合并提交在GitHub上实际显示的差异是什么？

请考虑以下提交页面：

通常，对于Git，提交是应用于先前代码基之上的一组更改，因此，考虑以下树：

查看

1ca1b6b

的差异将在左侧显示截至

ca2cac9

的代码库，在右侧显示提交中应用的更改。对于合并提交，我们在左侧看到了什么？i、 e.考虑以下因素：

---

如果我们在GitHub上查看提交

1e25f98

，左边是什么<代码>06f5be1？那么用一棵更复杂的树呢？还是三个分支的合并？它只是显示了历史上最后一个公共点之间的差异吗？

Git提交实际上是快照

。。。因此，您需要指定两个提交来进行区分。例如，

git diff HEAD^HEAD

。如果未指定，则将第二个参考设置为HEAD

但是是的，例如，

git log-p

显示了关于第一个父项的补丁，以使事情变得更简单。GitHub/Lab的行为也一样

父母已被订购

并且merge commit的第一个父级指向您在调用

git merge

之前所执行的提交。（你的头在哪里。）

默认情况下，始终使用第一个父对象。例如，

HEAD^

是

HEAD

的第一个父级（在第二幅图像上

6f01964

），

HEAD~2

是

HEAD

的第一个父级（

2bb48b5

）。这可以被

^

覆盖，因此

HEAD^2

是

HEAD

的第二个父级，因此

b0417C3

在实质上是正确的，我对其进行了改进，但为了具体地解决GitHub问题，GitHub所做的是完全忽略第二个父级

您可以使用以下命令在命令行上看到相同的差异：

git log -p --no-walk --first-parent -m cc5b002a5140e2d60184de42554a8737981c846c

或者更简单一点：

git show --first-parent cc5b002a5140e2d60184de42554a8737981c846c

---

（我们需要

git日志中的
--no walk
来阻止git查看更多提交，而
git show
暗示了这一点。我们需要
--first parent
使git只查看第一个父级，对于
git log
，我们需要
-m
或
-c
或
--cc
来强制
git log）de>显示补丁，因为
-p
通常会跳过显示用于合并的补丁，即使我们使用
--第一个父项
来修剪剩余的父项。）
如果git提交是快照，为什么cherry只挑选提交中所做的更改？@LeonAves cherry picking（顺便说一句，也在rebase内部使用）是使用引入的更改的异常，如文档中所述。选择提交内容没有多大意义：）实际上，
git log-p
默认情况下不显示差异。（在帖子中克隆回购协议并尝试，
git log-p--no walk cc5b002a5140e2d60184de42554a8737981c846c
）GitHub实际上选择使用
git log-p--no walk--first parent-m cc5b002a5140e2d60184de42554a8737981c846c
，以区别于第一个家长。@LeonAves:
git cherry pick
使用（单条）提交以查找修补程序的父级（不过，从技术上讲，它使用父级作为合并基础，执行完整的三方合并）。如果选择合并提交，则必须使用
-m
参数指定此操作要使用的父级（如果提交不是合并，则禁止使用此参数，这有点奇怪，因为
-m1
在此处有意义）。