自动重写完整的Git历史记录以消除简单的合并提交

在我看来,你应该避免为了让历史看起来“好看”而重写历史的诱惑。真的没有意义。事实上,历史更准确地反映了现实情况,而Git的报告工具都被设计成即使有很多小的合并也有用。

如果您对查看大量合并不感兴趣,可以从许多报告任务中抑制它们,例如

git log --no-merges

你所提议的(一个晚上的重新平衡,可能导致所有开发人员不得不 reset )似乎是为了工作而创造工作。

我不知道这有多简单。如果你做了 rebase -i ,它将尝试忽略所有合并,这些合并在没有冲突的情况下成功,但如果发生冲突,它将停止并等待您。

如果你把它当作 rebase -i -p 另一方面,它将保留合并,当用户进行真正的合并时,这是您想要的,但完全忽略了这一点。

也许这两个命令的某个序列(仅在需要时保留合并)可以在这种情况下完成任务。

不过,我必须同意查尔斯的观点,让历史反映现实比让它“看起来漂亮”更有价值。事实上,一次提交是在不知道另一次提交的情况下进行的,而在源代码的情况下,这可以告诉您为什么会发生错误。

我们的团队使用完全基于合并的Git工作流

总是拉的有什么问题 --rebase (例如) git pull -r )?如果你想要一个扁平的拓扑结构,最简单的方法是当你可以重新平衡时不要合并。

另外:你说你只想在“合并是干净的”的情况下变平。我只是在推测,但是我认为Git不会记录事实之后的冲突,除了默认提交消息中的一个注释之外,这个消息可能不存在。