如何在 git 中预览合并？

Question

我有一个 git 分支（例如主线），我想合并到另一个开发分支中。或者我也这样？

为了决定我是否真的想要合并这个分支，我想看看合并将做什么的某种预览。最好能够查看正在应用的提交列表。

到目前为止，我能想到的最好的办法是merge --no-ff --no-commit，然后是diff HEAD。

Answer 1

如果您像我一样，您正在寻找相当于 svn update -n 的内容。以下似乎可以解决问题。请注意，请确保首先执行 git fetch ，以便您的本地存储库有适当的更新可供比较。

$ git fetch origin
$ git diff --name-status origin/master
D       TableAudit/Step0_DeleteOldFiles.sh
D       TableAudit/Step1_PopulateRawTableList.sh
A       manbuild/staff_companies.sql
M       update-all-slave-dbs.sh

或者如果你想要从你的头脑到远程的差异：

$ git fetch origin
$ git diff origin/master

---

IMO这个解决方案比建议“合并然后中止”的顶级解决方案更容易并且更不容易出错（因此风险也更小）。

Answer 2

如果您已经获取了更改，我最喜欢的是：

git log ...@{u}

我相信这需要 git 1.7.x。 @{u} 表示法是上游分支的“简写”，因此它比 git log ...origin/master 更通用一些。

注意：如果您使用 zsh 和扩展的 glog，您可能需要执行以下操作：

git log ...@\{u\}

Answer 3

添加到现有答案中，可以创建别名来显示合并之前的差异和/或日志。许多答案忽略了在“预览”合并之前首先完成的fetch；这是一个将这两个步骤合二为一的别名（模拟类似于 Mercurial 的 hg 输入 / 传出）

因此，构建在“git log ..otherbranch< /code>”，您可以将以下内容添加到 ~/.gitconfig ：

...
[alias]
    # fetch and show what would be merged (use option "-p" to see patch)
    incoming = "!git remote update -p; git log ..@{u}"

为了对称，可以使用以下别名来显示在推送之前已提交和将推送的内容：

    # what would be pushed (currently committed)
    outgoing = log @{u}..

然后您可以运行“git传入”来显示大量更改，或“git传入-p”来显示补丁（即“diff”），“git传入--pretty=oneline”，以获得简洁的摘要等。然后您可以（可选）运行“git pull”来实际合并。 （不过，由于您已经提取了内容，因此可以直接完成合并。）

同样，“git outing”显示了如果您要运行“git push”。

Answer 4

除了以一次性方式实际执行合并（参见 Kasapo 的答案）之外，似乎没有可靠的方法来看待这一点。

话虽如此，这里有一个稍微接近的方法：

git log TARGET_BRANCH...SOURCE_BRANCH --cherry

这给出了哪些提交将进入合并的公平指示。要查看差异，请添加 -p。要查看文件名，请添加 --raw、--stat、--name-only、--name-状态。

git diff TARGET_BRANCH...SOURCE_BRANCH 方法的问题（请参阅 Jan Hudec 的答案）是，如果源分支包含交叉合并，您将看到目标分支中已有更改的差异。

Answer 5

我尝试用这个东西来查看 Visual Studio 代码中的更改。

从 dev 创建一个临时分支。然后使用 --no-ff --no-commit 标志合并已更改文件的分支。

git checkout dev 
git checkout -b feature_temp 
git merge feature --no-ff --no-commit

功能分支的更改文件将反映在 feature_temp 分支中。

Answer 6

git log currentbranch..otherbranch 将为您提供在进行合并时将进入当前分支的提交列表。提供有关提交详细信息的常用日志参数将为您提供更多信息。

git diff currentbranch otherbranch 将为您提供将成为一个的两个提交之间的差异。这将是一个 diff，为您提供将要合并的所有内容。

这些有帮助吗？

Answer 7

Pull 请求 - 我已经使用了大部分已提交的想法，但我也经常使用的一个是（特别是如果它来自另一个开发人员）执行 Pull 请求，这提供了一种方便的方法来在合并之前检查合并中的所有更改地方。我知道那是 GitHub，不是 git，但它确实很方便。

Answer 8

也许这可以帮助你？
git-diff-tree - 比较通过两个树对象找到的 blob 的内容和模式

Answer 9

我不想使用 git merge 命令作为检查冲突文件的先导。我不想进行合并，我想在合并之前确定潜在的问题 - 自动合并可能对我隐藏的问题。我一直在寻找的解决方案是如何让 git 吐出两个分支中已更改的文件列表，这些文件将在将来合并在一起，相对于某个共同的祖先。获得该列表后，我可以使用其他文件比较工具来进一步查找内容。我已经搜索了多次，但仍然没有在原生 git 命令中找到我想要的东西。

这是我的解决方法，以防它对其他人有帮助：

在这种情况下，我有一个名为 QA 的分支，自上次生产版本以来，该分支有许多更改。我们的最后一个生产版本标记为“15.20.1”。我有另一个名为 new_stuff 的开发分支，我想将其合并到 QA 分支中。 QA 和 new_stuff 都指向“遵循”（由 gitk 报告）15.20.1 标签的提交。

git checkout QA
git pull
git diff 15.20.1 --name-only > QA_files
git checkout new_stuff
git pull
git diff 15.20.1 --name-only > new_stuff_files
comm -12 QA_files new_stuff_files

以下是一些关于为什么我对定位这些特定文件感兴趣的讨论：

如何我信任 Git 合并？

https://softwareengineering.stackexchange.com /questions/199780/how-far-do-you-trust-automerge

Answer 10

• git log ..otherbranch
  • 将合并到当前分支的更改列表。
• git diff ...otherbranch
  • 从共同祖先（合并基础）到要合并内容的头部的差异。 注意三个点，与两个点相比，它们具有特殊含义（见下文）。
• gitk ...otherbranch
  • 自上次合并以来分支的图形表示。

空字符串意味着 HEAD，所以这就是为什么只是 ..otherbranch 而不是 HEAD..otherbranch。

对于 diff 而言，两个点和三个点的含义与列出修订版本的命令（log、gitk 等）略有不同。对于 log 和其他，两个点 (a..b) 表示 b 中的所有内容，但不包括 a 和三个点 (a ...b) 表示仅在 a 或 b 之一中的所有内容。但是 diff 适用于两个修订版，并且由两个点 (a..b) 表示的更简单的情况是从 a 到 b 的简单区别，并且三个点 (a...b) 表示共同祖先和 b 之间的差异 (git diff $(git merge-base ab)..b）。

Answer 11

我发现最适合我的解决方案是仅执行合并并在存在冲突时中止合并。这种特殊的语法对我来说感觉干净简单。这是下面的策略2。

但是，如果您想确保不会弄乱当前分支，或者无论是否存在冲突，您都没有准备好合并，只需在其上创建一个新的子分支并进行合并即可：

策略 1：安全的方法 - 合并临时分支：

git checkout mybranch
git checkout -b mynew-temporary-branch
git merge some-other-branch

这样，如果您只想查看冲突是什么，您可以简单地丢弃临时分支。您不需要费心“中止”合并，并且可以返回到您的工作 - 只需再次签出“mybranch”，您的分支中就不会有任何合并的代码或合并冲突。

这基本上是一次预演。

策略 2：当你确实想要合并时，但前提是不存在冲突

git checkout mybranch
git merge some-other-branch

如果 git 报告冲突（并且仅当存在冲突时），你可以这样做

git merge --abort

：合并成功，您无法中止它（只能重置）。

如果您还没有准备好合并，请使用上面更安全的方法。

[编辑：2016 年 11 月 - 我将策略 1 换成了 2，因为似乎大多数人都在寻找“安全的方法”。策略 2 现在更需要注意的是，如果合并存在您尚未准备好处理的冲突，您可以简单地中止合并。如果阅读评论请记住！]

Answer 12

这里的大多数答案要么需要一个干净的工作目录和多个交互步骤（对脚本编写不利），要么不适用于所有情况，例如过去的合并已经将一些突出的更改带入目标分支，或者选择执行以下操作相同的。

要真正了解如果将 develop 合并到 master 分支中，现在会发生什么变化：

git merge-tree $(git merge-base master develop) master develop

由于它是一个管道命令，它不会猜测你的意思，你必须明确。它也不会对输出进行着色或使用寻呼机，因此完整的命令是：

git merge-tree $(git merge-base master develop) master develop | colordiff | less -R

— https://git.seveas.net/previewing-a-merge-result.html

（感谢 David Normington 提供的链接）

PS：

如果您遇到合并冲突，它们会以通常的方式显示中的冲突标记输出，例如：

$ git merge-tree $(git merge-base a b ) a b 
added in both
  our    100644 78981922613b2afb6025042ff6bd878ac1994e85 a
  their  100644 61780798228d17af2d34fce4cfbdf35556832472 a
@@ -1 +1,5 @@
+<<<<<<< .our
 a
+=======
+b
+>>>>>>> .their

用户@dreftymac提出了一个很好的观点：这使得它不适合编写脚本，因为您无法轻松地从状态代码中捕获它。根据情况（删除与修改等），冲突标记可能会有很大不同，这也使得 grep 变得困难。提防。