为什么 Git 这么难？

作者 | Nick Eff      译者 | 弯月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

在工作中，我经常需要教其他人学习如何使用 Git 及其更高级的功能。在这个过程中，这些聪明且坚持学习的人往往连基础知识都无法掌握，这令我十分恼火，因为我自诩擅长解释事物。有时，我给他们解释 rebase 就像解释波粒二象性一样，满屋子的人以一种听天书的眼神看着我。

所以，这个周末之前我花了一些时间来思考为什么学习 Git 这么难的问题。

不是因为 Git 的命令行界面太差

有一个很明显的原因，Git 的命令行界面太差。但这个理由还不够充分，因为我们都见过更差的界面（或者，几乎差不多的情况）。

只要你对想完成的目标有详细的了解，就应该可以通过记忆和外部的参考资料来解决这个问题。虽然很麻烦，但至少有一条已知的学习途径。而学习 Git 的人并没有这个问题。

奇怪的思维模式

这个问题可以分为两部分讨论：

除非你掌握了 Git核心概念的思维模式和相应的类比（对象以及可以执行的操作），否则不可能安全地使用 Git。

Git 的核心概念完全不同于大多数人看待世界的方式。因此，用户倾向于采用更舒服（但不可行）的类比，这会导致混乱和结果不可预测。（此外，Git 的命令行界面极大地模糊了这些核心概念，因此任何人学习的时候都要经历一场艰难的考验，即使他们的思维方式正确也无济于事。）

我发现真正的问题在于，新手用户无法针对想要完成的任务制定有效的计划。有时，我会尝试让他们描述自己正在做什么，通常得到的答案不仅不完整或幼稚，而且非常混乱。

以下各项是 Git 超出人们的想象力和理解力的一些重要方面：

提交是 Git 世界线的唯一组成部分

提交内容既是快照也是补丁

远程操作的定义模糊，还有一定的延迟

分支并不完全是分支，它们更像是小书签

合并冲突非常难

git pull 操作存在

提交是 Git 世界线的唯一组成部分

提交是唯一且不可变的，而且还被固定到了历史与因果关系图中的特定点。这意味着，提交的身份由内容和上下文组成。（如果提交的内容相同，但父项不同，则不是同一个提交。）反过来，这意味着你需要适应分支多世界宇宙学，能够区分具有相同意图和内容的变更与快照，明白它们完全不可互换，并且代表完全不同的历史事件流程。

新手 Git 用户往往认为内容本身就构成了身份，这种思维方式虽然更自然，但会给你带来很多麻烦。

提交内容既是快照也是补丁

Git提交作为快照存储在磁盘上，但你不一定要将它们当成快照。各种 Git 命令不仅将提交视为完整的代码库快照，还会将其视为变更集合，具体取决于执行的操作。（作为补丁的提交并没有持久存储在某个地方，而是根据需要通过与其父级进行比较而派生。）

举个例子，cherry-pick 或 revert 之类的命令将提交视为补丁。show 将提交视为两者兼而有之，具体取决于参数！

Git新手用户往往很难理解自己的操作将提交视为了快照还是补丁，这给制定可靠的计划增加了一些额外的困难。

远程操作身份模糊，还有一定的延迟

你需要了解下述概念：

本地代码库。

上游远程库的“真正”版本，位于网络中的另一台计算机上。

最后一次获取的上游远程分支的本地缓存副本。

本地代码库的分支，标记为与上游远程中的某个分支同步。

以上后三者的更多实例，因为你可能有多个远程和许多跟踪分支。

Git新手用户根本无法区分这些概念。命令行界面未能消除歧义，而且关系和交互也很复杂。举个例子，考虑如下：

你的本地克隆也叫 remote。

分支名称在多个远程代码库之间完全独立。（通常我们会认为名称表示全局身份。然而，在 Git 中却并非如此！你的 main 与上游的 main 或分支的 main 没有特殊联系，这只是一种习惯约定。）

但是，提交有一个稳定的全局身份！标签也是，虽然其身份比提交弱一些。

顺便问一下，origin是什么意思？并没有特别规定，它只是 git clone 创建的默认名称，但它指的究竟是上游代码库、你的 GitHub 分叉，还是别的东西？重命名远程到很后面才会接触，这意味着在推送的时候，你经常会感到困惑。（我建议重命名origin，这样任何远程都代表某个上游或某个代码库，但这只是我个人的经验之谈。）

“跟踪分支”实际上并不特殊，它们只是注册一些方便使用的命令的方式。你可以推送或合并任何事物。

正斜杠（/）有时是特殊的命名空间分隔符，用于表示缓存的远程分支，有时则不然。

但是，将分支推送到远程时，切勿使用斜杠，而应使用空格。（因为这时你操作对远程代码库，而不是本地的缓存远程库。）

当报告跟踪分支的状态时，Git 会使用缓存的远程内容，但这些内容可能已经过期，并且根据真实的远程状态你的推送可能会被拒绝。

分支并不完全是分支，它们更像是小书签

对此，我不知道如何更好地解释，但你可以理解为：分支的有向无环图结构是不可变提交历史所固有的，而 Git“分支”实际上只是一个元数据，可以帮助你更方便地浏览结构：

分支就像书签一样，你可以在它们之间快速切换。

当前分支会随着你所做的每一次新提交而向前推进，可以更轻松地跟踪你的工作。

但是，你可以挑选一个分支，并将其放置在图的任意一点（git reset）。

分支并不相互排斥，它们并不“拥有”自身所处的历史分支。

所以，分支就是可以移动的小书签。你可以把它们想象成其他东西，而且最终你发现它们的行为方式确实令人困惑。

合并冲突非常难

这实际上并不是一个概念问题，通常人们会理解为“我们的改动相互冲突”。分析并解决冲突本来就很难。“如果我事先看到了你的改动，我会怎么改？”这是一个非常复杂的问题，这个问题的出现远远早于一小部分改动出现冲突，何况现有的界面在将冲突概念化方面做得非常糟糕，很容易让人头昏脑胀。

gitpull 操作存在

也许只有我一个人这么想，但这个问题确实让我感到很困惑，我们教给新用户的第一件事就是依赖一个命令，而且这个命令的意思翻译过来就是：立即改变我的本地分支，以反映上游发生过的编辑，但根据定义，我没有机会通过任何明确的行为（这些行为由配置控制，但一般新手都不太理解配置）审核代码，也无法确定我的改动是否有可能破坏分支的现有因果历史。

我更喜欢的行为是按照某人的建议设置 pull.rebase = true，然后让新手将他们协作的分支 pull 到其他人刚刚合并过的 origin/main 上。这样就可以减少混乱！

“pull”代表了一种幻象：你只希望 Git 完美地做好一切，让你能够正确地 push，而不用理解究竟发生了什么。如上所述，这与 Git 的工作原理完全相悖。这种幻像非常有害！我们在教新手时，能不能先让他们理解“fetch，观察，理解之后再决定是做 fast-forward 还是 merge 还是 rebase 还是 reset”？

那么怎么办？

我不知道。

好吧，我有个很强烈的想法：在教新手时，你必须不断强化核心概念。不厌其烦地要求新手解释他们对于任务的理解，阐明他们的思维模型，直到他们能够准确预测 Git 怎样执行各种命令。采用各种解释和比喻，直到找到一种适合他们的思维的比喻，而且要接受，你永远不是最后一个使用这种比喻的人。

但我还没有找到任何放之四海而皆准的比喻。有一些有趣的可视化的确有帮助，但并没有解释“代码变更内容本身并不是身份的全部”。

一些工具可以帮助用户提升对这些概念的理解，从而不断改进预期和估计。我特别喜欢展示历史图，可以通过外部应用程序和 gitx/gitk 等工具，以及我最爱的 log --date=format:'%a %b %e, %Y' --pretty=format:'%C(yellow)%h%C(reset)%s %C(cyan)%cd%C(reset) %C(blue)%an%C(reset) %C(green)%d%C(reset)' --graph 命令（可以放到.gitconfig 中并起个别名 lg，如果行太长，可以使用-S 作为换行）。但历史图至少需要部分理解概念，否则只不过是另一个令人头晕目眩的东西。

毕竟，这才是 Git 难学的真正原因。