git - 将 git 提交与相同的消息结合起来？

Question

我可能滥用 git 并以它从未被设计使用的方式使用它。我是一个团队规模的唯一开发人员，我在多台机器上进行开发。比如我在机器A上写代码，需要在机器B和机器C上测试(并重新编译)代码。我做快速开发(例如，每分钟提交一次，然后跨到机器B/C上测试) .

因此，我的许多提交都有有意义的消息，特别是我经常这样做:

机器A

git add -u
git commit -m "work"
git push

机器B/C

git pull
make
./run_tests

哦不!它不起作用...回到机器 A 并在 1 分钟后再次提交。

因此，正如您想象的那样，我的 git --log 历史记录有很多毫无值(value)的评论，它们只包含“工作”。有没有一种方法可以自动 merge 所有具有相同消息的 git 提交，具体来说，所有带有 -m "work"的顺序提交将 merge 为一个大提交 -m "big work"。

谢谢。

明确地说，我的评论历史(回溯 2 年)是这样的:

work
work
work
work
OMG THIS actually works.
work
work
work
OMG we solved a huge problem... we should call this v1.0
work
work
work

我想自动压缩所有“工作”消息，使其变成类似这样的内容:

work
OMG THIS actually works.
work
OMG we solved a huge problem... we should call this v1.0
work

etc...

侧面，至于为什么我这样滥用 git，基本上我将它用作 ctrl-s 功能......我也在 20 台机器上开发并且需要一种有效的方式在每分钟左右更改后共享代码。 NFS 不是一个选项，因为我也在离线/硬防火墙/等机器上工作......

Answer 1

您描述的工作流程与 git-rebase 中描述的非常相似交互模式手册页:

Rebasing interactively means that you have a chance to edit the commits which are rebased. You can reorder the commits, and you can remove them (weeding out bad or otherwise unwanted patches).

[...]

If you want to fold two or more commits into one, replace the command "pick" for the second and subsequent commits with "squash" or "fixup". If the commits had different authors, the folded commit will be attributed to the author of the first commit. The suggested commit message for the folded commit is the concatenation of the commit messages of the first commit and of those with the "squash" command, but omits the commit messages of commits with the "fixup" command.

将 git-rebase 示例应用到你的案例中，你必须做类似的事情

$ git rebase --interactive HEAD~13 # to fix last 12 commits

编辑器将启动当前分支中的所有提交:

pick deadaaa work
pick deadbbb work
pick deadccc work
pick deadddd work
pick deadeee OMG THIS actually works.
pick deadfff work
pick dead000 work
...

您需要做的是将您想要加入上层提交的提交的“pick”更改为“fixup”:

pick deadaaa work
fixup deadbbb work
fixup deadccc work
fixup deadddd work
pick deadeee OMG THIS actually works.
pick deadfff work
fixup dead000 work
...

清理之后，最安全的做法是从您的其余机器上重新克隆此存储库。因为在共享存储库上搞乱提交(就像 git rebase 那样)是灾难的完美秘诀。特别是如果您将尝试自动化此过程。

编辑: 当您控制了存储库的所有副本时，这应该不是问题。在修改 master 分支之前，只需确保所有副本都同步即可。在你完成更新所有副本后，强制推/pull 再次同步。如果出现问题“从上游 Rebase 恢复”git-rebase man 部分应该有所帮助。