【发布时间】：2009-10-28 08:18:38
【问题描述】：
我们的团队使用纯粹基于合并的 git 工作流程，我们正在讨论这种可能性 只是要求所有团队成员在一个下午将所有工作推送到服务器，并在一个晚上重新定位服务器存储库。
我（认为）我想自动做的是，只要所有提交都只在同一组分支上并且并行提交的数量低于给定阈值，我想重新设置系列并删除合并提交。但我愿意接受建议？
有人知道怎么做吗？
【问题讨论】：
【发布时间】：2009-10-28 08:18:38
【问题描述】：
在我看来，你应该避免为了让它“看起来不错”而重写历史的诱惑。真的没有意义。历史实际上是对现实的更准确表示，并且 git 的报告工具都被设计成有用的，即使有很多小合并。
如果您对查看大量合并不感兴趣，您可以从许多报告任务中禁止它们，例如
git log --no-merges
您的提议（一个变基之夜，大概导致所有开发人员不得不reset）似乎是为了工作而创造工作。
【讨论】：
-
+1 以获得良好的焦点 - “现实咬伤”。 Git 提供了如此巨大的工具空间和如此多的选项，很难知道什么是聪明的，什么不是。我坚信不要为工作而创造工作，所以我可能会坚持你的建议。
我不确定这有多简单。如果您执行rebase -i，它将尝试忽略所有合并，这对于没有冲突的合并成功，但如果发生冲突则停止并等待您。
另一方面，如果您将其调用为rebase -i -p，它将保留合并，这是您在用户进行真正合并时想要的，但否则完全错过了这一点。
也许这两个命令的一些序列，只在你想要的时候保留合并，可以在这种情况下完成工作。
不过，我必须同意查尔斯的观点，让历史反映现实比让它“看起来漂亮”更有价值。事实是，一个提交是在不知道另一个提交的情况下进行的，对于源代码，这可以告诉你为什么可能会出错。
我们的团队使用纯粹基于合并的 git 工作流程
总是用--rebase 拉动有什么问题（例如git pull -r）？如果你想要一个扁平的拓扑，最简单的方法是当你可以变基时不要合并。
另外：你说你只想在“合并是干净的”时变平。我只是在这里推测，但我认为除了默认提交消息中的注释之外，git 不会记录冲突，这可能仍然不存在。
【讨论】：