有什么方法可以從“部分”提交訊息中自動撰寫提交訊息，而不是在實際提交時將其作為一個整體撰寫？
假設我們有 3 個要提交更改的檔案：file1、file2、file3并且我們希望提交訊息有一個注釋來描述我們為什么在檔案中進行每個更改。有沒有辦法做這樣的事情？：
git add file1 訊息：“已更改檔案 1...”
git add file2 訊息： “已更改檔案 2...”
git add file3 訊息：“已更改檔案 3...”
（編輯：正如評論中所指出的，使用時無法撰寫提交訊息git add。這只是一個幫助澄清問題的示例。）
提交時，提交訊息必須是先前訊息的串聯。整個提交資訊應該是：
Changed file1...Changed file2...Changed file3...
這甚至可能嗎？提前致謝
uj5u.com熱心網友回復：
您可以創建三個提交
git add file1 && git commit -m "Changes to file1..."
git add file2 && git commit -m "Changes to file2..."
git add file3 && git commit -m "Changes to file3..."
然后做一個互動式rebase
git rebase -i HEAD~3
您將看到一個編輯器，其中包含
pick 9c67656 Changes to file1...
pick b54fa87 Changes to file2...
pick e5cf43d Changes to file3...
將第二個和第三個更改pick為squash
pick 9c67656 Changes to file1...
squash b54fa87 Changes to file2...
squash e5cf43d Changes to file3...
并退出。您將看到
# This is a combination of 3 commits.
# This is the 1st commit message:
Changes to file1...
# This is the commit message #2:
Changes to file2...
# This is the commit message #3:
Changes to file3...
您可以將其更改為您喜歡的任何內容，例如
Changes to file1...
Changes to file2...
Changes to file3...
uj5u.com熱心網友回復：
我會使用Nils Werner 的方法，或者更準確地說是我自己的變體（使用至少半途確定提交訊息進行三次提交：“修改檔案 1”不是有用的提交訊息1），來做到這一點，但是有是另一種方法。該git commit命令有許多訊息選項：
-c或-C, 兩者都接受任何決議 (viagit rev-parse) 為提交哈希 ID 的內容：該提交提供訊息；-m，它接受一個引數：這構成了訊息的一部分；-m可以連接多個選項以提供完整的訊息；-F，它接受一個檔案（路徑）名稱或-作為引數：提交訊息是從給定的檔案中讀取的，如果檔案名是-.
在所有情況下，訊息都可以進一步編輯：-C意味著--edit -c并且您可以使用明確的--edit. 這些都是通過創建一個檔案（.git/COMMIT_EDITMSG或類似的，取決于添加的作業樹狀態）然后在檔案上運行您選擇的編輯器來作業的。
因此，要擁有一個運行git add并生成訊息的別名，您將選擇自己的檔案位置——.git如果您不介意稍微危險地生活，您可以在里面選擇一個，或者您可以在其他位置使用一個以遠離它來自 Git，以防 Git 出于某種原因決定使用它——并使用它來構建到目前為止的訊息。然后運行，以便 Git 從到目前為止的訊息開始，但允許您進一步編輯它。您需要決定如何以及何時清空此累積檔案：大概，在成功提交之后將是一個好時機。git commit --edit -F path
1一個好的提交資訊不應該重復提交所做的事情。這是很容易發現的由計算機對您使用git log -p或git show --name-status或什么的。提交訊息應解釋您進行更改的原因：
commit 637799bf0ab72a509e1f2b29ee6ab3367eefbff9
Author: Carlo Marcelo Arenas Belón <carenas gmail.com>
Date: Thu Sep 16 01:55:22 2021 -0700
tree-diff: fix leak when not HAVE_ALLOCA_H
b8ba412bf7 (tree-diff: avoid alloca for large allocations, 2016-06-07)
adds a way to route some bigger allocations out of the stack and free
them through the addition of two conveniently named macros, but leaves
the calls to free the xalloca part, which could be also in the heap,
if the system doesn't HAVE_ALLOCA_H (ex: macOS and other BSD).
Add the missing free call, xalloca_free(), which is a noop if we
allocated memory in the stack frame, but a real free() if we
allocated in the heap instead, and while at it, change the expression
to match in both macros for ease of readability.
This avoids a leak reported by LSAN while running t0000 but that
wouldn't fail the test (which is fixed in the next patch):
SUMMARY: LeakSanitizer: 1034 byte(s) leaked in 15 allocation(s).
Signed-off-by: Carlo Marcelo Arenas Belón <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
將此與實際差異進行比較：
diff --git a/tree-diff.c b/tree-diff.c
index 1572615bd9..437c98a70e 100644
--- a/tree-diff.c
b/tree-diff.c
@@ -21,7 21,9 @@
ALLOC_ARRAY((x), nr); \
} while(0)
#define FAST_ARRAY_FREE(x, nr) do { \
- if ((nr) > 2) \
if ((nr) <= 2) \
xalloca_free((x)); \
else \
free((x)); \
} while(0)
差異顯示了更改的簡單機制。提交文本提供背景關系：在FAST_ARRAY_FREE宏有一個bug，由于特殊用途的xalloca時候n <= 2，而且在加入特殊用途較早提交其哈希ID設定，這樣一方面可以看看那個承諾為好。還給出了實際的不良行為，以及在何處、何時以及如何觀察以表明此修復程式修復它的細節。
只說“修復 tree-diff.c 中的錯誤”的提交訊息沒有用；一個說“當沒有 HAVE_ALLOCA_H 時修復泄漏”——一行總結——將是；但這個很好。
uj5u.com熱心網友回復：
嗯 - 實際上你創建了 3 個提交，所以你需要做的是：
git rebase -i HEAD~3打開最后 3 個提交的互動式 rebase（HEAD~ 之后的 3 個）。
在互動式 rebase 螢屏中，您可以將所有 3 個提交壓縮為 1 個（最后一個），然后您可以撰寫自定義提交訊息或將 3 個提交訊息連接為 1。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/332863.html
標籤：混帐