如何检查 Git 提交是否为合并提交

简介

在这个实验中，你将学习如何判断一个 Git 提交是否为合并提交。我们将探索 git show 命令来查看提交的详细信息，特别关注识别父提交，这是合并操作的一个关键指标。

你还将学习如何使用 git log --merges 命令，以高效地列出仓库历史记录中的所有合并提交。最后，我们将在非合并提交上测试这些方法，以巩固你对如何区分 Git 中不同类型提交的理解。

Skills Graph

使用 git show 检查父提交

在这一步中，我们将探索如何使用 git show 命令来查看提交的详细信息，特别关注其父提交。理解父提交对于浏览项目历史以及了解不同提交之间的关系至关重要。

首先，确保你位于项目目录中。打开终端并导航到 my-time-machine 目录：

cd ~/project/my-time-machine

现在，使用 git log 查看提交历史。我们将使用 --oneline 选项以简洁的方式查看：

git log --oneline

你应该会看到类似以下的输出（你的提交哈希会不同）：

a1b2c3d (HEAD -> master) Send a message to the future

这显示了我们的第一次提交。现在，使用 git show 查看这次提交的详细信息。从 git log 的输出中复制提交哈希（由字母和数字组成的短字符串，如 a1b2c3d），并替换下面命令中的 YOUR_COMMIT_HASH：

git show YOUR_COMMIT_HASH

例如，如果你的提交哈希是 a1b2c3d，你将运行：

git show a1b2c3d

输出会非常详细，显示有关提交的信息，包括作者、日期、提交消息以及该提交引入的更改。

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9
Author: Jane Doe <[email protected]>
Date:   Mon Aug 7 10:00:00 2023 +0000

    Send a message to the future

diff --git a/message.txt b/message.txt
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/message.txt
@@ -0,0 +1 @@
+Hello, Future Me

对于我们的第一次提交，也就是项目历史的起点，你会注意到输出中没有“Parent”行。这是因为初始提交没有父提交 —— 它是项目历史的根。

在后续步骤中，当我们有更多提交时，我们将再次使用 git show 来查看父提交是如何显示的，以及它们如何将历史记录联系在一起。理解这种联系是理解 Git 如何随时间跟踪更改的基础。

运行 git log --merges 进行验证

在这一步中，你将了解合并提交（merge commits），以及如何使用 git log --merges 专门查看项目历史记录中的此类提交。合并提交是将不同分支的更改整合在一起的特殊提交。

目前，你的项目历史非常简单，只有一个初始提交。你还没有创建任何分支或进行合并操作。首先，运行 git log --merges 来确认这一点。

确保你位于 ~/project/my-time-machine 目录中：

cd ~/project/my-time-machine

现在，运行以下命令：

git log --merges

由于你还没有执行任何合并操作，此命令可能不会产生任何输出：

这是预期的结果！git log --merges 命令旨在过滤提交历史记录，仅显示通过将一个分支合并到另一个分支而创建的提交。

要看到此命令的实际效果，你需要创建一个新分支，在该分支上进行一些提交，然后将其合并回主分支。你将在后续实验中探索分支和合并操作。

目前，重要的是要理解 git log --merges 是一个强大的工具，可用于了解项目中不同开发线路在何时以及如何合并。这在多人同时开发不同功能的协作环境中特别有用。

测试非合并提交

在这一步中，你将创建一个常规提交（非合并提交），然后使用 git log 查看它与合并提交（目前你还没有合并提交，但在后续实验中会有）在项目历史记录中的不同表现。这将有助于你巩固对不同提交类型的理解。

首先，对 message.txt 文件做一个小改动。你要添加一行新内容。

确保你位于 ~/project/my-time-machine 目录中：

cd ~/project/my-time-machine

现在，使用 echo 命令向文件追加一行新内容：

echo "Adding another line." >> message.txt

>> 操作符用于将文本追加到文件末尾，而不是覆盖文件内容。

查看文件内容：

cat message.txt

你应该会看到：

Hello, Future Me
Adding another line.

现在，查看仓库的状态：

git status

你应该会看到 message.txt 文件已被修改：

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   message.txt

no changes added to commit (use "git add" and/or "git commit -a")

Git 检测到了你所做的更改。现在，将这个更改暂存并提交。

git add message.txt
git commit -m "Add a second line to message"

你应该会看到确认提交的输出：

[master a1b2c3d] Add a second line to message
 1 file changed, 1 insertion(+)

现在，再次使用 git log --oneline 查看提交历史：

git log --oneline

你应该会看到两条提交记录：

e4f5g6h (HEAD -> master) Add a second line to message
a1b2c3d Send a message to the future

最新的提交（在这个例子中是 e4f5g6h，你的哈希值会不同）是新的非合并提交。它代表了直接在 master 分支上所做的一次更改。

如果再次运行 git log --merges，仍然不会有输出，因为这两条提交记录都不是合并提交。

理解常规提交和合并提交之间的区别，对于解读项目历史以及与他人有效协作非常重要。常规提交代表了单一开发线路上的线性进展，而合并提交则代表了不同开发线路上更改的整合。

总结

在本次实验中，你学习了如何在 Git 中识别合并提交。首先，你使用 git show 命令查看提交的详细信息，特别关注父提交（parent commits）的有无。你了解到初始提交没有父提交，而后续提交会显示其父提交。

接着，你探索了 git log --merges 命令，它可以直接列出仓库历史记录中的所有合并提交。最后，你在非合并提交上测试了这些方法，以确认它们能被正确识别，从而巩固了你对如何区分合并提交和常规提交的理解。