設定和配置
獲取和建立專案
基本快照
分支與合併
共享和更新專案
檢查和比較
打補丁
除錯
電子郵件
外部系統
伺服器管理
指南
管理
底層命令
- 2.46.2 → 2.52.0 無更改
-
2.46.1
2024-09-13
-
2.46.0
2024-07-29
- 2.45.1 → 2.45.4 無更改
-
2.45.0
2024-04-29
- 2.44.1 → 2.44.4 無更改
-
2.44.0
2024-02-23
- 2.43.1 → 2.43.7 無更改
-
2.43.0
2023-11-20
- 2.41.1 → 2.42.4 無更改
-
2.41.0
2023-06-01
- 2.39.4 → 2.40.4 無更改
-
2.39.3
2023-04-17
- 2.36.1 → 2.39.2 無更改
-
2.36.0
2022-04-18
- 2.32.1 → 2.35.8 無更改
-
2.32.0
2021-06-06
- 2.30.2 → 2.31.8 無更改
-
2.30.1
2021-02-08
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 無更改
-
2.29.0
2020-10-19
- 2.28.1 無更改
-
2.28.0
2020-07-27
- 2.27.1 無更改
-
2.27.0
2020-06-01
- 2.26.1 → 2.26.3 無更改
-
2.26.0
2020-03-22
- 2.24.1 → 2.25.5 無更改
-
2.24.0
2019-11-04
- 2.23.1 → 2.23.4 無更改
-
2.23.0
2019-08-16
- 2.22.1 → 2.22.5 無更改
-
2.22.0
2019-06-07
- 2.19.1 → 2.21.4 無更改
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 無更改
-
2.18.0
2018-06-21
- 2.17.0 → 2.17.6 無更改
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
- 2.11.4 → 2.12.5 無變更
-
2.10.5
2017-09-22
-
2.9.5
2017-07-30
- 2.5.6 → 2.8.6 無更改
-
2.4.12
2017-05-05
- 2.3.10 無更改
-
2.2.3
2015-09-04
- 2.1.4 無更改
-
2.0.5
2014-12-17
描述
鉤子是在 Git 執行的特定點觸發操作的程式,您可以將它們放置在鉤子目錄中。未設定可執行位的鉤子將被忽略。
預設情況下,鉤子目錄是 $GIT_DIR/hooks,但可以透過 core.hooksPath 配置變數進行更改(請參閱 git-config[1])。
在 Git 呼叫鉤子之前,它會將工作目錄更改為裸倉庫中的 $GIT_DIR 或非裸倉庫中的工作樹根目錄。一個例外是推送期間觸發的鉤子(pre-receive、update、post-receive、post-update、push-to-checkout),這些鉤子始終在 $GIT_DIR 中執行。
環境變數,如 GIT_DIR、GIT_WORK_TREE 等,會被匯出,以便鉤子執行的 Git 命令能夠正確找到倉庫。如果您的鉤子需要在一個外部倉庫或同一倉庫的不同工作樹中呼叫 Git 命令,那麼它應該清除這些環境變數,以免它們干擾外部位置的 Git 操作。例如
local_desc=$(git describe) foreign_desc=$(unset $(git rev-parse --local-env-vars); git -C ../foreign-repo describe)
鉤子可以透過環境變數、命令列引數和標準輸入獲取其引數。有關詳細資訊,請參閱下面每個鉤子的文件。
git init 可能會根據其配置將鉤子複製到新倉庫。有關詳細資訊,請參閱 git-init[1] 中的“TEMPLATE DIRECTORY”部分。當本文件的其餘部分提及“預設鉤子”時,指的是 Git 附帶的預設模板。
下面將描述當前支援的鉤子。
鉤子
applypatch-msg
此鉤子由 git-am[1] 呼叫。它接受一個引數,即儲存建議的提交日誌訊息的檔名。以非零狀態退出將導致 git am 在應用補丁之前中止。
鉤子允許就地編輯訊息檔案,並可用於將訊息規範化為某些專案標準格式。它還可以用於在檢查訊息檔案後拒絕提交。
預設的 applypatch-msg 鉤子在啟用時會執行 commit-msg 鉤子(如果後者已啟用)。
pre-applypatch
此鉤子由 git-am[1] 呼叫。它不接受引數,並在應用補丁但提交之前被呼叫。
如果它以非零狀態退出,那麼在應用補丁後工作樹將不會被提交。
它可以用於檢查當前工作樹,並在不滿足某些測試時拒絕提交。
預設的 pre-applypatch 鉤子在啟用時會執行 pre-commit 鉤子(如果後者已啟用)。
pre-commit
此鉤子由 git-commit[1] 呼叫,並可透過 --no-verify 選項繞過。它不接受引數,並在獲取建議的提交日誌訊息和進行提交之前被呼叫。指令碼以非零狀態退出將導致 git commit 命令在建立提交之前中止。
預設的 pre-commit 鉤子在啟用時會捕獲引入的帶有尾隨空格的行,並在找到這樣的行時中止提交。
如果命令不會啟動編輯器來修改提交訊息,則所有 git commit 鉤子都會以環境變數 GIT_EDITOR=: 呼叫。
預設的 pre-commit 鉤子在啟用時(並且 hooks.allownonascii 配置選項未設定或設定為 false)會阻止使用非 ASCII 檔名。
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 鉤子的替代品。
Git 附帶的示例 prepare-commit-msg 鉤子會刪除提交模板註釋部分中的幫助訊息。
commit-msg
此鉤子由 git-commit[1] 和 git-merge[1] 呼叫,並可透過 --no-verify 選項繞過。它接受一個引數,即儲存建議的提交日誌訊息的檔名。以非零狀態退出將導致命令中止。
鉤子允許就地編輯訊息檔案,並可用於將訊息規範化為某些專案標準格式。它還可以用於在檢查訊息檔案後拒絕提交。
預設的 commit-msg 鉤子在啟用時會檢測重複的 Signed-off-by 尾部,並在找到重複項時中止提交。
pre-rebase
此鉤子由 git-rebase[1] 呼叫,可用於阻止分支被 rebase。該鉤子可能帶有一個或兩個引數。第一個引數是系列從中分叉的上游。第二個引數是要 rebase 的分支,在 rebase 當前分支時未設定。
post-checkout
在 git-checkout[1] 或 git-switch[1] 在更新工作樹後執行時,會呼叫此鉤子。該鉤子接受三個引數:上一個 HEAD 的 ref、新的 HEAD 的 ref(可能已更改,也可能未更改),以及一個指示簽出是分支簽出(更改分支,flag=1)還是檔案簽出(從索引檢索檔案,flag=0)的標誌。此鉤子不能影響 git switch 或 git checkout 的結果,除了鉤子的退出狀態將成為這兩個命令的退出狀態。
在 git-clone[1] 之後也會執行此鉤子,除非使用了 --no-checkout (-n)選項。傳遞給鉤子的第一個引數是 null-ref,第二個是新 HEAD 的 ref,標誌始終為 1。對於 git worktree add 也是如此,除非使用了 --no-checkout。
此鉤子可用於執行倉庫有效性檢查、在不同時自動顯示與前一個 HEAD 的差異,或設定工作目錄元資料屬性。
post-merge
此鉤子由 git-merge[1] 呼叫,當在本地倉庫上執行 git pull 時會發生。該鉤子接受一個引數,一個狀態標誌,指定正在進行的合併是否為 squash 合併。此鉤子不能影響 git merge 的結果,並且在合併因衝突而失敗時不會執行。
此鉤子可與相應的 pre-commit 鉤子結合使用,以儲存和恢復與工作樹關聯的任何形式的元資料(例如:許可權/所有權、ACL 等)。請參閱 contrib/hooks/setgitperms.perl 以獲取如何執行此操作的示例。
pre-push
此鉤子由 git-push[1] 呼叫,可用於阻止推送發生。該鉤子帶有兩個引數,提供目標遠端的名稱和位置,如果未使用命名遠端,則兩個值將相同。
有關要推送的內容的資訊透過以下格式的行提供給鉤子的標準輸入
<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
儘管會提供完整的物件名稱。如果 foreign ref 尚不存在,則 <remote-object-name> 將是全零物件名稱。如果要刪除 ref,則 <local-ref> 將提供為 (delete),並且 <local-object-name> 將是全零物件名稱。如果本地提交是透過除可展開名稱(如 HEAD~ 或物件名稱)之外的內容指定的,則將按原始方式提供。
如果此鉤子以非零狀態退出,git push 將中止,不執行任何推送。有關拒絕推送的原因的資訊可以透過寫入標準錯誤來發送給使用者。
pre-receive
當 git-receive-pack[1] 響應 git push 並更新其倉庫中的引用時,會呼叫此鉤子。在開始更新遠端倉庫中的 ref 之前,會呼叫 pre-receive 鉤子。其退出狀態決定更新的成功或失敗。
此鉤子對每個接收操作執行一次。它不接受引數,但對於要更新的每個 ref,它會在標準輸入上接收一行格式如下:
<old-oid> SP <new-oid> SP <ref-name> LF
其中 <old-oid> 是儲存在 ref 中的舊物件名稱,<new-oid> 是要儲存在新 ref 中的新物件名稱,<ref-name> 是 ref 的完整名稱。在建立新 ref 時,<old-oid> 是全零物件名稱。
如果鉤子以非零狀態退出,則不會更新任何 ref。如果鉤子以零狀態退出,更新仍然可以被 update 鉤子阻止。
標準輸出和標準錯誤輸出都會轉發到另一端的 git send-pack,因此您可以簡單地 echo 訊息給使用者。
可以透過環境變數 GIT_PUSH_OPTION_COUNT 讀取 git push --push-option=... 命令列的推送選項數量,選項本身位於 GIT_PUSH_OPTION_0、GIT_PUSH_OPTION_1、…。如果協商不使用推送選項階段,則不會設定環境變數。如果客戶端選擇使用推送選項但未傳輸任何選項,則計數變數將設定為零,GIT_PUSH_OPTION_COUNT=0。
有關注意事項,請參閱 git-receive-pack[1] 中的“Quarantine Environment”部分。
update
當 git-receive-pack[1] 響應 git push 並更新其倉庫中的引用時,會呼叫此鉤子。在更新遠端倉庫中的 ref 之前,會呼叫 update 鉤子。其退出狀態決定 ref 更新的成功或失敗。
該鉤子對每個要更新的 ref 執行一次,並接受三個引數:
-
正在更新的 ref 的名稱,
-
儲存在 ref 中的舊物件名稱,
-
以及要儲存在新 ref 中的新物件名稱。
update 鉤子以零退出允許更新 ref。以非零狀態退出將阻止 git receive-pack 更新該 ref。
此鉤子可用於透過確保物件名稱是現有物件名稱所指向提交物件的後代提交物件來防止對某些 ref 進行*強制*更新。也就是說,強制執行“僅限快進”策略。
它還可以用於記錄舊..新狀態。但是,它不知道所有分支的集合,因此在天真使用時,最終會為每個 ref 傳送一封電子郵件。 post-receive 鉤子更適合此目的。
在限制使用者僅透過網路訪問 git 命令的環境中,此鉤子可用於實現訪問控制,而無需依賴檔案系統所有權和組 membership。請參閱 git-shell[1] 瞭解如何使用登入 shell 將使用者的訪問許可權限制為僅 git 命令。
標準輸出和標準錯誤輸出都會轉發到另一端的 git send-pack,因此您可以簡單地 echo 訊息給使用者。
預設的 update 鉤子在啟用時(並且 hooks.allowunannotated 配置選項未設定或設定為 false)會阻止推送未註解的標籤。
proc-receive
此鉤子由 git-receive-pack[1] 呼叫。如果伺服器設定了多值配置變數 receive.procReceiveRefs,並且傳送到 receive-pack 的命令具有匹配的引用名稱,則這些命令將由此鉤子執行,而不是由內部 execute_commands() 函式執行。此鉤子負責更新相關引用並將結果報告回 receive-pack。
此鉤子對每個接收操作執行一次。它不接受引數,但使用 pkt-line 格式協議與 receive-pack 通訊,以讀取命令、推送選項併發送結果。在下面的協議示例中,字母 S 代表 receive-pack,字母 H 代表此鉤子。
# Version and features negotiation. S: PKT-LINE(version=1\0push-options atomic...) S: flush-pkt H: PKT-LINE(version=1\0push-options...) H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive results from the hook. # OK, run this command successfully. H: PKT-LINE(ok <ref>) # NO, I reject it. H: PKT-LINE(ng <ref> <reason>) # Fall through, let 'receive-pack' execute it. H: PKT-LINE(ok <ref>) H: PKT-LINE(option fall-through) # OK, but has an alternate reference. The alternate reference name # and other status can be given in option directives. 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 鉤子的退出狀態僅決定傳送給它的命令組的成功或失敗,除非使用原子推送。
post-receive
當 git-receive-pack[1] 響應 git push 並更新其倉庫中的引用時,會呼叫此鉤子。在處理完所有建議的 ref 更新後,如果至少有一個 ref 已更新,則此鉤子將在遠端倉庫上執行一次。
該鉤子不接受引數。對於每個成功更新的 ref,它會在標準輸入上接收一行,格式與 pre-receive 鉤子相同。
此鉤子不會影響 git receive-pack 的結果,因為它在實際工作完成後被呼叫。
它取代了 post-update 鉤子,因為它除了 ref 名稱外,還可以獲取所有 ref 的舊值和新值。
標準輸出和標準錯誤輸出都會轉發到另一端的 git send-pack,因此您可以簡單地 echo 訊息給使用者。
預設的 post-receive 鉤子是空的,但在 Git 發行版的 contrib/hooks 目錄中提供了一個示例指令碼 post-receive-email,該指令碼實現了傳送提交電子郵件的功能。
可以透過環境變數 GIT_PUSH_OPTION_COUNT 讀取 git push --push-option=... 命令列的推送選項數量,選項本身位於 GIT_PUSH_OPTION_0、GIT_PUSH_OPTION_1、…。如果協商不使用推送選項階段,則不會設定環境變數。如果客戶端選擇使用推送選項但未傳輸任何選項,則計數變數將設定為零,GIT_PUSH_OPTION_COUNT=0。
有關其他詳細資訊,請參閱 git-receive-pack[1] 中的“post-receive”部分。
post-update
當 git-receive-pack[1] 響應 git push 並更新其倉庫中的引用時,會呼叫此鉤子。它在所有 ref 更新完成後在遠端倉庫上執行一次。
它接受可變數量的引數,每個引數是要更新的 ref 的名稱。
此鉤子主要用於通知,不能影響 git receive-pack 的結果。
post-update 鉤子可以知道哪些 head 被推送了,但它不知道它們的原始值和更新值,所以它不適合用於記錄舊..新。如果您需要它們,可以考慮使用 post-receive 鉤子。
啟用後,預設的 post-update 鉤子會執行 git update-server-info 以保持用於啞傳輸(例如 HTTP)的資訊是最新的。如果您釋出了一個可以透過 HTTP 訪問的 Git 倉庫,您應該啟用此鉤子。
標準輸出和標準錯誤輸出都會轉發到另一端的 git send-pack,因此您可以簡單地 echo 訊息給使用者。
reference-transaction
此鉤子由執行引用更新的任何 Git 命令呼叫。它在引用事務準備、提交或中止時執行,因此可能會被呼叫多次。該鉤子還支援符號引用更新。
該鉤子接受一個引數,即給定引用事務所處的當前狀態:
-
"prepared": 所有引用更新都已排隊到事務中,並且引用已在磁碟上鎖定。
-
"committed": 引用事務已提交,並且所有引用現在都具有各自的新值。
-
"aborted": 引用事務已中止,未執行任何更改,並且已釋放鎖定。
對於新增到事務中的每個引用更新,鉤子將在標準輸入上接收一行格式如下:
<old-value> SP <new-value> SP <ref-name> LF
其中 <old-value> 是傳遞到引用事務中的舊物件名稱,<new-value> 是要儲存在 ref 中的新物件名稱,<ref-name> 是 ref 的完整名稱。在強制更新引用而不考慮其當前值時,或當引用需要重新建立時,<old-value> 是全零物件名稱。為了區分這些情況,您可以透過 git rev-parse 檢查 <ref-name> 的當前值。
對於符號引用更新,<old_value> 和 <new-value> 欄位可以表示引用而不是物件。引用將以 ref: 字首表示,例如 ref:<ref-target>。
除了“prepared”狀態外,鉤子的退出狀態在任何狀態下都被忽略。在“prepared”狀態下,非零退出狀態將導致事務被中止。在這種情況下,鉤子不會以“aborted”狀態被呼叫。
push-to-checkout
當 git-receive-pack[1] 響應 git push 並更新其倉庫中的引用時,並且當推送嘗試更新當前已簽出的分支且 receive.denyCurrentBranch 配置變數設定為 updateInstead 時,會呼叫此鉤子。預設情況下,如果遠端倉庫的工作樹和索引與當前已簽出的提交有任何差異,則拒絕此類推送;當工作樹和索引都與當前提交匹配時,它們將被更新以匹配分支的最新推送。此鉤子用於覆蓋預設行為。
該鉤子接收將用於更新當前分支尖端的提交。它可以以非零狀態退出以拒絕推送(當它這樣做時,它不得修改索引或工作樹)。或者,它可以對工作樹和索引進行任何必要的更改,以將它們帶到當前分支的尖端更新到新提交時的所需狀態,並以零狀態退出。
例如,鉤子可以簡單地執行 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,通常不會呼叫它!)。其第一個引數表示呼叫它的命令:目前是 amend 或 rebase。未來可能會傳遞其他依賴於命令的引數。
該鉤子在標準輸入上接收重寫提交的列表,格式如下:
<old-object-name> SP <new-object-name> [ SP <extra-info> ] LF
extra-info 再次依賴於命令。如果為空,則前面的空格也將被省略。目前,沒有命令傳遞任何 extra-info。
該鉤子總是在自動註釋複製(請參閱 git-config[1] 中的 "notes.rewrite.<command>")之後執行,因此可以訪問這些註釋。
以下命令特定註釋適用:
sendemail-validate
此鉤子由 git-send-email[1] 呼叫。
它接受這些命令列引數。它們是:1.儲存要傳送的電子郵件內容的檔案的名稱。2.儲存電子郵件 SMTP 頭的檔案的名稱。
SMTP 頭以與傳遞給使用者的郵件傳輸代理 (MTA) 完全相同的方式傳遞。實際上,傳遞給使用者 MTA 的電子郵件是 $2 的內容後跟 $1 的內容。
下面顯示了一些常見頭的示例。請注意大小寫和多行製表符結構。
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-validate 鉤子會檢查所有傳送的補丁(不包括封面信)是否可以在不發生衝突的情況下應用到上游倉庫的預設分支之上。為在應用給定系列的所有補丁後執行其他驗證步驟留出了一些佔位符。
fsmonitor-watchman
當配置選項 core.fsmonitor 設定為 .git/hooks/fsmonitor-watchman 或 .git/hooks/fsmonitor-watchmanv2(取決於鉤子版本)時,會呼叫此鉤子。
版本 1 接受兩個引數:版本號 (1) 和自 1970 年 1 月 1 日午夜以來的經過的納秒數。
版本 2 接受兩個引數:版本號 (2) 和用於標識自該標記以來的更改的令牌。對於 watchman,這將是時鐘 ID。此版本必須在標準輸出上輸出新的令牌,然後是一個 NUL,然後是檔案列表。
該鉤子應在標準輸出上輸出自請求時間以來可能已更改的所有工作目錄中檔案的列表。邏輯應該是包含性的,以免錯過任何潛在的更改。路徑應相對於工作目錄的根,並由單個 NUL 分隔。
包含實際上未更改的檔案是可以的。應包含所有更改,包括新建立和刪除的檔案。重新命名檔案時,應同時包含舊名稱和新名稱。
Git 將限制它檢查更改的檔案以及檢查未跟蹤檔案的目錄,這取決於路徑名。
告訴 git“所有檔案都已更改”的一種最佳化方法是返回檔名 /。
退出狀態決定 Git 是否會使用鉤子中的資料來限制其搜尋。發生錯誤時,它將回退到驗證所有檔案和資料夾。
p4-changelist
此鉤子由 git-p4 submit 呼叫。
p4-changelist 鉤子在使用者編輯了 changelist 訊息後執行。它可以透過 --no-verify 選項繞過。它接受一個引數,即儲存建議的 changelist 文字的檔名。以非零狀態退出將導致命令中止。
鉤子允許編輯 changelist 檔案,並可用於將文字規範化為某些專案標準格式。它還可以用於在檢查訊息檔案後拒絕提交。
有關詳細資訊,請執行 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 鉤子在 P4 中的提交成功後呼叫。它不接受引數,主要用於通知,不能影響 git p4 submit 操作的結果。
有關詳細資訊,請執行 git-p4 submit --help。