一、Git 入门：从零开始的版本控制之旅
说实话，我刚入行那会儿，对版本控制的理解就是「文件备份」。每天下班前把代码复制到 U 盘，文件名改成 项目_2021_08_15_最终版。直到有一天，我把「最终版」和「真·最终版」搞混了，被老大骂了一顿。嗯，从那以后，我才真正开始研究 Git。
这一章，咱们就从头聊聊 Git 是什么、它怎么来的、跟 SVN 有啥区别，以及怎么装怎么用。你想想看，如果连工具的历史和设计哲学都不了解，后面学再多命令也是空中楼阁。
1.1 Git 发展史：一个天才的周末项目
Git 的故事得从 2005 年说起。当时 Linux 内核社区用的版本控制工具叫 BitKeeper，本来是免费用的。后来 BitKeeper 收回了免费授权，Linus Torvalds 一怒之下——对，就是 Linux 的创始人——决定自己写一个版本控制系统。
我印象特别深，Linus 当时说了一句话：「我花了两周写了个 Git，你们别跟我说这玩意儿有多难。」实际上，Git 的核心代码在 10 天内就完成了。为什么这么快？因为 Linus 对版本控制有非常清晰的目标：
- 速度：必须比任何现有工具都快
- 分布式：每个人都是完整的仓库
- 数据完整性：内容用 SHA-1 哈希校验，改一个比特都能发现
- 支持非线性开发：分支和合并必须轻量且高效
我在项目中遇到过不少人对 Git 的哈希机制不理解，觉得「不就是个版本号吗？」其实不是。Git 的每个提交、每个文件、每个目录都会生成一个 40 位的 SHA-1 哈希值。这意味着什么？意味着你的代码历史是不可篡改的。我曾经帮同事恢复过误删的分支，靠的就是哈希值定位——这要是 SVN，基本没戏。
核心要点：Git 不是 Linus 拍脑袋想出来的，而是为了解决真实痛点——分布式协作、代码完整性、分支灵活性。理解这个背景，你就能明白为什么 Git 的命令设计「反直觉」但「有道理」。
1.2 Git vs SVN：为什么 Git 赢了？
我刚开始工作时，公司用的是 SVN。那时候觉得 SVN 挺好的啊，有中央服务器，有版本号，还能锁定文件。直到我参与了一个 20 人的项目，才体会到 SVN 的痛：
| 对比维度 | Git | SVN |
|---|---|---|
| 架构 | 分布式，每个本地都是完整仓库 | 集中式，依赖中央服务器 |
| 分支 | 轻量级，创建/切换秒级完成 | 重量级，本质是目录拷贝 |
| 离线工作 | 完全支持，提交、日志、分支均可离线 | 大部分操作需要联网 |
| 数据存储 | 快照式存储，每次提交保存完整文件快照 | 差异式存储，只保存文件变更 |
| 安全性 | SHA-1 哈希校验，内容不可篡改 | 依赖服务器权限控制 |
| 学习曲线 | 较陡，概念多（暂存区、哈希、引用） | 较平缓，概念简单 |
说白了，SVN 适合「一个人写代码，其他人围观」的场景。而 Git 适合「所有人都在改代码，还要并行开发多个功能」的场景。我个人习惯用 Git 做分支管理，每个功能一个分支，互不干扰。你想想看，如果 SVN 要创建 10 个分支，服务器上得拷贝 10 份目录——这得多浪费空间？
我的建议：如果你还在用 SVN，别急着全盘迁移。可以先在个人项目上用 Git，感受一下「离线提交」和「随意分支」的爽快感。等你习惯了，自然就不想回去了。
1.3 Git 工作流程：三个区域与四种状态
Git 的工作流程，说白了就是文件在三个区域之间流转：工作区、暂存区、仓库。我刚开始学的时候，总觉得「暂存区」是多余的——为什么不能直接提交？后来才明白，暂存区让你可以「挑着提交」，而不是一股脑全塞进去。
举个例子：你改了三个文件，但只想提交其中两个。在 SVN 里，你得先复制一份，删掉不想提交的，再提交。在 Git 里，你只需要 git add 那两个文件，然后 git commit 就行。第三个文件还在工作区，不受影响。
下面这张图，是我自己画的工作流程示意，你看一眼就明白了：
对应到文件状态，Git 有四种状态：
- 未跟踪（Untracked）：新文件，Git 还没管它
- 已暂存（Staged）：文件已加入暂存区，等待提交
- 已修改（Modified）：文件被改了，但还没暂存
- 已提交（Committed）：文件已安全存到仓库里
我曾经犯过一个低级错误：在项目上线前，直接在工作区改了配置文件，忘了 git add 就提交了。结果线上配置没更新，出了事故。从那以后，我每次提交前都会用 git status 确认一遍——这个习惯救了我好几次。
避坑指南：我曾经因为没搞清楚「已修改」和「已暂存」的区别，用 git checkout -- file 把辛苦改了一天的代码全丢了。记住：git checkout -- file 会丢弃工作区的修改，且不可恢复！如果你不确定，先用 git stash 暂存起来。
1.4 Git 安装与配置：从零开始搭环境
安装 Git 其实很简单，但配置这一步很多人会跳过。我建议你花 5 分钟配好，后面能省很多事。
安装方式
- Windows：去官网下载安装包，一路 Next。注意勾选「Git Bash Here」和「Git GUI Here」
- macOS：
brew install git或者直接装 Xcode Command Line Tools - Linux：
sudo apt install git（Ubuntu）或sudo yum install git（CentOS）
全局配置（必须做）
安装完后，第一件事就是设置你的名字和邮箱。为什么？因为每次提交都会记录这些信息，方便团队知道是谁改的。
# 设置用户名和邮箱（替换成你自己的）
git config --global user.name "Zhang San"
git config --global user.email "zhangsan@example.com"
# 查看配置
git config --list
# 设置默认分支名为 main（2020 年后 GitHub 默认改了）
git config --global init.defaultBranch main我个人习惯还会配几个别名，省得每次敲长命令：
git config --global alias.st status
git config --global alias.ci commit
git config --global alias.br branch
git config --global alias.co checkout
git config --global alias.lg "log --oneline --graph --all"配完之后，git st 就等于 git status，是不是爽多了？
小技巧：如果你用 Windows，建议把 Git Bash 的默认编码改成 UTF-8，否则中文文件名会乱码。命令是：git config --global core.quotepath false。
验证安装
打开终端，输入 git --version，如果看到版本号，说明安装成功。我建议用 2.30 以上的版本，新版本修复了很多安全漏洞。
1.5 第一个 Git 仓库：从初始化到第一次提交
光说不练假把式。咱们来创建一个真正的 Git 仓库：
# 创建一个新目录
mkdir my-first-repo
cd my-first-repo
# 初始化 Git 仓库
git init
# 创建一个文件
echo "# Hello Git" > README.md
# 查看状态（README.md 应该是未跟踪状态）
git status
# 添加到暂存区
git add README.md
# 提交到仓库
git commit -m "第一次提交：添加 README 文件"看到 1 file changed, 1 insertion(+) 这样的输出，恭喜你，你的第一个 Git 提交完成了！
嗯，这里要注意：git init 会在当前目录下创建一个隐藏的 .git 文件夹，里面存着所有版本历史。千万别手贱删掉它——删了就等于丢了所有历史记录。
总结一下：Git 入门其实就三件事——理解它的设计哲学（分布式、快照、哈希）、掌握三个区域（工作区、暂存区、仓库）、学会基本操作（init、add、commit、status）。后面的分支、合并、远程协作，都是在这个基础上延伸的。
好了，这一章的内容就到这儿。Git 的世界很大，但咱们已经迈出了第一步。记住：别怕犯错，Git 最强大的地方就是「几乎什么都能恢复」。放心大胆地去试吧。