为什么有这么多项目更喜欢“ git rebase”而不是“ git merge”？

使用DVCS的优点之一是编辑提交合并工作流（通常由CVCS强制执行的编辑合并提交工作）。允许将每个唯一更改记录在与合并无关的存储库中，可确保DAG准确反映项目的真实血统书。

为什么这么多网站谈论要“避免合并提交”？合并合并前合并或合并后合并是否会使隔离回归，还原过去的更改等变得更加困难？

澄清点： DVCS的默认行为是创建合并提交。为什么有那么多地方谈论看到隐藏这些合并提交的线性开发历史的愿望？

人们希望避免合并提交，因为这会使日志更漂亮。说真的 看起来就像是他们一起成长的集中式日志，在本地他们可以在一个分支中进行所有开发。除了这些美学之外，没有任何好处，除了您提到的那些缺点外，还有其他一些缺点，例如，不通过“中央”服务器直接从同事那里拉动就容易产生冲突。

用两个词： git bisect

线性历史记录可让您查明错误的实际来源。

def bar(arg=None):
    pass

def foo():
    bar()

分支1进行了一些重构，使其arg不再有效：

def bar():
    pass

def foo():
    bar()

分支2具有需要使用的新功能arg：

def bar(arg=None):
    pass

def foo():
    bar(arg=1)

不会有合并冲突，但是引入了一个错误。幸运的是，这一特定程序将在编译步骤中被发现，但是我们并不总是那么幸运。如果该错误表现为意外行为，而不是编译错误，那么我们可能会在一两个星期内找不到它。到那时，git bisect去救援！

真是的 这是它所看到的：

(master: green)
|             \_________________________
|                \                      \
(master: green)  (branch 1: green)     (branch 2: green)
|                 |                     |
|                 |                     |
(master/merge commit: green)            |
|                         ______________/
|                        /
(master/merge commit: red)
|
...days pass...
|
(master: red)

因此，当我们发送git bisect找到破坏构建的提交时，它将查明合并提交。好吧，这有所帮助，但实际上是指一包提交，而不是一个。所有祖先都是绿色的。另一方面，通过重新基准化，您可以获得线性历史记录：

(master: green)
|
(master: green)
|
(all branch 1 commits: green)
|
(some branch 2 commits: green)
|
(branch 2 commit: red)
|
(remaining branch 2 commits: red)
|
...days pass...
|
(master: still red)

现在，git bisect将指向破坏构建的确切功能提交。理想情况下，提交消息将解释什么意图足够好以进行另一次重构并立即修复该错误。

仅当维护人员没有编写所有代码时，这种影响才会在大型项目中加剧，因此他们不必记住为什么要进行任何给定的提交/每个分支的用途。因此，查明确切的提交（然后能够检查其周围的提交）是很有帮助的。

也就是说，我（当前）仍然喜欢合并。重新部署到发行分支将为您提供与配合使用的线性历史记录git bisect，同时保留日常工作的真实历史记录。

简而言之，因为合并通常是出错的另一个地方，并且只需出错一次就可以使人们非常害怕再次对其进行处理（如果可能，请害羞两次）。

假设我们正在一个新的“帐户管理”屏幕上工作，事实证明在“新帐户”工作流程中发现了一个错误。好的，我们采取两种不同的方式-您完成帐户管理，然后使用“新帐户”修复该错误。由于我们都在处理帐户，因此我们一直在使用非常相似的代码-也许我们甚至不得不调整相同的代码段。

现在，此刻我们有两个不同但完全正常工作的软件版本。我们都对更改进行了提交，我们都已尽职地测试了代码，并且独立地我们非常有信心我们已经完成了出色的工作。怎么办？

好了，是时候合并了，但是...废话，现在发生了什么？我们很可能会从两个工作软件套件转变为一个统一的，可怕的新漏洞软件，在该错误软件中，您的帐户管理不起作用，新帐户也已失效，我什至不知道旧错误是否仍然存在。

也许该软件很智能，它说存在冲突，并坚持要求我们提供指导。好吧，废话-我坐下来做，看看你添加了一些我不立即理解的复杂代码。我认为这与我所做的更改相冲突...我问你，等一下你检查一下，就会看到你不理解的代码。我们中的一个或两个都必须花时间坐下来，对适当的合并进行哈希处理，并可能重新测试整个dang事物，以确保我们没有破坏它。

同时，其他8个人都像他们的施虐者一样提交代码，在我知道我们发生合并冲突之前，我做了一些小错误修复，然后提交了这些错误，可以肯定，这是个休息的好时机，也许您下午休息或参加会议或其他任何活动。也许我应该去度假。或改变职业。

因此，为了逃避这一噩梦，有些人变得非常害怕承诺（还有什么新东西，对吗？）。在这种情况下，我们很自然地会产生厌恶情绪-除非我们认为自己很烂并且反正会把它搞砸，在这种情况下，人们开始鲁acting地放弃行动。叹

所以你去了。是的，现代系统的设计旨在减轻这种痛苦，并且应该能够轻松地进行还原，变基，变基，freebase和hanglide等。

但是，这还需要更多工作，我们只想按一下微波炉上的按钮，然后在有时间找到叉子之前就完成4道菜的餐点，这一切实在令人非常难以满足-代码是工作，高效，有意义，但是优雅地处理合并就不算在内。

通常，程序员必须开发出良好的工作记忆，然后趋向于在解决问题后立即忘记所有那些垃圾名称和变量名称以及作用域，并处理合并冲突（或更糟糕的是，错误处理的合并）是提醒您死亡的邀请。

变基提供了一个移动分支点，该分支点简化了将更改推回基线的过程。这使您可以将长时间运行的分支视为本地更改。如果不重新设置基准，分支将从基准累积更改，这些更改将包含在合并回基准中的更改中。

合并会将基线留在原始分支点。如果您从分支所在的行合并了几个星期的更改，则分支点现在会有很多更改，其中许多更改将在基线中。这使得很难识别分支中的更改。将更改推回基线可能会产生与您的更改无关的冲突。在发生冲突的情况下，可以推动不一致的更改。进行中的合并需要努力进行管理，并且松散更改相对容易。

Rebase将您的分支点移动到基准上的最新修订版。您遇到的任何冲突仅是您的更改。推动变更要简单得多。在本地分支机构中，通过执行其他重新基准处理冲突。在推送冲突的情况下，最后一次推送他们的更改将需要解决他们的更改问题。

自动化工具在确保合并代码能够编译和运行方面变得越来越好，从而避免了语法冲突，但是它们不能保证不存在合并可能引起的逻辑冲突。因此，“成功”合并会使您产生虚假的信心，而实际上却不能保证任何事情，因此您必须重做所有测试。

正如我所看到的那样，分支和合并的真正问题在于，它把众所周知的东西踢了下去。它可以让您说“我将在自己的小世界里工作”一周，然后解决以后出现的任何问题。但是，修复bug总是更快/更便宜。到所有代码分支开始合并时，您可能已经忘记了所做的某些细微差别。

将上述两个问题放在一起，您可能会发现自己处在一种简单易行的情况下，即每个人都在同一根主干上工作，并在出现冲突时不断解决冲突，即使它们会使主动开发的速度变慢了一点。

另一个相关的要点是：通过重新定标，我可以轻松地在我的发布分支中挑选或还原功能。

在任何答案中都没有说三件事：

• 在分支内扩散：

  • 当存在合并提交时，在分支中的任意一对提交之间进行区分变得非常困难。

• 一次合并一项：

  • 解决两个分支之间的差异时，合并通常会同时发生，并且任何合并冲突都将由您处理，而无需担心具体冲突由哪个具体提交引起。如果您重新设置基准，则重新基准设置将在发生冲突时停止，并允许您在该情况下解决它。

• 推送前清理：

  • 如果您犯了一个错误的提交，以后需要修复，如果您尚未推送交互式基础，则可以合并/分割/更改/移动提交。尽管您仍然可以执行合并操作，但是要合并/拆分/更改/移动合并边界将变得非常困难。