Question

我们的团队使用纯粹基于合并的git工作流程，我们正在讨论这种可能性只是要求所有团队成员在一个下午将所有工作推送到服务器并做一个重新定位服务器仓库的晚上。

我（想）我想自动做的是，只要所有提交只在同一组分支上并且并行提交的数量低于给定的阈值我想重新定义系列并删除合并提交。但我愿意接受建议吗？

任何人都知道怎么做？

Answer 1

在我看来，你应该避免重写历史只是为了让它“看起来不错”。真的没有意义。事实上，历史是对现实的更准确的表示，而git的报告工具都被设计为即使有很多小合并也很有用。

如果您对查看大量合并不感兴趣，可以将它们从许多报告任务中删除，例如

git log --no-merges

你提出的建议（一个变相的晚上，可能导致所有开发人员必须reset）似乎是为了工作而创造工作。

Answer 2

我不确定这有多简单。如果您执行rebase -i，它将尝试忽略所有合并，这些合并成功进行合并而不会发生冲突，但如果发生冲突则会停止并等待您。

另一方面，如果你将它作为rebase -i -p调用，它将保留合并，这是你在用户进行真正合并时所需要的，但是完全错过了这一点。

也许这两个命令的某些序列，只在你想要的时候保留合并，在这种情况下可以完成工作。

但是，我必须同意查尔斯的观点，认为历史反映现实远比使它“看起来漂亮”更有价值。事实上，一个提交是在不了解另一个提交的情况下进行的，在源代码的情况下，这可以告诉您为什么可能出现问题。

我们的团队使用纯粹基于合并的git工作流程

总是拉着--rebase（例如 git pull -r ）会有什么问题？如果您需要平面拓扑，最简单的方法是在您可以重新绑定时进行合并。

另外：你说你只想在“合并是干净的”时变平。我只是在这里推测，但我认为除了默认提交消息中的一个注释之外，git记录不会发生冲突，这可能还不存在。