如前所述，传入——no-commit标志，但为了避免快进提交，也传入——no-ff，如下所示:

$ git merge --no-commit --no-ff $BRANCH

检查阶段性的变化:

$ git diff --cached

你可以撤销合并，即使是快进合并:

$ git merge --abort

用git撤销合并是如此简单，你甚至不应该担心演练:

$ git pull $REMOTE $BRANCH
# uh oh, that wasn't right
$ git reset --hard ORIG_HEAD
# all is right with the world

编辑:正如下面的评论中所指出的，如果你在你的工作目录或暂存区域中有更改，你可能想要在执行上述操作之前隐藏它们(否则它们将在上面的git重置后消失)

只要将当前分支与远程分支区别开来，这将告诉你当你进行拉/合并时将会发生什么变化。

#see diff between current master and remote branch
git diff master origin/master

如果你想从B快进到A，那么你必须确保git log B..A没有显示任何东西，也就是说A没有B没有的东西。但即使B. A有一些东西，你仍然可能能够合并而没有冲突，所以上面说明了两件事:将会有一个快进，因此你不会得到冲突。

我的简单粗暴解决方案是:

创建一个“pre-master”分支(当然来自master) 将所有你想要的东西合并到这个预master中。 然后你可以看到合并是如何发生的，而不触及主。 将pre-master合并为master OR 将所有想要发布的分支合并到master中

不管怎样，我会听从@orange80的建议。

我只需要实现一个自动查找存储库与其远程存储库之间冲突的方法。这个解决方案在内存中进行合并，所以它不会影响索引，也不会影响工作树。我认为这是解决这个问题最安全的方法。下面是它的工作原理:

将远程获取到存储库。例如: Git获取源主机 执行命令git merge-base: git merge-base FETCH_HEAD master 运行git merge-tree: git merge-tree mergebase master FETCH_HEAD (mergebase为上一步打印的merge-base十六进制id)

现在假设您想要合并远程主服务器和本地主服务器，但是您可以使用任何分支。Git合并树将在内存中执行合并，并将结果打印到标准输出。Grep模式<<或>>。或者您可以将输出打印到一个文件中并进行检查。如果你发现一行以“changed in both”开头，那么很可能会有冲突。

不完全是那样的。但是您可以使用——no-commit选项，这样它就不会在合并后自动提交结果。通过这种方式，您可以检查合并，如果需要的话，还可以在不破坏提交树的情况下撤消合并。

你可以在看到冲突后执行git merge -abort。

我猜你只是想知道在真正尝试合并之前你给自己惹了多少麻烦……并且在合并失败后重置到最后一次提交相对容易，所以如果这是预期的方法，我不会感到惊讶。

也就是说，如果你真的不想触及工作树中现有的文件，你可以创建一个补丁并针对目标分支测试它。这还可以显示对哪些文件做了哪些更改-只需在文本编辑器中打开补丁文件。

git checkout -b mycrazybranch
[change some stuff...]
git add .
git commit -m "changed some stuff"
git format-patch master --stdout > crazy.patch
git checkout master
git apply crazy.patch --check
[all good! cleanup...]
rm crazy.patch

如您所见，这将创建一个补丁文件，然后您可以测试它—检查并查看是否有任何错误，然后删除补丁文件。

作为对已有答案的总结，有两种方法来检查是否存在合并冲突

Git format-patch $(Git merge-base branch1 branch2).——| git apply——3way——check -

注意，在运行上述命令时，当前的分支应该是branch1

另一种方法:

git merge --no-commit branch2
# check the return code here
git merge --abort

我使用git日志来查看从主分支到特性分支上发生了什么变化

git log does_this_branch..contain_this_branch_changes

例如，查看哪些提交在一个已经/没有被合并到master的特性分支中:

git log master..feature_branch

这可能很有趣:从文档中:

如果您尝试合并，导致复杂的冲突，并希望 重新开始，你可以用git merge -abort恢复。

但你也可以用幼稚(但缓慢)的方式来做:

rm -Rf /tmp/repository
cp -r repository /tmp/
cd /tmp/repository
git merge ...
...if successful, do the real merge. :)

(注意:仅仅克隆到/tmp不能工作，你需要一个副本，以确保未提交的更改不会冲突)。

我做了一个别名来做这件事，就像一个魅力，我这样做:

 git config --global alias.mergetest '!f(){ git merge --no-commit --no-ff "$1"; git merge --abort; echo "Merge aborted"; };f '

现在我只需调用

git mergetest <branchname>

看看是否有任何冲突。

为你的工作副本制作一个临时副本，然后合并，并将两者区分开来。

Git在合并时引入了——ff-only选项。

来自:http://git-scm.com/docs/git-merge ——ff-only 拒绝合并并以非零状态退出，除非当前HEAD已经是最新的，或者合并可以作为快进解决。

这样做将尝试合并和快进，如果不能，它将中止并提示您不能执行快进，但不影响您的工作分支。如果它可以快进，那么它将在工作分支上执行合并。此选项也可用于git拉取。因此，你可以这样做:

git pull --ff-only origin branchA #See if you can pull down and merge branchA

git merge --ff-only branchA branchB #See if you can merge branchA into branchB

我使用request-pull git命令来做到这一点。它允许您查看合并时可能发生的每个更改，但无需对本地或远程存储库进行任何操作。

例如，假设您想将一个名为“feature-x”的分支合并到您的主分支中

git request-pull master origin feature-x

将向您展示将发生什么(不做任何事情)的摘要:

The following changes since commit fc01dde318:
    Layout updates (2015-06-25 11:00:47 +0200)
are available in the git repository at:
    http://fakeurl.com/myrepo.git/ feature-x
for you to fetch changes up to 841d3b41ad:
----------------------------------------------------------------
john (2):
    Adding some layout
    Refactoring
ioserver.js            |   8 +++---
package.json           |   7 +++++-
server.js              |   4 +--
layout/ldkdsd.js       | 277 +++++++++++++++++++++++++++++++++++++
4 files changed, 289 insertions(+), 7 deletions(-)
create mode 100644 layout/ldkdsd.js

如果您添加-pparameter，您还将获得完整的补丁文本，就像您对每个更改的文件执行git diff一样。

我很惊讶没有人建议使用补丁。

假设你想测试从your_branch到master的合并(我假设你已经检查了master):

$ git diff master your_branch > your_branch.patch
$ git apply --check your_branch.patch
$ rm your_branch.patch

这样应该可以了。

如果你得到这样的错误

error: patch failed: test.txt:1
error: test.txt: patch does not apply

这意味着补丁并不成功，合并会产生冲突。没有输出意味着补丁是干净的，您可以轻松地合并分支

请注意，这实际上不会改变您的工作树(当然除了创建补丁文件，但您可以安全地删除之后)。在git-apply文档中:

--check
    Instead of applying the patch, see if the patch is applicable to the
    current working tree and/or the index file and detects errors. Turns
    off "apply".

提醒那些比我更聪明/对git更有经验的人:如果我错了，请告诉我，这个方法确实显示出与常规合并不同的行为。奇怪的是，这个问题已经存在8年多了，没有人会提出这个看似显而易见的解决方案。

我的解决方案是向后归并。

不要将您的分支合并到远程“目标”分支中，而是将该分支合并到您的分支中。

git checkout my-branch
git merge origin/target-branch

你将看到是否有任何冲突，并可以计划如何解决它们。

在这之后，你可以通过git merge—abort终止合并，或者(如果没有任何冲突并且合并已经发生)通过git reset—hard HEAD~1回滚到之前的提交

我知道这在理论上是跑题的，但对于从谷歌搜索到这里的人来说，实际上是非常切题的。

当有疑问时，你可以使用Github界面创建一个pull-request，并检查它是否表明干净的合并是可能的。

我只想看到冲突(不能看到他们与diff3在GitHub，还)。充分利用上面的答案，我想到了这个:

git merge --no-commit --no-ff @{upstream}
git grep -l '<<<<<<< HEAD' | xargs -I % sh -c "echo -e '\n\e[93m%\n---\e[0m' && cat %"
git merge --abort

对我来说，这是用来检查我的pr的。你可以用任何分支替换@{upstream}。

我希望这对大家有所帮助。