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

$ git merge #91-fix-html-markup

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

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

发生在我身上并被发送到这个页面，不确定我是否有相同的场景，但我的是我试图“重新合并”“测试”分支。

所以我之前合并了它，但我故意在合并过程中排除了一些特定的更改，所以它在分支之间显然有一些差异。然后，我试图重新合并它，因为我意识到/忘记我应该添加一个特定的更改/文件，我之前已经排除了，我希望如果我再次进行合并，将显示我之前排除的所有更改，但我错了，我得到了“已经更新”的消息。

在阅读@Bombe的评论/回答后，他是对的，我认为git是这样做的，所以我所做的是在测试分支上对文件进行硬备份，然后签出主分支，手动将文件粘贴到其中，并提交它，就像它是新的更改一样。

我不确定这是否是正确的方法，或者是否可以帮助其他有同样问题的人，但它确实为我的特殊情况提供了解决方案。

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

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

下面是从另一个分支获得更改的方法，而不考虑合并历史(注意:这会清除工作树，所以git在尝试之前会隐藏或提交更改)

// stash changes to ensure you don't lose any edits
git checkout your-branch-that-won't-simply-merge
git stash


git checkout branch-with-changes -- .

——。参数将检出其他分支的所有文件，同时仍检出到同一分支。然后您可以按照自己的意愿添加和提交。

我还将它与 Git add -p 这将使你能够在“大块头”中进行任何变化。它会询问y/n您是否想要执行任何更改过的行块，这意味着您可以在下次提交时保留不想要的更改。

这是我找到的原始答案的链接，去点赞吧。: https://stackoverflow.com/a/15536640/8272035

89年问题 通过提供当前路径，.:

Git签出other-branch-name——。

此操作类似于在不签出文件的情况下将HEAD切换到另一个分支，但只是从“另一个方向”切换。

正如@김민준提到的，这将覆盖任何未提交的更改。如果需要的话，记得先把它们藏起来或提交到某个地方。

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

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

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

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

编辑10/12/2019:

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

git checkout master
git reset --hard test

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

然后做:

git push --force origin master

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