Github分支总是在前面或后面 [英] Github Branches are always ahead or behind

问题描述

我们有一个有2个分支的回购。一个名为 dev ，另一个 prd 。我们遵循一个正常的流程来发送来自我们Forks的请求，将我们的更改与 dev 合并。之后，将请求和合并从 dev 转换为 prd ，以使这些更新成为Live。

从 dev 到 prd 合并时， prd 分支变得永远在 dev 的前面（有时是提交栈）。如果我们试图合并 prd 回到 dev ，它会发生相反的效果， p>

我们怎样才能让两个分支恢复同步，因为这些状态导致了团队的混乱。

注意：它是未来，没有文件更改，只提交被记录下来。

解决方案

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

在Git中，合并与其他任何合并一样，只有两个（或更多）父母。它包含合并内容所需的更改。将分支合并到另一个分支时，源分支不会更改。所以当dev被合并到产品中时，只有产品发生了变化。

这是一个可视化的例子。假设dev在第3次提交时分支了产品。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总是会在合并之后领先于开发者。例外是快进。假设发生这种情况。

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

at 4.已经完成了关于dev而不是prod的工作。 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 branch -d dev ，git会拒绝删除分支。 不要使用-D或-f强制它，否则你将失去开发工作。只需将dev合并到prod中，然后再试一次即可。

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

We have a repo with 2 branches. One named dev and the other prd. We follow a normal process to sending pull requests from our Forks to merge our changes with dev. Afterwards, a pull request and merge is made from dev into prd to make these updates Live.

The problem is at one point while merging from dev to prd, the prd branch became permanently 'ahead' of dev (sometimes the commits ahead stack). The opposite effect will happen if we try to merge prd back into dev, except it will then be behind.

How can we get both of branches back in sync because these statuses are causing confusion for the team.

Note: it is ahead with no file changes, only commits are being recorded.

解决方案

Because of the way merges work in Git, this is normal behavior.

In Git, a merge is a commit like any other, it just has two (or more) parents. It contains the changes necessary to merge the content. When you merge a branch into another, the source branch is not changed. So when dev is merged into prod, only prod changes.

Here's a visual example. Let's say dev was branched off prod at commit 3. prod is now at commit 7 and dev is at E. prod is checked out.

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

When dev is merged into prod with the command git merge dev, this the the result.

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

The merge results in a new commit whose parents are both 7 and E. It contains all the changes necessary to merge them together. prod is advanced to this new commit. dev remains at E.

This is why prod will always ahead of dev after merging. The exception is "fast forwarding". Let's say this happens.

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

dev was branched off of prod at 4. Work has been done on dev but not prod. prod is checked out. When git merge dev is done, git will recognize there is no need for a merge and do a "fast forward".

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

prod is advanced to C, the same place dev is. You can override this behavior with git merge --no-ff for "no fast-forward". This is recommended for feature branches, where retaining the fact that a set of commits was all part of a cohesive feature is important, but unnecessary if you're just making a production branch catch up to development.

The fact that your merges are not fast-forwarding indicates that commits were made directly to prod, those are commits 4 - 7 in our example. In many workflows this should not happen, commits should only be made to dev and then merged into prod. You should investigate that, there could be changes in prod which are not in dev. Somebody probably hot patched prod.

The simplest way to fix this situation is to merge dev into prod and then immediately delete dev and branch it again off prod. Don't worry, branch history will be preserved.

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

git branch -d dev will prevent you from deleting a branch which has not been fully merged. For example, if the repository looked like this...

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

And you ran git branch -d dev, git would refuse to delete the branch. DO NOT use -D or -f to force it else you will lose work from dev. Simply merge dev into prod and then try again.

There are other ways to handle this situation, but that is the simplest. After that, your commits should fast forward.

这篇关于Github分支总是在前面或后面的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！