3

我可能滥用 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 历史记录有很多只包含“工作”的毫无价值的评论。有没有办法自动组合所有具有相同消息的 git 提交，具体来说，所有带有 -m "work" 的顺序提交将组合成一个大提交 -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 不是一个选项，因为我也在离线/硬防火墙/等机器上工作......

4

2 回答 2

1

你没有滥用 git。这对于 git 来说绝对是一个很好的场景。

我建议将您的工作存储库设置A为包含（在可能现有的遥控器旁边origin）另外两个遥控器remote_B和remote_C. （在主机上B，C您设置了相应的裸存储库。）

这使您可以A使用git push remote_B. - 您可以通过在远程存储库中添加一个小钩子来进一步自动化这一点，以自动构建您的项目并运行测试。

这样，您只需推动并立即查看结果，而无需离开A。

现在对于您的实际问题：我首先强烈建议使用更有意义的提交消息。- 你通常在某个给定的主题上工作，或者尝试解决一些特殊的问题。- 给自己一个提示，提交是关于什么的。

一旦你得到你的测试工作使用git rebase -i。只要您没有更改上游（可能指向origin并且您仅在完成工作后才推送到那里），git rebase -i就会准确显示您尚未推送的那些提交，并允许您根据需要组合、重新排序和重命名它们。- 在这一点上，有一些有意义的提交消息能够以有意义的方式组合它们是非常有帮助的。

作为最后一步，当您对结果感到满意时，您会努力工作origin，一切都很好。:)

于 2013-11-14T08:46:21.653 回答
1

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

交互式变基意味着您有机会编辑变基的提交。您可以重新排序提交，也可以删除它们（清除坏的或其他不需要的补丁）。

[...]

如果要将两个或多个提交合并为一个，请将第二个和后续提交的命令“pick”替换为“squash”或“fixup”。如果提交有不同的作者，折叠的提交将归属于第一个提交的作者。折叠提交的建议提交消息是第一个提交的提交消息和使用“squash”命令的提交消息的串联，但省略了使用“fixup”命令的提交的提交消息。

将 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 所做的）是灾难的完美秘诀。特别是如果您尝试自动化此过程。

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

于 2013-11-14T02:07:07.590 回答