我不明白为什么要设计成这样。当我提交一个正在进行的工作(WIP)时,它代表着尚未编译或尚未完成的代码。当我最终提交“终于可行!”的提交记录并在合并之前压缩时,将这些 WIP 提交记录合并到“终于可行!”的提交记录中,而不是与之前的提交记录合并,更有意义。压缩 WIP 实质上“打破”了我知道不能编译的先前的提交记录。
为了解决这个问题,我的工作流程是将从“可行!”到第一个 WIP 提交记录之前的所有提交记录都压缩。但这不是很愚蠢吗?其他人怎么做,使得将 WIP 压缩到以前的提交记录变得有意义呢?
在当前的Git版本中(从2.32.0版本开始包含;在commit 9e3cebd97cbd47909e683e617d5ffa2781f0adaa引入),您可以在交互式rebase的待办事项列表中指定fixup -C
来选择用于压缩/修复的提交消息,例如:
pick 456789 Finished topic XYZ
pick abcdef WIP your incomplete commit
fixup 012345 WIP resolving compiler errors
fixup 6789ab WIP adding unit tests
fixup cdef01 WIP refactoring
fixup -C 234567 Implemented feature ABC
pick 89abcd Another feature
-c
而不是-C
:pick 456789 Finished topic XYZ
pick abcdef WIP your incomplete commit
fixup cdef01 WIP refactoring
fixup -c 234567 Implemented feature ABC
pick 89abcd Another feature
可以使用exec
行执行任何其他附加步骤:
pick 456789 Finished topic XYZ
pick abcdef WIP your incomplete commit
fixup cdef01 WIP refactoring
fixup -C 234567 Implemented feature ABC
exec git commit --amend --reset-author -CHEAD
pick 89abcd Another feature
在 Git 2.32.0 之前,您可以通过以下待办事项列表解决此限制:
pick 456789 Finished topic XYZ
pick abcdef WIP your incomplete commit
fixup cdef01 WIP refactoring
fixup 234567 Implemented feature ABC
exec git commit --amend -C 234567 # commit id from line above
pick 89abcd Another feature
将最新的提交压缩到旧的提交中应该会保留两者的差异。仅仅因为你“挑选”了旧的提交,并不意味着你修复工作中的错误的新工作被遗漏了。
尝试使用git rebase -i HEAD~4
,但将4替换为您想要合并的提交数,从HEAD开始,这可能是您的工作状态。
有一个很好的指南介绍如何使用交互式rebase,可以在http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html上找到。
那为什么不使用git reset --soft
,将HEAD
(只有HEAD
)重置回第一个WIP,并从那里提交(使用最近和最终工作的WIP的索引和工作树)。
这样,您可以快速将这些提交合并在一起。
请参阅“如何使用git合并我的最后X个提交?”了解更多信息。
这与我在“git reset --soft的实际用途?”中得出的结论相一致:
每次:
- 您对最终结果(工作树和索引方面)感到满意
- 您对带您达到该结果的所有提交都不满意:
git reset --soft
就是答案。
sequencer
:尽管第一行无效,仍然完成解析待办事项列表。
签名:Alex Henrie
在编辑待办事项列表之前,会将其重写以缩短被选择的提交的OID,并附上有关编辑列表的建议。在ddb81e5("rebase-interactive
: use todo_list_write_to_file()
in edit_todo_list()
",2019-03-05,Git v2.22.0-rc0 -- merge)之前,如果无法解析现有的待办事项列表,则初始重写也会被跳过。
这导致的不幸结果是,如果在初始编辑后无法解析列表,则当用户重新编辑列表时给出的建议是错误的。
此更改依赖于todo_list_parse_insn_buffer()
即使无法解析也返回整个待办事项列表。
不幸的是,如果列表以"fixup"命令开头,则会被截断,剩余的行会丢失。
通过在初始"fixup"提交后继续解析,解决此问题,就像我们在看到其他无效行时所做的那样。
git merge -i --update-refs
选项怎么样? - VonCgit merge -i
?你是不是想说git rebase -i
? :) 我同意--update-refs
是好的和有用的(https://dev59.com/OnE85IYBdhLWcg3whUBr),但它并不适用于这个问题。我的理解是这个问题是关于提交信息而不是其它分支或引用的。 - knittlrebase --update-refs
是 Git 中非常受欢迎和有用的新增功能。这是我工作流程中一直缺少的东西 :) - knittl-c
(小写)也可以让您修改提交消息。 - jmbeck-c
。已经更新了我的回答! - knittl