为什么 Git 如此复杂

当你学习编程时，人们通常会推荐学习 Git。从理论上讲，这听起来很简单：一个跟踪代码更改的程序，可帮助您在需要时恢复以前版本的代码。除此之外，它还是一个在行业中几乎无处不在的工具。在实践中……Git 至少可以说是令人困惑的。

为什么一定要这样？

命令行界面—CLI

大多数计算机的日常用户不习惯基于文本的界面。我称之为奢侈，因为正如我之前所写，它有一些很大的优势——尽管它可能需要一些时间来适应用户体验。因此，如果您的关联与列表中的关联相匹配：

• cat ——毛茸茸的动物，
• cd人们过去是如何听音乐的，以及
• grep一些象声词，

那么您第一次使用 Git 时，学习命令行基础知识可能会有额外的困难。 Windows 95 及其同类产品从您那里夺走了一些东西。

Git的设计目标

Git 从来就不是简单的。它的制作考虑了不同的目标：更重要和更具挑战性的目标。

安全地存储保存的数据

Git 旨在始终将数据准确地返回给您，或者让您知道存储库已损坏。它用它做了一件了不起的工作——你可以确定你在签出提交时得到的状态与它的作者想要的完全一样。当然，这是假设他们知道自己在做什么。

Git 是如何做到这么好的数据安全性的呢？它以巧妙的方式存储所有内容——提交、文件夹和文件。每个对象都由其内容的加密哈希值标识——一个基于对象内容生成的数字，如果文件中的任何内容发生更改，该数字也会更改。因为对象之间的引用也是散列的，所以几乎没有办法在 Git 没有注意到某些东西关闭的情况下篡改存储库内部。即使在这些情况下，有意义的代码也会被长文本乱码所取代。

跨不安全的网络与不可信的参与者一起工作

因为所有内容都由加密哈希值标识，所以 Git 不必信任很多网络来保持数据的完整性。 Git 免受中间人攻击：没有人可以在 Git 的两个节点之间注入有意义的代码。当然，如果有人可以读取他们不想要的提交，这也是一个问题，但比攻击者将代码注入代码库的危险后果要小。

为了提供额外的安全层，Git 提供了注册提交——一种确保提交由设置为作者的人编写的额外方法。

保持向后兼容性

Git 界面比它必须的更复杂，因为它尊重用户的旧习惯。我是2011年开始学Git的，直到上周才注意到有一个新的git switch命令推荐用来切换分支。我习惯这样做的方式（ git checkout + 各种标志）仍然可以正常工作。 Git 优先考虑老用户和他们的习惯，而不是新用户的简单性——这将我们带到下一点。

超级用户的用户体验

Git 是为超级用户而设计的工具。它由 Linus Torvalds 编写，用于管理 Linux 代码库——不是初学者的任务。 Git 的主要用户开发操作系统，拥有数十年的编程经验，并且生活在命令行中。除此之外的所有用途都是偶然的，并不是开发 Git 的人主要关心的问题。

简单权衡

当您设计系统时，没有什么是免费的——包括用户在内的简单性。

隐藏复杂性

当你处理一个本质上很复杂的问题时，你可以通过抽象掉复杂性来简化解决方案。它走了吗？不，它只是对用户隐藏。例如，在互联网连接的情况下，我和大多数人只将连接质量理解为 📶 的条数：

• 越少越好
• 越多越好

这对于使用 Internet 来说已经足够了，但是却很难理解和解决任何连接问题。

Git 专注于公开并行更改文件和以异步方式同步所带来的所有复杂性。在另一端，您可以直接访问共享磁盘。它很容易使用，但是当两个人试图同时编辑同一个文件时会发生什么？一个人会很幸运，会保留他们的改变，而另一个人会失去一切。这不是一个很好的工作流程，特别是如果丢失的更改值得花费数小时的昂贵劳动力。因为 Git 向用户公开了在这种情况下可能出现的所有问题，所以它可以以智能方式解决文件中的冲突——在某些情况下，这需要用户手动执行。

简单与安全

Git 的另一个让用户感到困惑的部分是提交 ID 非常长，而且无法记住数字。即使是用户友好的缩写形式，它们看起来也像0828ae1 。完整的 ID 是0828ae10b20500fbc777cc40aa88feefd123ea5e 。我们可以只按顺序排列数字，还是只使用分支名称？问题在于提交 ID 是保证数据完整性的哈希值——它们保证我机器上的提交 X 与远程或您机器上的提交 X 相同。由于不同的原因，它们之间可能会出现不匹配：

• 有意的——变基、修改、压缩或任何其他改变历史的操作
• 无意的——错误或对代码库的攻击

简化界面并向用户隐藏提交 ID 将消除用户了解他们在其计算机上运行的代码库上发生的事情的可能性。而且由于代码是在机器上运行的，因此任何安全漏洞都是极其危险的。

这是正确的方法吗？

在我学习 Git 的时候，它还是一个新鲜事物——我是 2011 年学习的，Git 创建于 2005 年（第一次提交是从Thu Apr 7 15:13:13 2005 -0700 开始）。当时我在工作中使用SVN ， Mercurial通常被认为是 Git 的更用户友好的替代品。你最近听说过这些名字吗？ Git 几乎完全统治了版本控制市场。它随着 GitHub 的兴起而广受欢迎，但即使对于初学者来说它很粗糙，它也是一个非常有效的工具，而且它会一直存在。

作为初级程序员应该怎么做？

我的建议是尽早学习它。 Git 不太可能很快变得更简单。或者曾经。版本控制系统通常可以在您编程时省去很多麻烦。如果您努力移动代码库的版本，我无法想象如何高效地使用代码。学好 Git 将帮助您专注于代码挑战，而不是为丢失的文件而苦苦挣扎或修复所谓的“Git 问题”——这些问题几乎总是人们自己搞砸了他们的存储库。

除此之外，学习 Git 已成为新开发人员的必经之路。作为一名开发人员，您必须使用它，如果您在没有很好地理解它的情况下尝试使用它，Git 会让您的生活变得悲惨。明智的选择是按照自己的方式学习它，而不是等到审阅者反馈或代码问题迫使您在处理其他职责的同时学习它。

如何学习更多？

如果您有兴趣了解有关 Git 的更多信息，请在此处注册以获取有关我的以 Git 为中心的内容的更新。