自动重写完整的 git 历史记录以摆脱简单的合并提交
我们的团队使用纯粹基于合并的 git 工作流程，我们正在讨论这种可能性 只是要求所有团队成员在一个下午将所有工作推送到服务器，并用一晚上的时间重新调整服务器存储库的基础。
我（认为）我想要自动执行的是，只要所有提交仅在同一组分支上并且并行提交的数量低于给定阈值，我想重新调整系列并删除合并提交（s）。但我愿意接受建议？
有人知道该怎么做吗？
Our team uses a purely merge-based git workflow, and we're discussing the possibility
of just asking all team members to push all work to server one afternoon and do an evening of rebasing the server repo.
I (think) what I would like to do automatically is that as long as all the commits are only on the same set of branches AND the number of parallel commits are below a given threshold I would like to rebase the series and remove the merge commit(s). But I am open to suggestions ?
Anyone know how to do this ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我看来，你应该避免仅仅为了让它“看起来不错”而重写历史的诱惑。确实没有意义。事实上，历史是对现实的更准确的表示，并且 git 的报告工具都被设计为即使有大量小的合并也很有用。
如果您对查看大量合并不感兴趣，您可以从许多报告任务中抑制它们，例如
您所提议的内容（一晚的变基，可能导致所有开发人员必须
重置）似乎就像为了工作而创造工作一样。In my opinion you should avoid the temptation to re-write history just to make it "look nice". There really is no point. The history, as it is, is a more accurate representation of reality and git's reporting tools are all designed to be useful even with lots of little merges.
If you're not interested in viewing a lot of merges you can suppress them from many reporting tasks, e.g.
What you're proposing (an evening of rebasing, presumably causing all developers to have to
reset) seems like creating work for work's sake.我不确定这有多简单。如果您执行
rebase -i，它将尝试忽略所有合并，这对于没有冲突的合并会成功，但如果存在冲突，则会停止并等待您。另一方面，如果您以
rebase -i -p的形式调用它，它将保留合并，这正是用户进行真正合并时所希望的，但否则就完全错过了要点。也许这两个命令的某种顺序，仅在您想要的时候保留合并，可以在这种情况下完成工作。
不过，我必须同意查尔斯的观点，让历史反映现实比让它“看起来漂亮”更有价值。事实是，一项提交是在不了解另一项提交的情况下进行的，对于源代码，这可以告诉您为什么会出现问题。
总是使用
--rebase拉取（例如git pull -r）有什么问题？如果您需要扁平拓扑，最简单的方法是在可以变基时不要合并。另外：你说你只想在“合并干净”的情况下压平。我只是在这里推测，但我不认为 git 会在事后记录冲突，除了默认提交消息中的注释之外，该注释可能不存在了。
I'm not sure how simple this could be. If you do a
rebase -i, it will attempt to ignore all merges, which succeeds for merges without conflict, but stops and waits for you if there was a conflict.If you invoke it as
rebase -i -p, on the other hand, it will preserve merges, which is what you want when the user did a real merge, but completely misses the point otherwise.Perhaps some sequence of the two commands, preserving merges only when you want to, could get the job done in this case.
I must agree with Charles, though, that having the history reflect reality is much more valuable than making it "look pretty". The fact is, one commit was made without knowledge of the other, and in the case of source code this can tell you why something might have gone wrong.
What's wrong with always pulling with
--rebase(e.g.git pull -r)? If you desire a flat topology, the simplest way is not to merge when you could rebase.Also: you say you only want to flatten if "the merge is clean". I'm just speculating here, but I don't think git records conflicts after the fact other than a note in the default commit message, which may not still be there.