Github分支总是领先或落后

Question

我们有一个有 2 个分支的仓库。一个被命名dev，另一个被命名prd。我们遵循正常流程从我们的分叉发送拉取请求，以将我们的更改与dev. 然后，发出拉取请求并进行合并，dev以prd使这些更新生效。

问题是在合并 fromdev到时的某个时刻prd，prd分支永久“领先”于dev（有时是提前提交堆栈）。如果我们尝试合并prd回，则会发生相反的效果dev，除非它会落后。

我们如何才能使两个分支恢复同步，因为这些状态给团队带来了混乱。

注意：它领先于没有文件更改，仅记录提交。

Answer 1

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

在 Git 中，合并是像任何其他提交一样的提交，它只有两个（或更多）父级。它包含合并内容所需的更改。当您将一个分支合并到另一个分支时，源分支不会更改。因此，当 dev 合并到 prod 时，只有 prod 发生变化。

这是一个视觉示例。假设 dev 在提交 3 处从 prod 分支出来。prod 现在位于提交 7 处，dev 位于 E 处。prod 已签出。

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

当使用命令将 dev 合并到 prod 时git merge dev，这就是结果。

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 处从 prod 中分支出来。dev 上的工作已经完成，但 prod 上还没有完成。产品已签出。完成后git merge dev，git 将认识到不需要合并并执行“快进”。

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

prod 高级到 C，与 dev 相同。您可以使用git merge --no-ff“不快进”来覆盖此行为。建议对功能分支这样做，因为保留一组提交是内聚功能的一部分这一事实很重要，但如果您只是让生产分支赶上开发，则没有必要。

您的合并不是快进的事实表明提交是直接对 prod 进行的，在我们的示例中是提交 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 时git branch -d dev，它会拒绝删除该分支。不要使用 -D 或 -f 来强制它，否则你将失去开发人员的工作。只需将 dev 合并到 prod 中，然后重试。

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