在实际合并之前查看git合并的结果

在实际合并两个分支之前，是否有方法检查两个分支之间合并的结果

当尝试将分支A合并到分支B时，我通常会从B签出一个临时分支，将其与分支A合并，然后我会创建一个差异补丁，或者只是签出到该临时分支，并在将A合并到B之前检查是否一切正常

---

git是否提供了一个命令或功能来实现这一点？

正如Marian Theisen所建议的，您可以这样做来进行合并，而无需提交

git merge --no-commit <branchname>

另外，请记住，在Git中，改变想法并返回到以前的状态总是很容易的。你可以做一个完整的合并，包括提交，检查完整的结果，如果你改变主意，你可以

git reset --hard HEAD^

放弃合并并在合并前返回提交

事实上，在合并解析过程中的任何时候，您都可以

git reset --merge

---

中止合并并丢弃合并更改。

为什么要费事呢？只需执行合并，测试它，如果您不喜欢它，然后

git reset--hard HEAD^

返回到预合并状态。无论您是否决定保留合并，执行一些临时或中途合并只会增加您的工作量。

我称之为“代码审阅工作流”，并一直这样做

git merge --no-commit --no-ff branchname

如果没有

--no ff

标志，如果Git可以进行快进，那么它就会这样做。（正如预期的那样，与快进一样，没有要创建的合并提交。）

为了方便起见，我在

.gitconfig

中设置了此别名：

rev = merge --no-ff --no-commit

这样我就可以简单地做到：

git rev branchname

其思想是，所有功能都在单独的分支中开发，每个功能都由作者以外的人进行审查和合并。正如其他答案所指出的，您可以通过以下方式中止合并：

git reset --merge

并要求作者做更多的修改

要查看仅包含合并提交的日志，我使用另一个别名：

revlog = log --first-parent

---

这样，日志就成了一个大步骤的时间线：一个功能一个功能地执行，而不是一个提交一个提交。

git merge——不提交

快进合并没有风险。快进合并是最好的：没有风险，没有污染，只需向前移动分支指针。为什么有人会如此随便地使用它——没有ff标志对我来说是个谜。如果有人能说明这一点，请说明。根据我自己的经验，我要提醒人们在决定反对快进之前要真正理解快进的含义。@PaulvanLeeuwen我同意你的观点。但这不是“随意使用

--no ff

标志”的情况。这是对合并前检查更改这一特定问题的回答。尽管快进不是合并，但使用

--no ff

似乎符合OP的意图。我发现这是一种将开发分支合并到主分支的好方法，但在提交合并之前，只需将env/settings文件重置为正常。不过，我相信有一个比我更好的解决方案来维护不同的环境设置。在我的情况下，我必须在合并之前手动查看和选择每个更改，因此为了使过程更简单，我还使用了

git reset

来取消所有修改文件的保存。

revlog = log --first-parent