假设你有一个具有以下提交历史的分支master:

A -- B -- C -- D

现在，你创建了一个分支测试，处理它，并执行4次提交:

                 E -- F -- G -- H
                /
A -- B -- C -- D

主人的头指向D，测试者的头指向H。

当你要合并的分支的HEAD是你想要合并的分支的提交链的父节点时，就会显示“Already - updated”消息。 这里的情况就是这样:D是E的父结点。

从测试到主服务器没有什么需要合并的，因为从那时起主服务器上没有任何变化。 你在这里要做的就是告诉Git让master的head指向H，所以master的分支有如下的提交历史:

A -- B -- C -- D -- E -- F -- G -- H

这是一个Git命令重置的作业。 你也想让工作目录反映这个变化，所以你要做一个硬重置:

git reset --hard H

这很傻，但可能会发生。假设你的分支名称前缀是一个问题引用(例如#91-fix-html-markup)，如果你这样合并:

$ git merge #91-fix-html-markup

它不会像预期的那样工作，因为#之后的所有内容都被忽略，因为#开始一个内联注释。

在这种情况下，你可以重命名分支，省略#或使用单引号环绕分支名称:git merge '#91-fix-html-markup'。

“已经是最新的”消息意味着您试图合并的分支的所有更改都已经合并到您当前所在的分支。更具体地说，它意味着您试图合并的分支是当前分支的父分支。恭喜你，这是你做过的最简单的合并。：）

使用gitk查看您的存储库。“test”分支的标签应该在“master”分支标签的下方。

您的分支相对于其父分支是最新的。根据合并，自上次合并以来父节点中没有新的变化。这并不意味着分支是相同的，因为您可以在工作分支中进行大量更改，而且听起来确实如此。

编辑10/12/2019:

根据Charles Drake对这个答案的评论，解决这个问题的一个解决方案是:

git checkout master
git reset --hard test

这又回到了“测试”层面。

然后做:

git push --force origin master

为了迫使中央回购的变化。

这可能看起来微不足道，但我见过许多人忽略它，只是在父分支上进行git合并。这将自动导致“已经更新”的消息。

合并命令应该是git merge branchNametoMergeFrom

例如，假设你有2个分支branchA和branchB，你需要将B合并为a，你需要首先签出到branchA，然后使用merge命令，同时指定要合并的分支(在这种情况下是branchB)。

因此，命令不应该只是git merge，而应该是git merge branchB。

如果将分支A合并到分支B报告“Already up to date”，则反过来并不总是正确的。只有当分支B是分支A的后代时才成立，否则 分支B可以有A中没有的变更。

例子:

在master上创建分支A和B 您在master中做了一些更改，并只将这些更改合并到分支B中(不更新或忘记更新分支A)。 你在分支A中做了一些改变，并将A合并到B。

在这一点上，合并A到B报告“已经更新”，但分支是不同的，因为分支B有来自主的更新，而分支A没有。

我已经修复了这样的问题，重新基于当前的分支本身。