این دستور git-receive-pack است که می تواند در ارائه دهنده هاست رایگان OnWorks با استفاده از یکی از چندین ایستگاه کاری آنلاین رایگان ما مانند Ubuntu Online، Fedora Online، شبیه ساز آنلاین ویندوز یا شبیه ساز آنلاین MAC OS اجرا شود.
برنامه:
نام
git-receive-pack - آنچه را که به مخزن فشار داده شده است دریافت کنید
خلاصه
git-receive-pack
شرح
فراخوانی شده توسط دستگاه گوارش ارسال بسته و مخزن را با اطلاعاتی که از
انتهای راه دور
این دستور معمولاً مستقیماً توسط کاربر نهایی فراخوانی نمی شود. UI برای پروتکل است
در دستگاه گوارش ارسال بسته سمت، و جفت برنامه برای ارسال بهروزرسانیها استفاده میشود
مخزن از راه دور برای عملیات کشش، نگاه کنید git-fetch-pack(1).
این دستور امکان ایجاد و ارسال سریع refs sha1 (سر/برچسب) را بر روی آن فراهم می کند
انتهای راه دور (به طور دقیق، انتهای محلی است git-receive-pack اجرا می شود، اما به کاربر
که در انتهای بسته ارسال نشسته است، در حال به روز رسانی ریموت است. سردرگم؟)
نمونههای واقعی دیگری از استفاده از هوکهای بهروزرسانی و پس از بهروزرسانی وجود دارد
دایرکتوری اسناد/نحوه.
git-receive-pack گزینه پیکربندی receive.denyNonFastForwards را ارج می نهد، که به آن می گوید که آیا
اگر بهروزرسانیهای یک مرجع سریع به جلو نیستند، باید رد شوند.
OPTIONS
مخزن برای همگام سازی
پیش دریافت کنید HOOK
قبل از بهروزرسانی، اگر فایل $GIT_DIR/hooks/pre-receive وجود داشته باشد و قابل اجرا باشد،
یک بار بدون هیچ پارامتری فراخوانی می شود. ورودی استاندارد قلاب یک خط خواهد بود
در هر مرجع که باید به روز شود:
sha1-old SP sha1-new SP refname LF
مقدار refname نسبت به $GIT_DIR است. به عنوان مثال برای سر استاد این است
"رفع / سر / استاد". دو مقدار sha1 قبل از هر refname نام شیء هستند
refname قبل و بعد از آپدیت Refهایی که باید ایجاد شوند sha1-old برابر با 0{40} خواهند بود،
در حالی که موارد حذف شده دارای sha1-new برابر با 0{40} خواهند بود، در غیر این صورت sha1-old و
sha1-new باید اشیاء معتبر در مخزن باشد.
هنگام پذیرش فشار امضا شده (نگاه کنید به git-push(1))، گواهی فشار امضا شده در a ذخیره می شود
blob و یک متغیر محیطی GIT_PUSH_CERT را می توان برای نام شی آن مورد استفاده قرار داد. دیدن
شرح قلاب پس از دریافت به عنوان مثال. علاوه بر این، گواهی است
با استفاده از GPG تأیید می شود و نتیجه با متغیرهای محیطی زیر صادر می شود:
GIT_PUSH_CERT_SIGNER
نام و آدرس ایمیل صاحب کلیدی که فشار را امضا کرده است
گواهی
GIT_PUSH_CERT_KEY
شناسه کلید GPG کلیدی که گواهی فشار را امضا کرده است.
GIT_PUSH_CERT_STATUS
وضعیت تأیید GPG گواهی فشار، با استفاده از همان یادگاری
در %G استفاده می شود؟ فرمت دستورات خانواده git log (نگاه کنید به گیت(1).
GIT_PUSH_CERT_NONCE
رشته nonce فرآیند از امضاکننده خواست تا در گواهی فشار وارد شود. اگر
این با مقدار ثبت شده در هدر "nonce" در گواهی فشار مطابقت ندارد،
ممکن است نشان دهد که گواهینامه معتبری است که از a در حال پخش مجدد است
جلسه جداگانه "git push".
GIT_PUSH_CERT_NONCE_STATUS
ناخواسته
"git push --signed" زمانی که ما از آن درخواست ارسال نکردیم، یک nonce ارسال کرد.
گم شده
"git push --signed" هیچ هدر nonce ارسال نکرد.
بد
"git push --signed" یک nonce جعلی ارسال کرد.
OK
"git push --signed" پیامی را که از آن خواسته بودیم ارسال کند.
SLOP
"git push --signed" یک nonce متفاوت از آنچه که اکنون از آن خواسته بودیم ارسال کرد، اما
در جلسه قبلی متغیر محیطی GIT_PUSH_CERT_NONCE_SLOP را ببینید.
GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" یک nonce متفاوت از آنچه که اکنون از آن خواسته بودیم ارسال کرد، اما در a
جلسه متفاوتی که زمان شروع آن با این چند ثانیه متفاوت است
جلسه جاری فقط زمانی معنادار است که GIT_PUSH_CERT_NONCE_STATUS می گوید SLOP. همچنین بخوانید
در مورد متغیر receive.certNonceSlop در گیت(1).
این هوک قبل از بهروزرسانی نام مجدد و قبل از بررسی سریع به جلو، فراخوانی میشود
انجام.
اگر قلاب پیش دریافت با وضعیت خروج غیر صفر خارج شود، هیچ به روز رسانی انجام نخواهد شد.
و قلاب های به روز رسانی، پس از دریافت و پس از به روز رسانی نیز فراخوانی نمی شوند. این میتواند باشد
اگر بهروزرسانی پشتیبانی نمیشود، برای نجات سریع وثیقه مفید است.
بروزرسانی HOOK
قبل از بهروزرسانی هر مرجع، اگر فایل $GIT_DIR/hooks/update وجود داشته باشد و قابل اجرا باشد،
یک بار در هر ref فراخوانی می شود، با سه پارامتر:
$GIT_DIR/hooks/update refname sha1-old sha1-new
پارامتر refname نسبت به $GIT_DIR است. به عنوان مثال برای سر استاد این است
"رفع / سر / استاد". دو آرگومان sha1 نام اشیا برای refname قبلی هستند
و بعد از آپدیت توجه داشته باشید که هوک قبل از بهروزرسانی نام refname فراخوانی میشود، بنابراین
یا sha1-old 0{40} است (یعنی هنوز چنین مرجعی وجود ندارد)، یا باید با آنچه که هست مطابقت داشته باشد
ثبت شده در refname
اگر نمیخواهد بهروزرسانی مرجع نامشده را ممنوع کند، قلاب باید با وضعیت غیر صفر خارج شود.
در غیر این صورت باید با صفر خارج شود.
اجرای موفقیتآمیز (وضعیت خروج صفر) این قلاب، اراده رف را تضمین نمیکند
در واقع به روز شود، این فقط یک پیش نیاز است. به این ترتیب ارسال ایده خوبی نیست
اعلامیه ها (به عنوان مثال ایمیل) از این قلاب. به جای آن از قلاب پس از دریافت استفاده کنید.
پس از دریافت HOOK
پس از بهروزرسانی همه مراجع (یا تلاش برای بهروزرسانی)، در صورتی که بهروزرسانی ref انجام شد
موفقیت آمیز بود، و اگر فایل $GIT_DIR/hooks/post-receive وجود داشته باشد و قابل اجرا باشد، خواهد بود
یک بار بدون پارامتر فراخوانی شده است. ورودی استاندارد قلاب برای هر خط یک خط خواهد بود
مرجع با موفقیت به روز شد:
sha1-old SP sha1-new SP refname LF
مقدار refname نسبت به $GIT_DIR است. به عنوان مثال برای سر استاد این است
"رفع / سر / استاد". دو مقدار sha1 قبل از هر refname نام شیء هستند
refname قبل و بعد از آپدیت Refهایی که ایجاد شدند sha1-old برابر خواهند داشت
0{40}، در حالی که ref هایی که حذف شده اند sha1-new برابر با 0{40} خواهند داشت، در غیر این صورت sha1-old هستند
و sha1-new باید اشیاء معتبر در مخزن باشند.
متغیرهای محیطی GIT_PUSH_CERT* را میتوان بررسی کرد، درست مانند قلاب پیشدریافت،
پس از پذیرش یک فشار امضا شده
با استفاده از این قلاب، میتوان ایمیلهایی را که بهروزرسانیهای مخزن را توصیف میکنند، تولید کرد.
این اسکریپت نمونه به ازای هر ref یک پیام ایمیل ارسال میکند که commitهای ارسال شده به آن را فهرست میکند
مخزن، و گواهیهای ارسال فشارهای امضا شده را با امضای خوب به a ثبت میکند
خدمات لاگر:
#!/ بن / شل
# mail out commit اطلاعات به روز رسانی.
در حالی که بیضی nval ref
do
if expr "$oval" : '0*$' >/dev/null
سپس
echo "یک مرجع جدید با commit های زیر ایجاد کرد:"
git rev-list -- بسیار زیبا "$nval"
دیگر
echo "تعهدات جدید:"
git rev-list -- زیبا "$nval" "^$oval"
fi |
mail -s "تغییر در ref $ref" commit-list@mydomain
انجام شده
در صورت وجود، گواهی فشار امضا شده به سیستم وارد شوید
اگر تست -n "${GIT_PUSH_CERT-}" و & تست ${GIT_PUSH_CERT_STATUS} = G
سپس
(
پژواک غیر قابل انتظار ${GIT_PUSH_NONCE} است
git cat-blob ${GIT_PUSH_CERT}
) | mail -s "گواهی فشار از $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
خروج 0
کد خروج از این فراخوانی قلاب نادیده گرفته می شود، اما یک کد خروج غیر صفر
ایجاد یک پیام خطا
توجه داشته باشید که این امکان وجود دارد که refname هنگام اجرا شدن این قلاب sha1-new نداشته باشد. این می تواند
به راحتی اتفاق می افتد اگر کاربر دیگری پس از به روز رسانی ref آن را تغییر دهد git-receive-pack,
اما قبل از اینکه هوک بتواند آن را ارزیابی کند. توصیه می شود که قلاب ها به sha1-new تکیه کنند
به جای مقدار فعلی refname.
پس از به روز رسانی HOOK
پس از تمام پردازش های دیگر، اگر حداقل یک مرجع به روز شده باشد، و اگر
فایل $GIT_DIR/hooks/post-update وجود دارد و قابل اجرا است، سپس post-update فراخوانی می شود
با لیست داورانی که به روز شده اند. این می تواند برای پیاده سازی هر مخزن استفاده شود
وظایف پاکسازی گسترده
کد خروج از این فراخوانی قلاب نادیده گرفته می شود. تنها چیزی که برای
git-receive-pack انجام دادن در آن نقطه به هر حال خروج از خود است.
این قلاب را می توان به عنوان مثال برای اجرای git update-server-info در صورت وجود مخزن استفاده کرد
بسته بندی شده و از طریق یک حمل و نقل گنگ سرو می شود.
#!/ بن / شل
exec git update-server-info
با استفاده از خدمات onworks.net از git-receive-pack به صورت آنلاین استفاده کنید