Git 入门

在正式介绍 Git 之前，我们先明确一个重要的问题：如何高效、可靠地管理我们不断变化的数字作品？

以“版本控制”为例，无论代码、文档还是设计稿，都需要在持续修改和迭代过程中，能够有序地记录与管理历史变更。在缺乏专业工具的情况下，最原始的方法通常是人为地保存多个不同版本的文件，例如 项目_草图.jpg、项目_初稿.jpg、项目_最终版.jpg，通过文件名来区分各个阶段。

但这种方法管理复杂且极易出错，很难支持高效的协作开发和精确的历史回溯。而版本控制系统（Version Control System, VCS）则应运而生。它专门用于记录和管理文件或项目在不同时间点的状态，能够让用户随时恢复到任意历史版本，并全面追踪每次修改的内容及其作者。

现代的版本控制是所有软件开发及数字内容协作不可或缺的基础设施。通过系统化地管理版本历史，团队成员可以并行开发，无需担心误操作导致的数据丢失或冲突，并能清楚地掌握项目的演进过程。

版本控制的演化史

版本控制本身，也经历了一段有趣的进化史，就像是从单机游戏进化到了云端世界。

本地版本控制

最早的时候，程序员们在自己的电脑上创造了“本地版本控制系统”。这好比那位画家，把所有的草稿都保存在自己的一台电脑里。 这套系统很方便，解决了“另存为”的混乱问题，但它的致命弱点在于——所有的历史记录都困在一台机器上。一旦硬盘损坏，那就像艺术家的画室着火，所有的心血都将付之一炬。而且，这也让合作变得异常困难。

集中化版本控制

为了解决合作的问题，“集中化版本控制系统”（CVCS）应运而生。你可以把它想象成一个中央美术馆的服务器。 所有参与创作的画家，都把自己的作品上传到这个中央服务器。大家都能看到彼此的进度，管理员也能精细地控制每个人的权限。 这在很长一段时间里都是主流。但它的问题也很明显：它太依赖那个“中央美术馆”了。如果美术馆的网络断了，所有人都得停工；如果它的服务器崩溃了，而又没有妥善的备份，那将是一场毁灭性的灾难，整个项目的历史都可能烟消云散。

分布式版本控制

于是，更先进的“分布式版本控制系统”（DVCS）登上了历史舞台，而我们故事的主角——Git，正是其中的佼佼者。

在分布式的世界里，游戏规则彻底改变了。它不再是只有一个中央美术馆，而是当一位画家连接到服务器时，他下载的不仅仅是最新的画作，而是将整个美术馆的全部历史——每一幅草稿、每一次修改——完整地克隆了一份到自己的电脑上。 这意味着，每个人的电脑都是一个功能完整的备份。即使中央服务器彻底瘫痪，任何一位画家都可以用自己的本地副本，将整个项目历史恢复如初。

更棒的是，这种模式让离线工作变得轻而易举。你可以在没有网络的飞机上、火车上，随心所欲地创作和“提交”你的新版本，等到有网络时，再与他人同步。

Git 的诞生

Git 的诞生本身也颇具传奇色彩。它由 Linux 的创始人 Linus Torvalds 在 2005 年创造。当时，Linux 内核开发社区与他们之前使用的商业版本控制系统 BitKeeper 关系破裂，Linus 被“逼上梁山”，索性自己动手， 基于多年来维护大型开源项目的经验，创造了一个全新的工具。

他为 Git 定下了几个目标：速度飞快、设计简洁、强力支持非线性开发（即成千上万个并行分支）、完全分布式，并且能高效处理像 Linux 内核这样庞大的项目。 Git 的核心思想，与它的前辈们有一个根本性的区别。理解这一点，能让你更快地掌握 Git 的精髓。

快照，而非差异

其他版本控制系统大多记录的是“文件的变化量”。好比一本账本，记录着“张三在 A 文件第三行增加了一句话”，“李四删除了 B 文件的结尾”。 而 Git 的思路则完全不同，它不关心“变化”，只关心“状态”。

为了效率，如果文件没有变动，Git 不会重复存储，只是保留一个指向上一次快照的链接。所以，Git 的历史，就是一连串的快照流。 这个看似微小的差异，让 Git 在处理分支等操作时，展现出惊人的强大和灵活性，我们会在后续部分详细介绍。

近乎一切操作都在本地

另外，Git 的绝大部分操作都依赖本地资源，几乎不需要访问网络。无论是查看历史、比较文件差异，还是提交新的版本，都在你的电脑上瞬间完成。这赋予了 Git 风驰电掣般的速度。

数据的完整性

Git 中所有的数据在存储前都会计算校验和，并以校验和来引用。这意味着任何文件或目录的内容在未经 Git 知晓的情况下被修改，Git 都能立刻发现。 这个功能被植入在 Git 的最底层，是其哲学的核心。你不用担心信息在传输时丢失或损坏，因为 Git 总能检测到。 这种校验和机制被称为 SHA-1 哈希，它是一个由40个十六进制字符组成的字符串，看起来像这样：24b9da6552252987aa493b52f8696cd6d3b00373。在 Git 的世界里，一切都由它的哈希值来标识，而不是文件名。

只增不减的数据

当你在 Git 里操作时，绝大多数动作都只是向数据库中添加数据。你很难让系统做出任何不可撤销的操作，或者以任何方式擦除数据。 就像在任何版本控制系统里一样，你可能会丢失或搞砸尚未提交的更改；但一旦你将快照提交到 Git，它就很难丢失，特别是当你定期将数据库推送到另一个仓库时。 这让使用 Git 成为一种乐趣，因为我们知道可以放心大胆地进行实验，而不用担心会严重搞砸。

Git 的三大区域

在 Git 的世界里，还有一个至关重要的概念，那就是文件的“三种状态”，这也是初学者需要用心理解的地方。为了让这个过程不那么抽象，我们不妨用一个烹饪的比喻来理解它。 你的 Git 项目主要由三个区域构成：工作区（Working Directory）、暂存区（Staging Area）和 Git 仓库（Git Directory）。

1. 工作区：这就是你的厨房操作台。你在这里切菜、调味，对文件进行各种修改。此刻，文件处于“已修改”（Modified）状态。
2. 暂存区：这是你准备上菜前的备菜区。你把切好的、搭配好的菜，整齐地放进一个盘子里，准备下锅。这个“放入盘子”的动作，就是 git add 命令，它将你工作区的修改“暂存”起来，标记这些改动将要进入下一次的正式提交。此时，文件处于“已暂存”（Staged）状态。
3. Git 仓库：这就是你的菜谱宝典。当你执行 git commit 命令时，暂存区里准备好的“一盘菜”就被正式烹饪、拍照，并永久地记录到了你的菜谱里。一旦进入仓库，这个版本就处于“已提交”（Committed）状态，被安全地保存了下来。

第一次使用 Git

在开始你的 Git 之旅前，你需要在你的电脑上安装它。无论你使用 Linux, Mac, 还是 Windows，都可以通过Git官网 轻松找到并安装。

安装完成后，还有一件只需做一次的重要事情：设置你的身份。你需要告诉 Git 你是谁，因为你的每一次提交，都会刻上你的名字和邮箱。

|
$ git config --global user.name "你的名字"
$ git config --global user.email "你的邮箱@example.com"

这就像是在你的每一件作品上署名。--global 选项意味着，这台电脑上所有的 Git 项目都会默认使用这个身份。 你还可以设置你偏爱的文本编辑器。当 Git 需要你输入一些提交信息时，就会自动打开它。 完成了这些，你就已经为进入 Git 的精彩世界做好了全部准备。