applypatch-msg

این قلاب توسط git-am(1) فراخوانی می‌شود. یک پارامتر منفرد می‌گیرد که نام فایلی است که پیام پیشنهادی لاگ کامیت را نگه می‌دارد. خروج با وضعیتی غیر از صفر باعث می‌شود git am قبل از اعمال وصله (patch) عملیات را لغو کند.

قلاب مجاز است فایل پیام را در جا ویرایش کند و می‌توان از آن برای استانداردسازی پیام به یک قالب تعریف‌شده در پروژه استفاده کرد. همچنین می‌توان پس از بررسی فایل پیام، از آن برای رد کردن کامیت استفاده نمود.

قلاب پیش‌فرض applypatch-msg در صورت فعال بودن، در صورتی که قلاب commit-msg نیز فعال باشد، آن را اجرا می‌کند.

pre-applypatch

این قلاب توسط git-am(1) فراخوانی می‌شود. هیچ پارامتری دریافت نمی‌کند و پس از اعمال وصله، اما قبل از ثبت کامیت فراخوانی می‌گردد.

اگر با وضعیت غیر صفر خارج شود، درخت کاری پس از اعمال وصله کامیت نخواهد شد.

از این قلاب می‌توان برای بررسی درخت کاری فعلی و امتناع از ثبت کامیت در صورت عدم موفقیت در آزمون‌های خاص استفاده کرد.

قلاب پیش‌فرض pre-applypatch در صورت فعال بودن، قلاب pre-commit را اجرا می‌کند (چنانچه فعال باشد).

post-applypatch

این قلاب توسط git-am(1) فراخوانی می‌شود. پارامتری دریافت نمی‌کند و پس از اعمال وصله و ایجاد یک کامیت فراخوانی می‌شود.

این قلاب عمدتاً برای اطلاع‌رسانی در نظر گرفته شده است و نمی‌تواند بر نتیجهٔ git am تأثیر بگذارد.

pre-commit

این قلاب توسط git-commit(1) فراخوانی می‌شود و با گزینهٔ --no-verify می‌توان آن را نادیده گرفت. هیچ پارامتری دریافت نمی‌کند و قبل از دریافت پیام لاگ کامیت پیشنهادی و ایجاد کامیت فراخوانی می‌گردد. خروج با وضعیت غیر صفر از این اسکریپت باعث می‌شود دستور git commit پیش از ایجاد کامیت متوقف شود.

تمام قلاب‌های مربوط به git commit در صورتی که دستور قرار نباشد ویرایشگری را برای اصلاح پیام کامیت باز کند، با متغیر محیطی GIT_EDITOR=: فراخوانی می‌شوند.

قلاب پیش‌فرض pre-commit در صورت فعال بودن، از افزودن نام فایل‌های غیر ASCII و خطوط دارای فاصله‌های خالی انتهایی (trailing whitespace) جلوگیری می‌کند. بررسی نام‌های غیر ASCII را می‌توان با تنظیم گزینهٔ پیکربندی hooks.allownonascii روی true غیرفعال کرد.

pre-merge-commit

این قلاب توسط git-merge(1) فراخوانی می‌شود و می‌توان با گزینهٔ --no-verify آن را نادیده گرفت. هیچ پارامتری دریافت نمی‌کند و پس از انجام موفقیت‌آمیز ادغام و قبل از دریافت پیام پیشنهادی لاگ برای ثبت کامیت فراخوانی می‌شود. خروج با وضعیت غیر صفر باعث می‌شود دستور git merge قبل از ثبت کامیت لغو شود.

قلاب پیش‌فرض pre-merge-commit در صورت فعال بودن، قلاب pre-commit را (در صورت فعال بودن) اجرا می‌کند.

این قلاب در صورتی که دستور یک ویرایشگر را برای ویرایش پیام کامیت باز نکند، با متغیر محیطی GIT_EDITOR=: فراخوانی می‌شود.

اگر ادغام نتواند به‌صورت خودکار انجام شود، تعارض‌ها باید حل شده و نتیجه به‌صورت جداگانه کامیت شود (به git-merge(1) مراجعه کنید). در این حالت، این قلاب اجرا نخواهد شد، اما قلاب pre-commit در صورت فعال بودن اجرا می‌گردد.

prepare-commit-msg

این قلاب بلافاصله پس از آماده‌سازی پیام لاگ پیش‌فرض و قبل از باز شدن ویرایشگر توسط git-commit(1) فراخوانی می‌شود.

این قلاب یک تا سه پارامتر دریافت می‌کند. اولی نام فایلی است که پیام لاگ کامیت را در خود دارد. دومی منبع پیام کامیت است و می‌تواند یکی از موارد زیر باشد: message (اگر گزینهٔ -m یا -F داده شده باشد)؛ template (اگر گزینهٔ -t داده شده باشد یا متغیر پیکربندی commit.template تنظیم شده باشد)؛ merge (اگر کامیت حاصل یک ادغام باشد یا فایل .git/MERGE_MSG وجود داشته باشد)؛ squash (اگر فایل .git/SQUASH_MSG وجود داشته باشد)؛ یا commit که به دنبال آن یک نام شیء کامیت می‌آید (اگر گزینهٔ -c، -C یا --amend داده شده باشد).

اگر وضعیت خروج غیر صفر باشد، git commit لغو خواهد شد.

هدف از این قلاب، ویرایش فایل پیام در جا است و با گزینهٔ --no-verify نادیده گرفته نمی‌شود. خروج با مقدار غیر صفر به منزله شکست قلاب است و کامیت را لغو می‌کند. نباید از این قلاب به عنوان جایگزینی برای قلاب pre-commit استفاده شود.

قلاب نمونهٔ prepare-commit-msg که همراه Git ارائه می‌شود، پیام راهنمای موجود در بخش‌های کامنت‌شده قالب کامیت را حذف می‌کند.

commit-msg

این قلاب توسط git-commit(1) و git-merge(1) فراخوانی می‌شود و با گزینهٔ --no-verify قابل نادیده‌گیری است. این قلاب یک پارامتر دریافت می‌کند: نام فایلی که پیام لاگ کامیت پیشنهادی را در خود دارد. خروج با وضعیت غیر صفر موجب لغو دستور می‌شود.

قلاب مجاز است فایل پیام را در جا ویرایش کند و می‌توان از آن برای استانداردسازی پیام به فرمت خاص پروژه استفاده کرد. همچنین می‌توان پس از بررسی محتوای فایل پیام، از ایجاد کامیت ممانعت به عمل آورد.

قلاب پیش‌فرض commit-msg در صورت فعال بودن، تریلرهای تکراری Signed-off-by را شناسایی کرده و در صورت یافتن، کامیت را لغو می‌کند.

post-commit

این قلاب توسط git-commit(1) فراخوانی می‌شود. هیچ پارامتری نمی‌گیرد و پس از ایجاد کامیت فراخوانی می‌شود.

هدف اصلی این قلاب اطلاع‌رسانی است و نمی‌تواند بر نتیجهٔ نهایی git commit تأثیر بگذارد.

pre-rebase

این قلاب توسط git-rebase(1) فراخوانی می‌شود و می‌توان از آن برای جلوگیری از بازپایه‌ریزی (rebase) یک شاخه استفاده کرد. قلاب ممکن است با یک یا دو پارامتر فراخوانی شود. پارامتر اول شاخه بالادستی (upstream) است که مجموعه تغییرات از آن منشعب شده است. پارامتر دوم شاخه‌ای است که در حال بازپایه‌ریزی است؛ این مقدار هنگام بازپایه‌ریزی شاخهٔ فعلی تنظیم نمی‌شود.

post-checkout

این قلاب هنگامی فراخوانی می‌شود که پس از به‌روزرسانی درخت کاری، دستور git-checkout(1) یا git-switch(1) اجرا شود. سه پارامتر به قلاب داده می‌شود: ارجاع HEAD قبلی، ارجاع HEAD جدید (که ممکن است تغییر کرده یا نکرده باشد) و یک پرچم که نشان می‌دهد آیا خروج مربوط به یک شاخه بوده است (تغییر شاخه، پرچم=1) یا مربوط به یک فایل (بازیابی فایل از نمایه/ایندکس، پرچم=0). این قلاب نمی‌تواند بر نتیجهٔ git switch یا git checkout تأثیری بگذارد، به جز این‌که وضعیت خروج قلاب تبدیل به وضعیت خروج این دو دستور می‌شود.

این قلاب همچنین پس از اجرای git-clone(1) اجرا می‌شود، مگر این‌که گزینهٔ --no-checkout (-n) استفاده شده باشد. اولین پارامتر داده‌شده به قلاب null-ref است، دومی ارجاع HEAD جدید و مقدار پرچم همواره 1 است. به‌طور مشابه برای دستور git worktree add نیز اجرا می‌شود مگر این‌که --no-checkout استفاده شده باشد.

از این قلاب می‌توان برای بررسی اعتبارسنجی مخزن، نمایش خودکار تفاوت‌ها با HEAD قبلی (در صورت تغییر)، یا تنظیم خصوصیات متادیتای دایرکتوری کاری استفاده کرد.

post-merge

این قلاب توسط git-merge(1) فراخوانی می‌شود، که هنگام اجرای git pull روی یک مخزن محلی رخ می‌دهد. قلاب یک پارامتر می‌گیرد: یک پرچم وضعیت که مشخص می‌کند آیا ادغام انجام‌شده از نوع فشرده‌سازی (squash merge) بوده است یا خیر. این قلاب نمی‌تواند بر نتیجهٔ نهایی git merge تأثیر بگذارد و در صورتی که ادغام به دلیل وجود تعارض‌ها با شکست مواجه شود، اجرا نخواهد شد.

از این قلاب می‌توان در ترکیب با یک قلاب متناظر pre-commit برای ذخیره و بازیابی هر شکلی از متادیتای مرتبط با درخت کاری (مانند دسترسی‌ها/مالکیت، ACLها و غیره) استفاده کرد. برای مشاهده یک نمونه از نحوه انجام این کار، به contrib/hooks/setgitperms.perl مراجعه کنید.

pre-push

این قلاب توسط git-push(1) فراخوانی می‌شود و می‌تواند برای جلوگیری از ارسال تغییرات (push) به کار رود. قلاب با دو پارامتر فراخوانی می‌شود که نام و آدرس مخزن ریموت مقصد را ارائه می‌دهند؛ در صورتی که از یک ریموت نام‌گذاری‌شده استفاده نشود، هر دو مقدار یکسان خواهند بود.

اطلاعات مربوط به آنچه قرار است ارسال شود در ورودی استاندارد (stdin) قلاب با خطوطی به فرمت زیر ارائه می‌شود:

<local-ref> SP <local-object-name> SP <remote-ref> SP <remote-object-name> LF

برای مثال، اگر دستور git push origin master:foreign اجرا شود، قلاب خطی مانند زیر دریافت می‌کند:

refs/heads/master 67890 refs/heads/foreign 12345

اگرچه نام کامل شیء ارائه خواهد شد. اگر مرجع ریموت هنوز وجود نداشته باشد، مقدار <remote-object-name> شیء کاملاً صفر خواهد بود. اگر قرار باشد مرجعی حذف شود، <local-ref> به‌صورت (delete) و مقدار <local-object-name> شیء تماماً صفر ارسال می‌شود. اگر کامیت محلی با چیزی غیر از نامی که بتوان آن را گسترش داد مشخص شده باشد (مانند HEAD~ یا نام شیء)، به همان صورتی که در ابتدا داده شده بود، ارسال خواهد شد.

اگر این قلاب با وضعیت غیر صفر خارج شود، git push بدون ارسال هیچ داده‌ای متوقف خواهد شد. اطلاعات مربوط به علت رد شدن push می‌تواند با نوشتن روی خروجی استاندارد خطا (stderr) به کاربر نشان داده شود.

pre-receive

این قلاب توسط git-receive-pack(1) هنگامی فراخوانی می‌شود که در واکنش به git push، مرجع‌ها را در مخزن خود به‌روزرسانی می‌کند. این قلاب درست قبل از شروع به‌روزرسانی مرجع‌ها در مخزن ریموت فراخوانی می‌شود. وضعیت خروج آن موفقیت یا شکست عملیات به‌روزرسانی را تعیین می‌کند.

این قلاب یک‌بار برای کل عملیات دریافت اجرا می‌شود. هیچ آرگومانی دریافت نمی‌کند، اما برای هر مرجعی که قرار است به‌روزرسانی شود، خطی با فرمت زیر از ورودی استاندارد دریافت می‌کند:

<old-oid> SP <new-oid> SP <ref-name> LF

که در آن <old-oid> نام شیء قدیمی ذخیره‌شده در مرجع، <new-oid> نام شیء جدید برای ذخیره در مرجع، و <ref-name> نام کامل مرجع است. هنگام ایجاد یک مرجع جدید، <old-oid> یک شیء تماماً صفر است.

اگر قلاب با وضعیت غیر صفر خارج شود، هیچ‌کدام از مرجع‌ها به‌روزرسانی نخواهند شد. اگر با صفر خارج شود، همچنان می‌توان از به‌روزرسانی مرجع‌های تکی توسط قلاب update جلوگیری کرد.

هر دو خروجی استاندارد (stdout) و خروجی خطای استاندارد (stderr) به دستور git send-pack در سمت دیگر ارسال می‌شوند، بنابراین می‌توانید به‌سادگی با استفاده از echo پیام‌هایی را برای کاربر نمایش دهید.

تعداد گزینه‌های push مشخص‌شده در خط فرمان git push --push-option=... را می‌توان از متغیر محیطی GIT_PUSH_OPTION_COUNT خواند و خود گزینه‌ها در GIT_PUSH_OPTION_0، GIT_PUSH_OPTION_1 و غیره یافت می‌شوند. در صورتی که در مذاکره توافق شود که از فاز گزینه‌های push استفاده نشود، این متغیرهای محیطی تنظیم نخواهند شد. اگر کلاینت استفاده از گزینه‌های push را انتخاب کند اما هیچ گزینه‌ای ارسال نکند، متغیر شمارنده روی صفر تنظیم می‌شود (GIT_PUSH_OPTION_COUNT=0).

برای آگاهی از برخی نکات و هشدارها، به بخش "Quarantine Environment" در git-receive-pack(1) مراجعه کنید.

update

این قلاب توسط git-receive-pack(1) هنگامی فراخوانی می‌شود که در واکنش به git push، مرجع‌ها را در مخزن خود به‌روزرسانی می‌کند. قلاب درست قبل از به‌روزرسانی مرجع در مخزن ریموت فراخوانی می‌شود. وضعیت خروج آن موفقیت یا شکست به‌روزرسانی مرجع را مشخص می‌کند.

قلاب یک‌بار به ازای هر مرجعی که قرار است به‌روز شود اجرا می‌گردد و سه پارامتر دریافت می‌کند:

خروج با کد صفر از قلاب update اجازه می‌دهد تا مرجع به‌روزرسانی شود. خروج با وضعیت غیر صفر مانع از به‌روزرسانی آن مرجع توسط git receive-pack می‌شود.

از این قلاب می‌توان برای جلوگیری از به‌روزرسانی‌های اجباری (forced) روی مرجع‌های خاص استفاده کرد تا اطمینان حاصل شود که نام شیء، یک شیء کامیت است که از نسل شیء کامیت مشخص‌شده با نام شیء قدیمی می‌باشد؛ به این معنی که سیاست «فقط رو به جلو» (fast-forward only) اعمال گردد.

همچنین می‌توان از آن برای ثبت وقایع وضعیت old..new استفاده کرد. با این حال، چون این قلاب کل مجموعه شاخه‌ها را نمی‌شناسد، استفاده ساده‌لوحانه از آن باعث ارسال یک ایمیل به ازای هر مرجع می‌شود. قلاب post-receive برای این منظور مناسب‌تر است.

در محیطی که دسترسی کاربران فقط به دستورهای git از طریق شبکه محدود شده است، می‌توان از این قلاب برای پیاده‌سازی کنترل دسترسی بدون وابستگی به مالکیت فایل‌سیستم و عضویت در گروه‌ها استفاده کرد. برای چگونگی استفاده از شل ورود به منظور محدود کردن دسترسی کاربر به دستورهای git، به git-shell(1) مراجعه کنید.

هر دو خروجی استاندارد و خروجی خطای استاندارد به git send-pack در سمت دیگر ارسال می‌شوند، بنابراین می‌توانید پیام‌ها را به‌سادگی با echo به کاربر برسانید.

قلاب پیش‌فرض update در صورت فعال بودن — و در حالتی که گزینهٔ پیکربندی hooks.allowunannotated تنظیم نشده یا روی false باشد — از push شدن تگ‌های بدون حاشیه‌نویسی (unannotated tags) جلوگیری می‌کند.

proc-receive

این قلاب توسط git-receive-pack(1) فراخوانی می‌شود. اگر سرور متغیر پیکربندی چندمقداری receive.procReceiveRefs را تنظیم کرده باشد و دستورات ارسال‌شده به receive-pack با نام‌های مرجع مطابقت داشته باشند، این دستورات به جای تابع داخلی execute_commands() توسط این قلاب اجرا خواهند شد. این قلاب مسئول به‌روزرسانی مرجع‌های مربوطه و گزارش نتایج به receive-pack است.

این قلاب یک‌بار برای عملیات دریافت اجرا می‌شود. هیچ آرگومانی نمی‌گیرد، اما از پروتکل با فرمت pkt-line برای برقراری ارتباط با receive-pack جهت خواندن دستورها، گزینه‌های push و ارسال نتایج استفاده می‌کند. در مثال زیر برای این پروتکل، حرف S نمایندهٔ receive-pack و حرف H نمایندهٔ این قلاب است.

# مذاکره نسخه و ویژگی‌ها.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt

# ارسال دستورها از سرور به قلاب.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# ارسال push-options تنها در صورتی که ویژگی 'push-options' فعال باشد.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt

# دریافت نتایج از قلاب.
# وضعیت OK: دستور با موفقیت اجرا شد.
H: PKT-LINE(ok <ref>)
# وضعیت NO: دستور رد شد.
H: PKT-LINE(ng <ref> <reason>)
# عبور دادن: اجازه دهید خود 'receive-pack' آن را اجرا کند.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# وضعیت OK اما با یک مرجع جایگزین. نام مرجع جایگزین
# و سایر وضعیت‌ها را می‌توان در دستورالعمل‌های option مشخص کرد.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt

هر دستور برای قلاب proc-receive ممکن است به یک شبه‌مرجع اشاره کند و همیشه دارای یک old-oid صفر است، در حالی که قلاب proc-receive ممکن است یک مرجع جایگزین را به‌روزرسانی کند که از قبل با یک old-oid غیر صفر وجود دارد. در این حالت، این قلاب از دستورالعمل‌های "option" برای گزارش ویژگی‌های توسعه‌یافته برای مرجعِ مشخص‌شده در دستور "ok" قبلی استفاده می‌کند.

گزارش دستورهای این قلاب باید همان ترتیبی را داشته باشد که در ورودی دریافت شده است. وضعیت خروج قلاب proc-receive تنها موفقیت یا شکست کل گروه دستورهای ارسال‌شده به آن را تعیین می‌کند، مگر اینکه push اتمیک (atomic) در حال استفاده باشد.

post-receive

این قلاب توسط git-receive-pack(1) در واکنش به git push و به‌روزرسانی مرجع‌ها در مخزن فراخوانی می‌شود. این قلاب یک‌بار در مخزن ریموت پس از پردازش تمام به‌روزرسانی‌های مرجع و در صورتی که حداقل یک مرجع به‌روز شده باشد، اجرا می‌گردد.

قلاب هیچ آرگومانی نمی‌گیرد. به ازای هر مرجعی که با موفقیت به‌روزرسانی شده باشد، یک خط با همان ساختار و فرمت قلاب pre-receive از طریق ورودی استاندارد دریافت می‌کند.

این قلاب بر نتیجهٔ git receive-pack تأثیری ندارد، زیرا پس از انجام کار اصلی فراخوانی می‌شود.

این قلاب جایگزین پیشرفته‌تری برای قلاب post-update است، چرا که علاوه بر نام مرجع‌ها، هر دو مقدار قدیمی و جدید آن‌ها را نیز دریافت می‌کند.

هر دو خروجی استاندارد و خروجی خطای استاندارد به git send-pack ارسال می‌شوند، بنابراین می‌توانید پیام‌های مورد نظر را با echo به کاربر نمایش دهید.

قلاب پیش‌فرض post-receive خالی است، اما یک اسکریپت نمونه به نام post-receive-email در دایرکتوری contrib/hooks توزیع Git ارائه شده است که قابلیت ارسال ایمیل‌های کامیت را پیاده‌سازی می‌کند.

تعداد گزینه‌های push داده‌شده در خط فرمان git push --push-option=... را می‌توان از متغیر محیطی GIT_PUSH_OPTION_COUNT خواند و گزینه‌ها در GIT_PUSH_OPTION_0، GIT_PUSH_OPTION_1 و غیره در دسترس هستند. اگر توافق شود که از این مرحله استفاده نشود، متغیرها تنظیم نخواهند شد. اگر کلاینت استفاده از گزینه‌ها را فعال کند اما هیچ مقداری نفرستد، شمارنده صفر می‌شود (GIT_PUSH_OPTION_COUNT=0).

برای جزئیات بیشتر به بخش "post-receive" در git-receive-pack(1) مراجعه کنید.

post-update

این قلاب توسط git-receive-pack(1) در واکنش به git push و پس از به‌روزرسانی مرجع‌ها در مخزن ریموت فراخوانی می‌شود. این قلاب یک‌بار پس از به‌روز شدن تمام مرجع‌ها اجرا می‌گردد.

تعداد متغیری پارامتر دریافت می‌کند که هر یک از آن‌ها نام مرجعی است که واقعاً به‌روزرسانی شده است.

این قلاب در درجه اول برای اطلاع‌رسانی است و نمی‌تواند بر نتیجهٔ نهایی git receive-pack تأثیر بگذارد.

قلاب post-update می‌تواند مشخص کند که چه شاخه‌هایی push شده‌اند، اما مقادیر اصلی و به‌روزشده آن‌ها را نمی‌داند؛ بنابراین برای ثبت وقایع old..new مناسب نیست. در عوض، قلاب post-receive هم مقادیر اصلی و هم مقادیر جدید را دریافت می‌کند؛ اگر به این مقادیر نیاز دارید بهتر است از آن استفاده کنید.

قلاب پیش‌فرض post-update در صورت فعال بودن، دستور git update-server-info را اجرا می‌کند تا اطلاعات مورد استفاده توسط پروتکل‌های انتقال ساده (مانند HTTP) به‌روز نگه داشته شود. اگر مخزنی را منتشر می‌کنید که از طریق HTTP قابل دسترسی است، احتمالاً باید این قلاب را فعال کنید.

هر دو خروجی استاندارد و خطای استاندارد به git send-pack در سمت دیگر ارسال می‌شوند.

reference-transaction

این قلاب توسط هر دستور Git که به‌روزرسانی مرجع‌ها را انجام می‌دهد فراخوانی می‌شود. هر زمان که یک تراکنش مرجع در وضعیت آماده‌سازی (preparing)، آماده‌شده (prepared)، کامیت‌شده (committed) یا لغوشده (aborted) قرار گیرد، اجرا می‌شود و بنابراین ممکن است چندین بار فراخوانی گردد. این قلاب همچنین از به‌روزرسانی مرجع‌های نمادین (symbolic references) پشتیبانی می‌کند.

این قلاب دقیقاً یک آرگومان می‌گیرد که همان وضعیت فعلی تراکنش مرجع است:

برای هر به‌روزرسانی مرجعی که به تراکنش اضافه شده است، قلاب خطی با فرمت زیر را در ورودی استاندارد دریافت می‌کند:

<old-value> SP <new-value> SP <ref-name> LF

که در آن <old-value> نام شیء قدیمی ارسال‌شده به تراکنش مرجع، <new-value> نام شیء جدید برای ذخیره در مرجع، و <ref-name> نام کامل مرجع است. هنگام به‌روزرسانی اجباری مرجع بدون در نظر گرفتن مقدار فعلی آن، یا زمانی که مرجع باید از نو ایجاد شود، <old-value> یک شیء تماماً صفر است. برای تمایز این موارد، می‌توانید مقدار فعلی <ref-name> را از طریق git rev-parse بررسی کنید. در طول وضعیت "preparing"، مرجع‌های نمادین حل نمی‌شوند: <ref-name> خود مرجع نمادین را منعکس می‌کند نه شیئی که به آن اشاره دارد.

برای به‌روزرسانی‌های مرجع نمادین، فیلدهای <old_value> و <new-value> می‌توانند به جای اشیاء، نشان‌دهنده مرجع‌ها باشند. یک مرجع با پیشوند ref: مشخص می‌شود، مانند ref:<ref-target>.

وضعیت خروج قلاب برای هر وضعیتی به جز حالت‌های "preparing" و "prepared" نادیده گرفته می‌شود. در این دو وضعیت، خروج با وضعیت غیر صفر موجب لغو شدن تراکنش خواهد شد. در این حالت قلاب با وضعیت "aborted" فراخوانی نخواهد شد.

push-to-checkout

این قلاب توسط git-receive-pack(1) فراخوانی می‌شود هنگامی که به git push واکنش نشان داده و مرجع‌ها را در مخزن خود به‌روزرسانی می‌کند، و زمانی که دستور push تلاش می‌کند شاخه‌ای را که در حال حاضر دریافت (checkout) شده به‌روز کند و متغیر پیکربندی receive.denyCurrentBranch روی updateInstead تنظیم شده باشد. چنین ارسال‌هایی به‌طور پیش‌فرض در صورتی که درخت کاری و نمایه مخزن ریموت تفاوتی با کامیت فعال فعلی داشته باشند، رد می‌شوند؛ اگر هر دو درخت کاری و نمایه با کامیت فعلی مطابقت داشته باشند، به‌روزرسانی می‌شوند تا با نوک جدید شاخه همگام شوند. این قلاب برای بازنویسی و تغییر این رفتار پیش‌فرض استفاده می‌شود.

این قلاب کامیتی را دریافت می‌کند که قرار است نوک شاخه فعلی به آن به‌روز شود. می‌تواند با وضعیت غیر صفر خارج شود تا از push جلوگیری کند (در این صورت نباید نمایه یا درخت کاری را تغییر دهد). یا می‌تواند هرگونه تغییر لازم را در درخت کاری و نمایه اعمال کند تا به محض به‌روزرسانی شاخه به کامیت جدید، به وضعیت دلخواه برسند و سپس با وضعیت صفر خارج شود.

به عنوان مثال، قلاب می‌تواند دستور git read-tree -u -m HEAD "$1" را اجرا کند تا رفتار دستور git fetch معکوس‌شده با git push را شبیه‌سازی کند؛ زیرا فرمت دو درختی git read-tree -u -m اساساً همان کار git switch یا git checkout را انجام می‌دهد که ضمن حفظ تغییرات محلی در درخت کاری (در صورتی که با تفاوت بین شاخه‌ها تداخل نداشته باشند)، شاخه‌ها را تعویض می‌کند.

pre-auto-gc

این قلاب توسط git gc --auto فراخوانی می‌شود (به git-gc(1) مراجعه کنید). هیچ پارامتری دریافت نمی‌کند و خروج با وضعیت غیر صفر از این اسکریپت باعث متوقف شدن اجرای git gc --auto می‌شود.

post-rewrite

این قلاب توسط دستورهایی فراخوانی می‌شود که کامیت‌ها را بازنویسی می‌کنند (git-commit(1) هنگامی که با --amend فراخوانی شود و git-rebase(1)؛ با این حال، ابزارهای بازنویسی کل تاریخچه مانند git-fast-import(1) یا git-filter-repo[1] معمولاً آن را فراخوانی نمی‌کنند!). اولین آرگومان آن دستوری را مشخص می‌کند که قلاب را فراخوانی کرده است: در حال حاضر یکی از مقادیر amend یا rebase. آرگومان‌های وابسته به دستور دیگر ممکن است در آینده اضافه شوند.

قلاب لیستی از کامیت‌های بازنویسی‌شده را در stdin به فرمت زیر دریافت می‌کند:

<old-object-name> SP <new-object-name> [ SP <extra-info> ] LF

مقدار extra-info نیز وابسته به دستور فراخوان است. اگر خالی باشد، کاراکتر SP قبلی نیز حذف می‌شود. در حال حاضر هیچ دستوری مقدار extra-info ارسال نمی‌کند.

قلاب همیشه پس از کپی خودکار یادداشت‌ها (notes) اجرا می‌شود (به "notes.rewrite.<command>" در git-config(1) مراجعه کنید) و بنابراین به این یادداشت‌ها دسترسی دارد.

توضیحات خاص زیر در مورد دستورها اعمال می‌شود:

rebase

sendemail-validate

این قلاب توسط git-send-email(1) فراخوانی می‌شود.

این قلاب آرگومان‌های خط فرمان زیر را می‌گیرد: ۱. نام فایلی که محتوای ایمیل ارسالی را نگه می‌دارد. ۲. نام فایلی که هدرهای SMTP ایمیل را در خود دارد.

هدرهای SMTP دقیقاً به همان روشی ارسال می‌شوند که به عامل انتقال ایمیل (MTA) کاربر ارسال می‌گردند. در واقع، ایمیل ارائه‌شده به MTA کاربر، محتوای $2 و به دنبال آن محتوای $1 است.

نمونه‌ای از چند هدر رایج در زیر نشان داده شده است. به حروف بزرگ و کوچک و ساختار چندخطی Tab توجه داشته باشید.

From: Example <from@example.com>
To: to@example.com
Cc: cc@example.com,
        A <author@example.com>,
        One <one@example.com>,
        two@example.com
Subject: PATCH-STRING

خروج با وضعیت غیر صفر باعث می‌شود git send-email قبل از ارسال هرگونه ایمیل لغو شود.

متغیرهای محیطی زیر هنگام اجرای قلاب تنظیم می‌شوند:

GIT_SENDEMAIL_FILE_COUNTER

GIT_SENDEMAIL_FILE_TOTAL

این متغیرها برای مثال می‌توانند جهت اعتبارسنجی سری وصله‌ها به کار روند.

قلاب نمونهٔ sendemail-validate که همراه با Git عرضه می‌شود، بررسی می‌کند که تمام وصله‌های ارسالی (به استثنای نامه‌پوششی یا cover letter) بدون تعارض بر روی شاخه پیش‌فرض مخزن بالادست اعمال شوند. بخش‌هایی نیز برای مراحل اعتبارسنجی تکمیلی پس از اعمال تمام وصله‌های یک سری در نظر گرفته شده است.

fsmonitor-watchman

این قلاب زمانی فراخوانی می‌شود که متغیر پیکربندی core.fsmonitor بر روی .git/hooks/fsmonitor-watchman یا .git/hooks/fsmonitor-watchmanv2 (بسته به نسخه قلاب مورد استفاده) تنظیم شده باشد.

نسخه ۱ دو آرگومان می‌گیرد: نسخه (1) و زمان سپری‌شده بر حسب نانوثانیه از نیمه‌شب ۱ ژانویه ۱۹۷۰.

نسخه ۲ دو آرگومان می‌گیرد: نسخه (2) و یک توکن که برای شناسایی تغییرات از زمان آن توکن استفاده می‌شود. برای watchman این مقدار یک شناسه ساعت (clock id) خواهد بود. این نسخه باید توکن جدید و به دنبال آن یک بایت NUL را قبل از فهرست فایل‌ها در stdout چاپ کند.

قلاب باید فهرست تمام فایل‌های موجود در دایرکتوری کاری را که ممکن است از زمان درخواستی تغییر کرده باشند در stdout بنویسد. منطق باید فراگیر باشد تا هیچ تغییر احتمالی را از دست ندهد. مسیرها باید نسبت به ریشهٔ دایرکتوری کاری بوده و با یک کاراکتر NUL از یکدیگر جدا شوند.

اشکالی ندارد اگر فایل‌هایی که واقعاً تغییر نکرده‌اند نیز در فهرست گنجانده شوند. تمام تغییرات از جمله فایل‌های جدید ایجاد‌شده و حذف‌شده باید لحاظ گردند. در صورت تغییر نام فایل‌ها، هر دو نام قدیمی و جدید باید ذکر شوند.

گیت بررسی فایل‌ها و همچنین بررسی دایرکتوری‌ها برای یافتن فایل‌های ردگیری‌نشده (untracked) را بر اساس نام مسیرهای داده‌شده محدود می‌کند.

یک روش بهینه‌سازی‌شده برای اینکه به git بگویید «همه فایل‌ها تغییر کرده‌اند»، بازگرداندن نام فایل / است.

وضعیت خروج تعیین می‌کند که آیا git از داده‌های قلاب برای محدود کردن جستجوی خود استفاده کند یا خیر. در صورت بروز خطا، به بررسی سنتی تمام فایل‌ها و پوشه‌ها بازمی‌گردد.

p4-changelist

این قلاب توسط git-p4 submit فراخوانی می‌شود.

قلاب p4-changelist پس از این‌که پیام changelist توسط کاربر ویرایش شد اجرا می‌گردد. با گزینهٔ --no-verify می‌توان آن را نادیده گرفت. یک پارامتر منفرد می‌گیرد: نام فایلی که متن پیشنهادی changelist را نگه می‌دارد. خروج با وضعیت غیر صفر موجب لغو دستور می‌شود.

قلاب مجاز است فایل changelist را ویرایش کند و می‌توان از آن برای استانداردسازی متن به فرمت پروژه استفاده نمود. همچنین می‌توان پس از بازرسی فایل پیام، عملیات Submit را لغو کرد.

برای جزئیات بیشتر دستور git-p4 submit --help را اجرا کنید.

p4-prepare-changelist

این قلاب توسط git-p4 submit فراخوانی می‌شود.

قلاب p4-prepare-changelist درست پس از آماده‌سازی پیام پیش‌فرض changelist و قبل از باز شدن ویرایشگر اجرا می‌شود. یک پارامتر دریافت می‌کند: نام فایلی که متن changelist را در خود دارد. خروج با وضعیت غیر صفر از اسکریپت باعث توقف فرآیند خواهد شد.

هدف از قلاب ویرایش فایل پیام در جا است و توسط گزینهٔ --no-verify لغو نمی‌شود. این قلاب حتی در صورت تنظیم بودن --prepare-p4-only نیز فراخوانی می‌شود.

برای جزئیات بیشتر git-p4 submit --help را اجرا کنید.

p4-post-changelist

این قلاب توسط git-p4 submit فراخوانی می‌شود.

قلاب p4-post-changelist پس از انجام موفقیت‌آمیز ثبت (submit) در P4 فراخوانی می‌شود. پارامتری دریافت نمی‌کند و اساساً برای اعلان و اطلاع‌رسانی است و نمی‌تواند بر نتیجه نهایی اقدام git p4 submit تأثیر بگذارد.

برای جزئیات بیشتر git-p4 submit --help را اجرا کنید.

p4-pre-submit

این قلاب توسط git-p4 submit فراخوانی می‌شود. هیچ پارامتری دریافت نمی‌کند و هیچ داده‌ای از ورودی استاندارد نمی‌خواند. خروج با وضعیت غیر صفر از این اسکریپت از شروع اجرای git-p4 submit جلوگیری می‌کند. می‌توان آن را با گزینه خط فرمان --no-verify نادیده گرفت. برای جزئیات git-p4 submit --help را اجرا کنید.

post-index-change

این قلاب هنگامی فراخوانی می‌شود که ایندکس (نمایه) در read-cache.c do_write_locked_index نوشته شود.

اولین پارامتر ارسالی به قلاب، نشانگری برای به‌روزرسانی دایرکتوری کاری است؛ "1" یعنی دایرکتوری کاری به‌روزرسانی شده و "0" یعنی به‌روزرسانی نشده است.

دومین پارامتر ارسالی به قلاب، نشانگری است برای اینکه آیا ایندکس به‌روز شده و بیت skip-worktree ممکن است تغییر کرده باشد یا خیر؛ "1" به معنای احتمال به‌روز شدن بیت‌های skip-worktree است و "0" به معنی عدم تغییر آن‌هاست.

هنگام اجرای قلاب فقط یکی از پارامترها باید روی "1" تنظیم باشد. اجرای قلاب با ارسال همزمان "1", "1" امکان‌پذیر نیست.