为什么合并后重新变基不是一个好习惯？

Question

我正在阅读Pro Git书，并陷入重新定标的问题。

下面是场景：

步骤1

第2步

我们可以看到遥控器进行了重新设置（不是一个好习惯，因为其他人可能会基于它进行工作）。

然后作者说：

  

如果执行git pull，将创建一个包含两行历史记录的合并提交，并且您的存储库将如下所示：

我不明白为什么git pull会自动合并C4和C7，因为我们知道通常git pull不会为您进行合并，您必须通过您自己，那么为什么在这种情况下git pull为您合并？

编辑：

对不起，我打打字并想得太快了，我说的是git fetch不会自动合并，git pull确实会合并，并且git pull = git fetch + {{ 1}}。

所以我的问题是，为什么作者说：

为内容重新设置基础时，您将放弃现有的提交并创建相似但不同的新提交。如果您将提交推送到某个地方，而其他人则将其拉下并基于它们进行工作，然后再使用git rebase重写这些提交，然后再次将其上推，那么您的协作者将不得不重新合并其工作，并且当您尝试执行以下操作时，事情将会变得混乱将他们的工作重新归还给您。

我真的很困惑，如果开发人员在合并后没有进行基础调整，因此我们将第一步中的图片作为开始，那么开发人员会在{{之后添加一个名为git merge的新提交。 1}}，然后如果我在计算机上调用C8，C6仍需要与git pull合并，因此无论如何都必须重新合并工作，这是不可避免的事情会变得混乱，那是什么问题呢？

Answer 1

将git pull视为git fetch [branch] && git merge [branch]的别名

Answer 2

我认为您只是误解了这本书的内容。

  

因此无论如何都将不得不重新合并工作，这是不可避免的，事情会变得混乱，那么这又是什么问题呢？

这不是一团糟，只是在进行合并。合并并不麻烦，合并很容易。没问题。

一个混乱的情况是，当其他人拥有您的存储库副本时，您通过重新定基来重写存储库的历史记录，然后尝试从其他人的副本中合并。它们的副本仍包含您的回购中不再存在的旧提交，因为您具有等效的内容，但通过重新创建创建的提交不相同。它变得混乱，因为它将尝试合并不需要合并的提交。

您正在用书来描述在重新定基后事物为何混乱的原因，然后尝试在假设的情况下理解它们而不重新定基。当然，这没有任何意义，因为您正在考虑一种完全不同的情况。

Answer 3

您应该在Git pull results in extraneous "Merge branch" messages in commit log处查找此问题，用户戳可以很好地解释合并的原因。

Answer 4

如Mauricio Machado's answer所示，默认情况下，git pull实际上是fetch和merge操作别名。

您可能需要配置拉取来进行重新设置：

$ git config --global pull.rebase true

Answer 5

重新设置基准是一项允许修改历史记录的操作。这意味着您不应该在与其他开发人员（例如，开发分支）一起工作的公共分支上这样做。

为什么？

因为这很可能会导致冲突，我们不愿意解决，因为这完全是手动的事情。你可以在这里读更多关于它的内容： Atlassian Tutorial - Git merge conflicts

另一方面，这并不意味着您根本不应该使用rebase。我每天都使用它来同步我的功能分支和开发。我也总是使用带有-rebase 选项的pull。

Answer 6

事情可能会变得混乱，因为如果您已经推送了提交，然后对影响该提交的本地进行了重新设置，则该提交将会更改。

考虑此问题：合并在您的前面添加内容，而变基则在您的后面添加内容

因此，如果您更改了后面的内容，现在的内容也会发生变化。

提交只是指向以前提交（我们称为父提交）的链接列表。如果您更改父母，那将更改提交本身，更改其SHA，这意味着这是一个全新的提交。

说你有

[some-branch]   D -> E
                       \
  [HEAD] = A -> B -> C -> E

您需要获得D，您可以：

REBASE

       [some-branch]   D -> E
                         \
  [HEAD] = A' -> B' -> C' -> D -> E

或合并

[some-branch]   D -> E
                  \
       [HEAD] = D -> A -> B -> C -> E

（我知道那里缺少一个合并提交）

  

为什么会变得混乱？因为如果您在获得D之前 推了您的分支，并且有人开始从其工作，那么他们的本地分支和被推（远程）的分支考虑到他们马上意识到发生了什么，就发散了，并解决了问题。

     

为什么更干净？它不会创建合并提交，因此会产生更清晰易读的历史记录。只有当您绝对确定自己是该分支机构中唯一的员工时，这才是安全的。

     

路要走吗？只需合并具有所需提交的分支，这将在最后一个提交之前创建一个新的提交，因此一旦按下，分支将兼容。