是否有办法自动从"partial"提交消息，而不是在实际执行提交时将其作为一个整体编写?
假设我们有3个文件要提交:file1，file2，file3，我们希望提交消息中有一个注释，描述为什么我们在一个文件中做了每个更改。有办法做到这一点吗?:
git add file1+信息:"改变file1…">
git add file2+信息:"改变file2…">
git add file3+信息:"改变file3…">
(编辑正如在评论中指出的那样，在使用git add时没有办法写提交消息。)
提交时，提交消息必须是先前消息的串联。整个提交消息应该是:
Changed file1...Changed file2...Changed file3...
这可能吗?提前感谢
您可以创建三个提交
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...
我将使用Nils Werner的方法，或者更准确地说，我自己的变体(进行三次提交，至少提交一半ok的消息:"不是一个有用的提交消息1)，要做到这一点，但有另一个方法。git commit命令有许多消息选项:
-c或-C，它们都接受任何(通过git rev-parse)解析为提交哈希ID的内容:提交提供消息;-m，它接受一个参数:这构成了消息的一部分;多个-m选项可以连接以提供完整的消息;-F，它以文件(路径)名或-作为参数:从给定的文件中读取提交消息，如果文件名为-，则从标准输入读取提交消息。
在所有情况下，消息都可以进一步编辑:-C表示--edit -c，您可以使用显式--edit。这些都是通过创建一个文件(.git/COMMIT_EDITMSG或类似的，取决于添加的工作树状态)，然后在文件上运行您选择的编辑器来工作的。
因此，要有一个运行git add并构建消息的别名，您可以选择自己的文件位置(如果您不介意稍微有点危险的话，您可以在.git中选择一个文件位置)，或者您可以在其他位置使用一个文件位置，以使它远离Git，以防Git出于某种原因决定吞食它)，并使用它来构建消息—到目前为止。然后运行git commit --edit -Fpath，以便Git从该消息启动，但允许进一步编辑它。您需要决定如何以及何时将清空这个累积文件:假设，在成功提交之后将是一个好时机。
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 <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
与实际差异比较:
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宏有一个错误，这是由于n <= 2时xalloca的特殊使用，并且在提供哈希ID的早期提交中添加了这种特殊使用，因此可以查看提交。还给出了实际的不良行为，以及在何处，何时以及如何观察到它以显示此修复程序修复了它的细节。
一个提交消息，只说"fix bug in tree- ff.c"不会有用;当没有"HAVE_ALLOCA_H"(一行摘要)时，"修复泄漏"将是;但是这个很好
嗯-实际上你创建了3次提交，所以你需要做的是:git rebase -i HEAD~3，打开最近3次提交(HEAD~后面的3次)的交互式重基。
在交互式的rebase屏幕中，你可以将所有的3个提交压缩成一个(最后一个)，在那里你可以写一个自定义的提交消息或将3个提交消息连接到一个。