为什么不直接创建一个丢弃的分支(git checkout -b)，然后在那里做一个测试合并?

如果我想比较一个主题分支的变化，我发现最简单和最安全的方法是:

git checkout master
git checkout -b trial_merge
git merge topic_branch

完成合并后，很容易看到合并后的更改

git diff master

完成后，只需删除trial_merge分支

git checkout master
git branch -D trial_merge

这样，主分支就不会改变。

你可以使用git merge——no-commit来阻止合并实际被提交，如果你不喜欢合并的工作方式，只需重置到原始头部。

如果您确实不想完成合并，即使它是快进(根据定义，因此没有冲突)，您也可以添加——no-ff。

在尝试合并之前，我认为没有一种方法可以模拟将要发生的事情。但是，如果您在执行合并之前确保git状态的输出为空，那么继续尝试它是相当安全的。如果你遇到冲突，你可以立即回到你之前的状态:

git reset --merge

从git 1.7.4开始，你也可以执行以下操作中止合并:

git merge --abort

(正如添加该选项的提交消息所解释的那样，添加此选项是为了与git rebase——abort等保持一致。)

我不知道是不是你的情况，但你的问题记得我，有时我开始一个功能，我花了几天时间来提交，我多次合并它的开发。

在这一点上，我失去了对我更改的确切文件的控制，只有当我的功能关闭，我的代码开始开发时，我才会知道它。

在这种情况下，了解您所做的修改(而不是来自合并的其他修改)的一个好方法是使用Sourcetree。

你必须点击基础分支上的右键，然后选择Diff Against Current:

然后sourcetree会向你显示所有的修改，如果你将你的分支合并到基础分支。

当然，它不会显示冲突，但它是合并中的有用工具。

我用:

git merge --ff-only

根据文件:

拒绝合并并以非零状态退出，除非当前HEAD已经是最新的，或者合并可以作为快进解决。

这并不是一个真正的模拟，因为在两个分支之间没有冲突的情况下，将会有一个快进合并。但如果发生冲突，你会被告知，什么也不会发生。