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