同样的事情也发生在我身上。 但是这个场景有点不同，我有一个master分支，我从它中分离出release_1(比如说)。 在release_1分支中做了一些更改，并将其合并到origin中。然后我在远程服务器上使用ssh 我再次使用命令git checkout -b release_1签出release_1，这实际上是一个新的分支release_!而不是从origin签出已经存在的分支release_1。 通过移除“-b”开关解决了问题

我不确定在我的情况下到底是什么问题，但问题的根源似乎是branchB检出，我无法从branchA拉出最新的更改…

我必须签出branchcha，拉出，然后签出branchB并合并branchA，让它像预期的那样工作。

当我知道远程主机上有更改时，这种情况经常发生在我身上，所以我尝试使用git merge master合并它们。但是，这不会与远程主服务器合并，而是与本地主服务器合并。

在合并之前，签出master，然后git拉到这里。然后您将能够将新的更改合并到您的分支中。

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

例子:

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

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

合并总是在当前HEAD和一个或多个提交之间(通常是分支头或标签)， 索引文件必须匹配HEAD提交的树(即上次提交的内容)。 换句话说，git diff——cached HEAD必须报告没有变化。 合并后的提交已经包含在HEAD中。这是最简单的情况，称为“Already - updated”。

这应该意味着测试中的提交已经合并到master中，但由于其他提交是在master上完成的，git diff test仍然会给出一些差异。

发生这种情况是因为您要合并的分支的本地副本已经过期。我有我的分支，叫MyBranch我想把它合并到ProjectMaster中。

_>git status
On branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.

nothing to commit, working tree clean

_>git merge ProjectMaster
Already up-to-date.

但我知道有些变化需要合并!

事情是这样的，当我输入git合并ProjectMaster时，git会查看这个分支的本地副本，这可能不是当前的。要查看情况是否如此，我首先告诉Git检查并查看我的分支是否过期，如果是的话，使用fetch获取任何更改。然后我跳到我想合并的分支，看看那里发生了什么……

_>git fetch origin

_>git checkout ProjectMaster
Switched to branch ProjectMaster
**Your branch is behind 'origin/ProjectMaster' by 85 commits, and can be fast-forwarded.**
  (use "git pull" to update your local branch)

啊哈!我的本地副本在85次提交时就过时了，这说明了一切!现在，我拉下我所遗漏的更改，然后跳转到MyBranch并再次尝试合并。

_>git pull
Updating 669f825..5b49912
Fast-forward

_>git checkout MyBranch-Issue2
Switched to branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.

_>git merge ProjectMaster
Auto-merging Runbooks/File1.ps1
CONFLICT (content): Merge conflict in Runbooks/Runbooks/File1.ps1

Automatic merge failed; fix conflicts and then commit the result.

现在我有另一个问题要解决…