Github分支总是在前面或后面

Question

我们有一个2分支回购。一个名为dev，另一个名称为prd。我们按照正常流程发送来自我们福克斯的请求，将我们的更改与dev合并。之后，从dev到prd进行拉取请求并合并，以使这些更新成为现场。

的问题是在一个点而合并来自dev到prd，所述prd分支永久成为“前方”的dev（有时提交提前叠加）。如果我们试图将prd合并回dev，会发生相反的效果，除非它会落后。

我们怎样才能让两个分支重新同步，因为这些状态导致团队混淆。

注意：它在前面没有文件更改，只有提交正在被记录。

Answer 1

由于合并Git的工作方式，这是正常的行为。

在Git中，合并与其他任何提交一样，它只有两个（或更多）父项。它包含合并内容所需的更改。当您将一个分支合并到另一个时，源分支不会更改。所以当dev被合并为prod时，只有prod会改变。

下面是一个视觉示例。假设dev在第3次提交时分支产品。prod现在是第7次提交，dev是E.检出。

1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 [prod] [HEAD] 
      \ 
      A -- B -- C -- D -- E [dev] 

当dev与命令git merge dev合并为prod时，这就是结果。

1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 [prod] [HEAD] 
      \     /
      A -- B -- C -- D -- E [dev] 

在新的合并结果提交父母均为7和E.它包含了所有必要的修改，以把它们合并起来。 prod被推进到这个新的提交。 dev仍然在E.

这就是为什么prod总是会在合并之后领先dev的原因。例外是“快进”。假设发生这种情况。

1 -- 2 -- 3 -- 4 [prod] [HEAD] 
       \ 
       A -- B -- C [dev] 

dev在产品4处分支出去。已经完成了关于dev但不是产品的工作。 prod被检出。当git merge dev完成后，git会识别出不需要合并，并执行“快进”。

1 -- 2 -- 3 -- 4 
       \ 
       A -- B -- C [dev] [prod] [HEAD] 

prod被推进到C，dev是同一个地方。您可以使用git merge --no-ff替代“没有快进”的行为。这被推荐用于特性分支，其中保留了一组提交都是一个内聚特性的一部分的事实是重要的，但如果你只是让生产分支赶上开发，那么这是不必要的。

事实上，你的合并不是快进表明提交直接提交到产品，在我们的例子中是提交4 - 7。在许多工作流程中，这不应该发生，提交只应该开发，然后合并为产品。你应该调查一下，可能会有变化，但不在开发中。有人可能热补丁产品。

解决这种情况的最简单方法是将dev合并为prod，然后立即删除dev并将其再次关闭prod。别担心，分支历史将被保留。

1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 [prod] [dev] [HEAD] 
      \     /
      A -- B -- C -- D -- E 

git branch -d dev将阻止您删除尚未完全合并的分支。例如，如果存储库这个样子......

1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 [prod] [HEAD] 
      \     /
      A -- B -- C -- D -- E -- F -- G [dev] 

你跑git branch -d dev，混帐将拒绝删除该分支。 不要使用-D或-f强制它否则你将失去开发工作。只需将dev合并到prod中，然后再试一次。

还有其他方法可以处理这种情况，但这是最简单的。之后，你的提交应该快进。