为什么合并后GIT说“已经是最新的"，但分支之间的差异仍然存在? [英] Why after merge does GIT say "Already up-to-date", but differences between branches still exist?

问题描述

我最初在newfeature"分支工作，我被要求紧急修复实时分支上的错误.我为此创建了一个名为generalmaintenance"的分支，完成了这项工作，然后切换到开发并将其合并.我现在想返回到newfeature"分支并合并我之前合并到它的更改.

I was originally working in 'newfeature' branch and I was called to fix a bug on the live branch urgently. I created a branch for that called 'generalmaintenance', did the job and then switched to develop and merged it in. I now want to return to 'newfeature' branch and to merge in the changes that I merged into it earlier.

当我切换到'newfeature'并合并到'develop'时，有3个文件发生冲突.

When I switched to 'newfeature' and merged in 'develop', there were conflicts in 3 files.

我在解决冲突时陷入了困境，最终决定使用 Aptana Studio 3(这是我的 IDE)的团队"菜单中的恢复"命令.我预计这会在合并之前让我回滚到合并之前，它似乎已经完成了.

I got in a tangle resolving the conflicts and eventually decided to use the "Revert" command in the 'Team' menu of Aptana Studio 3 (which is my IDE). I expected this to roll me back to before the merge, which it appears to have done.

无论如何，当我再次合并'develop'时，它说，Already-up-to-date，但是当比较两个分支之间的文件时，它们非常不同，我添加的更改在另一个分支中没有被合并.

Anyway, when I merge in 'develop' again, it says, Already-up-to-date, but when comparing files between the two branches, they are very different and the changes I added in the other branch are not being merged in.

请问我现在如何合并这两个分支?

How will I merge the two branches now please?

推荐答案

恢复合并与重置合并

我的猜测是你实际上是已经是最新的.

问题在于 git revert不会撤消合并，它只会撤消合并带来的更改.创建合并提交时，您将合并这两个分支的提交历史.

The problem is that git revert doesn't undo the merge, it only undoes the changes that the merge brought with it. When you create a merge commit, you're combining the commit histories of those two branches.

合并

     develop
        |
A---B---C
        
  E---F---M
          |
      newfeature

在上面的例子中，develop 被合并到 newfeature 中，创建了 M 提交.如果你运行 git log newfeature 你会看到来自两个分支的所有提交，但是从 newfeature 分支的角度来看，所有这些更改都是由 M 提交.

In the case above, develop is merged into newfeature, creating the M commit. If you were to run git log newfeature you would see all the commits from both branches, however from the perspective of the newfeature branch, all those changes were performed by the M commit.

恢复

git revert 命令不会删除任何提交，而是创建一个新提交来撤消提交所包含的更改.例如，如果您有一个包含此差异的提交...

The git revert command does not remove any commits, instead it creates a new commit that undoes the changes that the commit contained. For example if you had a commit containing this diff...

-This is the old sentence.
+This is the new sentence.

然后恢复这个，revert 命令将创建一个新的提交，它只是执行相反的差异，它只是翻转符号.

Then reverted this, the revert command would create a new commit that just preformed the opposite diff, it simply flips the signs.

-This is the new sentence.
+This is the old sentence.

这对于消除由其他开发人员已经拥有的提交造成的损害非常有用.它推动历史前进，而不是改变历史.

This is really useful for undoing damage caused by commits that other developers already have. It moves history forward rather than changing history.

恢复合并

但是，在非快进合并的上下文中，它可能会产生不良影响.

However, in the context of a non-fastforward merge it may have an undesired effect.

     develop
        |
A---B---C
        
  E---F---M---W
              |
         newfeature

假设 W 是一个回滚提交，你可以看到运行 git log newfeature 仍然会包含来自 develop 分支的所有提交.结果，来自 develop 的额外合并将不起作用，因为它看不到您的分支中缺少任何东西.

Assuming W is a reversion commit, you can see how running git log newfeature will still include all the commits from the develop branch. As a result, additional merges from develop will no work, because it doesn't see anything missing from your branch.

使用 git reset而不是还原.

Using git reset instead of revert.

将来，您可能需要考虑使用 git reset --hard (其中 是合并的提交哈希)如果该合并尚未与其他开发人员共享，则撤消合并.在上面的例子中，在创建了合并提交 M 之后，运行命令 git reset --hard F 将导致以下结果.

In the future, you might want to consider using git reset --hard <ref> (where <ref> is the commit hash of the merge) to undo a merge if that merge has not been shared with other developers. In the example above, after having created merge commit M, running the command git reset --hard F would result in the following.

     develop
        |
A---B---C
        
  E---F---M
      |
  newfeature

正如您所看到的，这种技术并没有像某些人认为的那样消除提交，它只是将您的分支移回您选择的提交.现在，如果您运行 git log newfeature，您只会得到提交 F、E 和 A.现在合并实际上已经从你的分支历史中消失了，所以以后在 develop 中尝试重新合并不会导致任何问题.

As you can see this technique doesn't obliterate the commit as some people tend to think, it simply moves your branch back to the commit you selected. Now if you ran git log newfeature you would only get commit F, E, and A. Now the merge is actually gone from your branches history, so a later attempts to re-merge in develop will cause no problems.

这种方法并非没有复杂性.意识到你现在正在修改历史，所以如果 newfeature 分支在 M 合并后被推送到远程分支，那么 git 会认为你只是出局日期并告诉你你需要运行 git pull.如果只是你在那个远程分支上工作，那么可以随意 force-push - git push -f ;<分支>.这将具有与重置相同的效果，但在远程分支上.

This method is not without its complications. Realize that you are now modifying history, so if the newfeature branch was pushed to a remote branch after the M merge was made, then git is going to think you are simply out of date and tell you that you need to run git pull. If its just you working on that remote branch, then feel free to force-push - git push -f <remote> <branch>. This will have the same effect of the reset but on the remote branch.

如果这个分支被多个开发人员使用，而他们现在已经从它中撤出 - 那么这是一个坏主意.这就是 git revert 有用的原因，因为它可以在不改变实际历史的情况下撤消更改.

If this branch is being used by multiple developers, who would have by now already pulled from it - then this is a bad idea. This is the very reason git revert is useful, because it undoes changes without changing the actual history.

在历史上使用重置实际上仅适用于尚未共享的提交.

Using reset on history is really only on option for commits that have not been shared.

解决方案 - 还原还原.

如果已经共享了合并提交，那么最好的方法可能是在该合并上使用 git revert.但是，正如我们之前所说，您不能简单地将分支合并回并期望该分支的所有更改重新出现.答案是还原还原提交.

If the merge commit has already been shared, then the best approach is probably to use git revert on that merge. However as we said before, you can not then simply merge the branch back in and expect all the changes from that branch to re-appear. The answer is to revert the revert commit.

假设您在 newfeature 中尊重合并后在 develop 分支上做了一些工作.您的历史记录看起来像这样.

Lets say you did some work on the develop branch after having revered the merge in newfeature. Your history would look something like this.

         develop
            |
A---B---C---D
        
  E---F---M---W
              |
         newfeature

如果你现在将 develop 合并到 newfeature 中，你只会得到 D 因为它是唯一一个还没有成为历史一部分的提交newfeature 分支.您还需要做的是还原 W 提交 - git revert W 应该执行 git merge develop 之后的技巧.

If you merge develop into newfeature now, you would only get D because its the only commit that is not already part of the history of the newfeature branch. What you also need to do is revert that W commit - git revert W should do the trick followed by git merge develop.

                 develop
                    |
A---B---C-----------D
                   
  E---F---M---W---M---G
                      |
                 newfeature

这将恢复原始合并提交所做的所有更改——这些更改实际上是由 C 和 B 做出的，但在 W 中恢复了，然后它通过一个新的合并提交 G 引入 D 我建议在合并最近的 develop，我怀疑按照这个顺序执行会降低触发冲突的可能性.

This restores all the changes made by the original merge commit - which were actually made by C and B but were reverted in W, it then brings in D via a new merge commit G I would recommend reverting the revert before merging in the recent changes to develop, I suspect doing it in that order will have a lower chance of triggering conflicts.

TL;DR

还原会创建还原提交".撤消还原时，您需要对第一次还原时创建的还原提交运行 revert 命令.应该很容易找到，git 倾向于对还原进行自动评论，以便它们以还原"一词开头.

Reverting creates a 'revert commit'. When undoing a revert, you need to run the revert command on the revert commit that was created when you reverted the first time. It should be easy enough to find, git tends to auto-comment on reverts so that they start with the word "Reverted".

git revert

这篇关于为什么合并后GIT说“已经是最新的"，但分支之间的差异仍然存在?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！