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

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

$ git merge #91-fix-html-markup

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

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

我有一种重新合并它的方法，我的场景是我需要合并一个发布分支。

条件:发布分支代码是金的。意思是master是不正确的而release分支是正确的。

现象:将发布版本合并到主版本时，主版本中不正确的部件没有与发布版本中的部件一起更新。

以下是步骤，免责声明:我对git的了解有限，一定有更好的方法来实现它。

checkout release branch, do a pull. [Commit #A] merge latest master to release [Commit #B] (incorrect file will write to release branch) do a reverse commit of the [Commit #B] BUT keep it in stage (if the reserve commit is committed as [Commit #C] then do a soft reset to Commit #B) (this essentially reverse the incorrect files) edit the files, check whether these are correct, discard the unwanted ones (if there is any) stash the changes in step 4 [Stash{X}] reset release back to Commit #A (same as remote) merge latest master to release again [Commit #D] (diff hash should be the same but commit hash is different than b) Apply stash {x} Commit and merge to master.

编辑:第9步可以发生在本地，只是看看预期的部分是否已应用，如果你碰巧不得不使用一个公关在远程。

我也有同样的问题。我在遥控器上做了修改，它仍然显示“已经更新”。重新克隆存储库为我解决了这个问题。

使用Git Bash面对这个场景。

我们的存储库有多个分支，每个分支都有不同的提交周期，合并偶尔会发生一次。 Old_Branch被用作New_Branch的父类

Old_Branch更新了一些更改，需要与New_Branch合并

正在使用下面的拉命令，没有任何分支，从所有分支获得所有来源。

Git拉源

奇怪的是，这并没有从所有分支中拉出所有的提交。曾经认为它正如所示显示几乎所有的分支和标签。

所以要解决这个问题，已经检查出Old_Branch拉了最新的使用

git checkout Old_Branch git拉原点Old_Branch

现在查看New_Branch

git checkout New_Branch

拉了一下，确认一下

git拉原点New_Branch git合并Old_Branch

viola得到了从Old_Branch到New_Branch的冲突来修复:)，这是预期的

嗨，我已经创建了一个git别名，我称之为git remerge，这有助于解决问题。

它首先将git merge <FEATURE-BRANCH-NAME>。 然后将强制重新计算分支之间不同文件的所有冲突。

你可以在这里使用它!

如果你有任何建议，或者你想为这个项目做出贡献，欢迎你!