我和一位同事正在使用带有单个远程源存储库的 git。我们都提交本地然后推送到原点。在我们工作的过程中，自然会有一些分歧。
一旦到了推到原点的时间，我怀疑我们可以合并本地，然后推到原点。我希望在没有描述合并的情况下获得一个相当直接的版本历史。
从相当复杂的版本地铁地图和不断重复出现的合并分支“主”消息来看，我猜我们做的事情不太正确。
- “合并分支到主控”消息的原因是什么？
- 如何简化此版本历史？
我感觉这个问题之前已经在这里得到了回答，但我无法完全理解我收集的信息。
问问题
7590 次
3 回答
25
我们有一个类似的案例。尽管我们使用中央主存储库，但我们经常有个别开发人员生成合并分支“主”消息。我们的解决方案是让开发人员git pull --rebase在从远程主存储库中提取时执行此操作。
于 2012-10-15T13:02:15.220 回答
12
我想你正在寻找git rebase.
从“保留真实历史”的角度来看，您的历史记录中记录的每个合并都是必需的。您的分支此时出现分歧，随后被合并（请注意两个分支如何具有独特的提交，因此无法进行快速转发。
如果你变基，当前的提示（包括你同事的更改）将成为新的分支点，除非他们在两者之间推动，否则你的更改可以通过快进应用，给人以线性开发的印象（但不-单调时间戳）。
于 2012-10-15T12:55:55.900 回答
0
你做的一切都是正确的。你在同步发展，你在不时整合同行的变化，git忠实地记录着这段历史。
虽然您可以通过变基“避免”合并提交，但通常最好坚持合并历史：每当您变基提交时，您实际上是在创建一个新提交，它对它是如何形成的说谎。而且，虽然这些谎言通常是善意的，但它们可能会在以后造成麻烦。如果您在每次重新提交时都跳过重新运行测试套件，则尤其如此。
我认为，“创造线性历史”的整个想法有点被误导了。你真的不想要线性历史。你想要一个真实的历史，一个每个提交都经过实际测试的历史。因为这使您以后可以运行git bisect有意义的结果。
TL;DR：不要改变你的习惯。他们本来就很好。将来您可能会感谢他们。
于 2020-01-17T15:04:47.760 回答