<返回更多

解读那些令人困惑 Git 术语

2023-12-08  微信公众号  Linux中国
加入收藏

我在 Mastodon 上进行了调查：

你有觉得哪些 Git 术语很让人困惑吗？我计划写篇博客，来解读 Git 中一些奇怪的术语，如：“分离的 HEAD 状态”，“快速前移”，“索引/暂存区/已暂存”，“比 origin/mAIn 提前 1 个提交”等等。

我收到了许多有洞见的答案，我在这里试图概述其中的一部分。下面是这些术语的列表：

我已经尽力讲解了这些术语，但它们几乎覆盖了 Git 的每一个主要特性，这对一篇博客而言显然过于繁重，所以在某些地方可能会有一些粗糙。

HEAD 和 “heads”

有些人表示他们对 HEAD 和 refs/heads/main 这些术语感到困惑，因为听起来像是一些复杂的技术内部实现。

以下是一个快速概述：

我认为，“head 是一个分支，HEAD 是当前的分支” 或许是 Git 中最奇怪的术语选择，但已经设定好了，想要更清晰的命名方案已经为时已晚，我们继续。

“HEAD 是当前的分支” 有一些重要的例外情况，我们将在下面讨论。

“分离的 HEAD 状态”

你可能已经看到过这条信息：

$ git checkout v0.1
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
[...]

（消息译文：你处于 “分离 HEAD” 的状态。你可以四处看看，进行试验性的更改并提交，你可以通过切换回一个分支来丢弃这个状态下做出的任何提交。）

这条信息的实质是：

在合并或变基中的 “ours” 和 “theirs”

遇到合并冲突时，你可以运行 git checkout --ours file.txt 来选择 “ours” 版本中的 file.txt。但问题是，什么是 “ours”，什么是 “theirs” 呢？

我总感觉此类术语混淆不清，也因此从未用过 git checkout --ours，但我还是查找相关资料试图理清。

在合并的过程中，这是如何运作的：当前分支是 “ours”，你要合并进来的分支是 “theirs”，这样看来似乎很合理。

$ git checkout merge-into-ours # 当前分支是 “ours”
$ git merge from-theirs # 我们正要合并的分支是 “theirs”

而在变基的过程中就刚好相反 —— 当前分支是 “theirs”，我们正在变基到的目标分支是 “ours”，如下：

$ git checkout theirs # 当前分支是 “theirs”
$ git rebase ours # 我们正在变基到的目标分支是 “ours”

我以为之所以会如此，因为在操作过程中，git rebase main 其实是将当前分支合并到 main （它类似于 git checkout main; git merge current_branch），尽管如此我仍然觉得此类术语会造成混淆。

这个精巧的小网站 对 “ours” 和 “theirs” 的术语进行了解释。

人们也提到，VSCode 将 “ours”/“theirs” 称作 “当前的更改”/“收到的更改”，同样会引起混淆。

“你的分支已经与 origin/main 同步”

此信息貌似很直白 —— 你的 main 分支已经与源端同步！

但它实际上有些误导。可能会让你以为这意味着你的 main 分支已经是最新的，其实不然。它真正的含义是 —— 如果你最后一次运行 git fetch 或 git pull 是五天前，那么你的 main 分支就是与五天前的所有更改同步。

因此，如果你没有意识到这一点，它对你的安全感其实是一种误导。

我认为 Git 理论上可以给出一个更有用的信息，像是“与五天前上一次获取的源端 main 是同步的”，因为最新一次获取的时间是在 reflog 中记录的，但它没有这么做。

HEAD^、HEAD~、HEAD^^、HEAD~~、HEAD^2、HEAD~2

我早就清楚 HEAD^ 代表前一次提交，但我很长一段时间都困惑于 HEAD~ 和 HEAD^ 之间的区别。

我查询资料，得到了如下的对应关系：

这看起来有些奇怪，为什么 HEAD~ 和 HEAD^ 是同一个概念？以及，“第三个父提交”是什么？难道就是父提交的父提交的父提交？（剧透：并非如此）让我们一起深入探讨一下！

大部分提交只有一个父提交。但是合并提交有多个父提交 - 因为它们合并了两个或更多的提交。在 Git 中，HEAD^ 意味着 “HEAD 提交的父提交”。但是如果 HEAD 是一个合并提交，那 HEAD^ 又代表怎么回事呢？

答案是，HEAD^ 指向的是合并提交的第一个父提交，HEAD^2 是第二个父提交，HEAD^3 是第三个父提交，等等。

但我猜他们也需要一个方式来表示“前三个提交”，所以 HEAD^3 是当前提交的第三个父提交（如果当前提交是一个合并提交，可能会有很多父提交），而 HEAD~3 是父提交的父提交的父提交。

我想，从我们之前对合并提交 “ours”/“theirs” 的讨论来看，HEAD^ 是 “ours”，HEAD^2 是 “theirs”。

.. 和 ...

这是两个命令：

我从没用过 .. 和 ... 这两个命令，所以我得查一下 man git-range-diff。我的理解是比如这样一个情况：

A - B main
  
    C - D test

更有挑战的是，git diff 显然也支持 .. 和 ...，但它们在 git log 中的意思完全不同？我的理解如下：

有关这个的更多讨论可以参考 这篇博客文章。

“可以快速前移”

在 git status 中，我们会经常遇到如下的信息：

$ git status
On branch main
Your branch is behind 'origin/main' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

（消息译文：你现在处于 main 分支上。你的分支比 origin/main 分支落后了 2 个提交，可以进行快速前进。 (使用 git pull 命令可以更新你的本地分支)）

但“快速前移” 到底是何意？本质上，它在告诉我们这两个分支基本如下图所示（最新的提交在右侧）：

main:        A - B - C
origin/main: A - B - C - D - E

或者，从另一个角度理解就是：

A - B - C - D - E (origin/main)
        |
        main

这里，origin/main 仅仅多出了 2 个 main 不存在的提交，因此我们可以轻松地让 main 更新至最新 —— 我们所需要做的就是添加上那 2 个提交。事实上，这几乎不可能出错 —— 不存在合并冲突。快速前进式合并是个非常棒的事情！这是合并两个分支最简单的方式。

运行完 git pull 之后，你会得到如下状态：

main:        A - B - C - D - E
origin/main: A - B - C - D - E

下面这个例子展示了一种不能快速前进的状态。

A - B - C - X  (main)
        |
        - - D - E  (origin/main)

此时，main 分支上有一个 origin/main 分支上无的提交（X），所以无法执行快速前移。在此种情况，git status 就会如此显示：

$ git status
Your branch and 'origin/main' have diverged,
and have 1 and 2 different commits each, respectively.

（你的分支和 origin/main 分支已经产生了分歧，其中各有 1 个和 2 个不同的提交。）

“引用”、“符号引用”

在使用 Git 时，“引用” 一词可能会使人混淆。实际上，Git 中被称为 “引用” 的实例至少有三种：

个人而言，“符号引用” 这个术语颇为奇特，因为我觉得我只使用过 HEAD（即当前分支）作为符号引用。而 HEAD 在 Git 中占据核心位置，多数 Git 核心命令的行为都基于 HEAD 的值，因此我不太确定将其泛化成一个概念的实际意义。

refspecs

在 .git/config 配置 Git 远程仓库时，你可能会看到这样的代码 +refs/heads/main:refs/remotes/origin/main 。

[remote "origin"]
    url = git@Github.com:jvns/pandas-cookbook
    fetch = +refs/heads/main:refs/remotes/origin/main

我对这段代码的含义并不十分清楚，我通常只是在使用 git clone 或 git remote add 配置远程仓库时采用默认配置，并没有动机去深究或改变。

“tree-ish”

在 git checkout 的手册页中，我们可以看到：

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...

那么这里的 tree-ish 是什么意思呢？其实当你执行 git checkout THING . 时，THING 可以是以下的任一种：

对我个人来说，“提交内的目录”这个功能我从未使用过，从我的视角看，tree-ish 可以解读为“提交或对提交的引用”。

“索引”、“暂存”、“缓存”

这些术语都指向的是同一样东西（文件 .git/index，当你执行 git add 时，你的变动会在这里被暂存）：

尽管它们都是指向同一个文件，但在实际使用中，这些术语的应用方式有所不同：

“重置”、“还原”、“恢复”

许多人提到，“重置reset”、“还原revert” 和 “恢复restore” 这三个词非常相似，易使人混淆。

我认为这部分的困惑来自以下原因：

虽然这些简短的描述为你详细说明了哪个名词受到了影响（“当前 HEAD”，“某些提交”，“工作树文件”），但它们都预设了你已经知道在这种语境中，“重置”、“还原”和“恢复”的准确含义。

以下是对它们各自功能的简要说明：

“未跟踪的文件”、“远程跟踪分支”、“跟踪远程分支”

在 Git 中，“跟踪” 这个词以三种相关但不同的方式使用：

即使“未跟踪的文件”和“远程跟踪分支”都用到了“跟踪”这个词，但是它们所在的上下文完全不同，所以没有太多混淆。但是，对于以下两种方式的“跟踪”使用，我觉得可能会产生些许困扰：

然而，在 Git 中，“跟踪远程的分支” 和 “远程跟踪分支” 是不同的事物，理解它们之间的区别非常关键！下面是对这两者区别的一个简单概述：

我以前没有深入思考过这种模糊的地方，但我认为很容易看出为什么它会让人感到困惑。

签出

签出做了两个完全无关的事情：

这是众所周知的混淆点，因此 Git 实际上已经将这两个功能分离到了 git switch 和 git restore（尽管你还是可以使用 checkout，就像我一样，在不愿丢弃 15 年对 git checkout 肌肉记忆的情况下）。

再者，即使用了 15 年，我仍然记不住 git checkout main file.txt 用于从 main 分支恢复 file.txt 版本的命令参数。

我觉得有时你可能需要在 checkout 命令后面加上--，帮助区分哪个参数是分支名，哪个是路径，但我并未这么使用过，也不确定何时需要这样做。

参考日志（reflog）

有很多人把 reflog 读作 re-flog，而不是 ref-log。由于本文已经足够长，我这里不会深入讨论参考日志，但值得注意的是：

合并 vs 变基 vs 遴选

有许多人提及他们常常对于合并和变基的区别感到迷惑，并且不理解变基中的“基base”指的是什么。

我会在这里尽量简要的进行描述，但是这些一句话的解释最终可能并不那么明了，因为每个人使用合并和变基创建工作流程时的方式差别挺大，要真正理解合并和变基，你必须理解工作流程。此外，有图示会更好理解。不过这个话题可能需要一篇独立的博客文章来完整讨论，所以我不打算深入这个问题。

rebase --onto

在 git rebase 中，存在一个被称为 --onto 的选项。这一直让我感到困惑，因为 git rebase main 的核心功能就是将当前分支变基到 main 运行上。那么，额外的 --onto 参数又是怎么回事呢？

我进行了一番查找，--onto 显然解决了一个我几乎没有或者说从未遇到过的问题，但我还是会记录下我对它的理解。

A - B - C (main)
      
      D - E - F - G (mybranch)
          |
          otherbranch

设想一下，出于某种原因，我只想把提交 F 和 G 变基到 main 上。我相信这应该是某些 Git 工作流中会经常遇到的场景。

显然，你可以运行 git rebase --onto main otherbranch mybranch 来完成这个操作。对我来说，在这个语法中记住 3 个不同的分支名顺序似乎是不可能的（三个分支名，对我来说实在太多了），但由于我从很多人那里听说过，我想它一定有它的用途。

提交

有人提到他们对 Git 中的提交作为一词双义（既作为动词也作为名词）的用法感到困惑。

例如：

我觉得大多数人应该能很快适应这个双关的用法，但是在 SQL 数据库中的“提交”用法与 Git 是有所不同，我认为在 SQL 数据库中，“提交”只是作为一个动词（你使用 COMMIT 来结束一个事务），并不作为名词。

此外，在 Git 中，你可以从以下三个不同的角度去考虑一个 Git 提交：

  1. 表示当前每个文件状态的快照
  2. 与父提交的差异
  3. 记录所有先前提交的历史

这些理解都是不错的：不同的命令在所有的这些情况下都会使用提交。例如，git show 将提交视为一个差异，git log 把提交看作是历史，git restore 则将提交理解为一个快照。

然而，Git 的术语并无太多助于你理解一个给定的命令正在如何使用提交。

更多令人困惑的术语

以下是更多让人觉得混淆的术语。我对许多这些术语的意思并不十分清楚。

我自己也不是很理解的东西：

人们提及觉得混淆，但我在这篇已经 3000 字的文章中略过的东西：

人们提及感到困惑的 Github 术语：

确实是 “每个 Git 术语”

我惊讶地发现，几乎 Git 的每个其他核心特性都被至少一人提及为某种方式中的困惑。我对听到更多我错过的混淆的 Git 术语的例子也有兴趣。

关于这个，有另一篇很棒的 2012 年的文章叫做《最困惑的 Git 术语》。它更多的讨论的是 Git 术语与 CVS 和 Subversion 术语的关联。

如果我要选出我觉得最令人困惑的 3 个 Git 术语，我现在会选：

就这样了！

在写这些的过程中，我学到了不少东西。我了解到了一些新的关于Git的事实，但更重要的是，现在我对于别人说Git的所有功能和特性都引起困惑有了更深的理解。

许多问题我之前根本没考虑过，比如我从来没有意识到，在讨论分支时，“跟踪”这个词的用法是多么地特别。

另外，尽管我已经尽力做到准确无误，但由于我涉猎到了一些我从未深入探讨过的Git的角落，所以可能还是出现了一些错误。

关键词：Git      点击(10)
声明：本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系，我们将立即删除或处理。
▍相关推荐
更多Git相关>>>
Copyright @ 简易百科 V 2.0 京ICP备14042104号