自动重写完整的git历史记录以摆脱简单的合并提交

Question

我们的团队使用纯粹基于合并的git工作流程，并且我们正在讨论仅需要所有团队成员在一天下午将所有工作推送到服务器的可能性 一个重新安装服务器回购的晚上。我想我会自动做的是，只要所有的提交只在同一组分支，并行提交的数量低于给定的阈值，我想重新设置系列和删除合并提交。但我愿意接受建议？

任何人都知道如何做到这一点？

Answer 1

在我看来，你应该避免重写历史的诱惑，以使其“看起来不错”。真的没有意义。历史就是一个更准确的现实表现，而git的报告工具全都设计成即使有很少的合并也很有用。

如果您不想查看大量合并，可以将它们从许多报告任务中取消，例如，

git log --no-merges 

你提出什么（垫底的一个晚上，大概是造成所有的开发人员都reset）似乎是创建工作的缘故工作。

Answer 2

我不知道这可能有多简单。如果您执行rebase -i，它将尝试忽略所有合并，合并成功时不会发生冲突，但会在发生冲突时停止并等待您。

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

也许这两个命令的某些顺序，只在需要时才保留合并，可以在这种情况下完成任务。

但是，我必须同意查尔斯的观点，即让历史反映现实比让它“看起来很漂亮”更有价值。事实是，一个提交是在没有其他知识的情况下做出的，而在源代码的情况下，它可以告诉你为什么可能出现了错误。

我们的团队使用了一个纯粹的合并基础的混帐工作流程

这有什么错总是--rebase（例如git pull -r）拉？如果你想要一个平坦的拓扑结构，最简单的方法就是在你可以重新绑定时不合并。

另外：你说你只想“扁平化”，如果“合并是干净的”。我只是在这里进行推测，但我不认为git记录会在默认提交消息中的记录之外发生冲突，这可能不会在那里。