Git 版本控制系统详解

Git 是全球最流行的分布式版本控制系统，由 Linus Torvalds 于 2005 年为 Linux 内核开发而创建。它将数据视为快照流（stream of snapshots），而非基于文件的增量差异（delta），几乎所有操作均为本地执行，速度极快。

1. 概述

1.1 Git 是什么

Git 本质上是一个内容寻址文件系统（content-addressable filesystem），其核心是一个简单的键值（key-value）数据库。任何内容都可以通过 git hash-object 存入 Git，Git 会返回一个 40 字符的 SHA-1 哈希作为唯一键。

1.2 三种状态与三个区域

Git 中文件有三种状态——已修改（modified）、已暂存（staged）、已提交（committed），对应三个工作区域：

基本工作流：修改文件 → 暂存变更 → 提交快照。

1.3 Git 与 SVN/CVS 的核心差异

传统集中式 VCS（如 SVN、CVS）以文件差异列表（delta-based）的方式存储数据：记录每个文件随时间变化的增量。Git 则将数据视为小型文件系统的快照流：每次提交时对整个项目拍照，未变化的文件不重复存储，仅存一条链接。

2. 行为图（系统"做什么"）

2.1 用例图 — Git 用户交互全景

图 1：Git 用例图

2.2 活动图 — 基本工作流

图 2：Git 基本工作流活动图（带泳道）

2.3 状态机图 — 文件生命周期

Git 文件中文件在不同区域之间流转，构成完整的状态机：

图 3：文件生命周期状态机图

2.4 序列图 — 提交过程

当用户执行 git commit 时，Git 内部如何创建 blob、tree、commit 三种对象：

图 4：git commit 内部序列图

3. 结构图（系统"由什么组成"）

3.1 组件图 — 核心架构

Git 内部由四种核心对象类型（blob、tree、commit、tag）和引用系统（refs、HEAD）组成，协同工作构成完整版本控制系统：

图 5：Git 内部架构组件图

3.2 对象模型

Git 底层四种对象类型及其关系：

图 6：Git 对象模型关系图

对象存储机制：每个对象存储时，Git 会构造一个 header（格式："对象类型 内容长度\0"），与内容拼接后计算 SHA-1 哈希，再经 zlib 压缩写入 .git/objects/<前2字符>/<后38字符>。

3.3 部署图 — 分布式拓扑

Git 是分布式系统，多个仓库通过推拉操作实现同步：

图 7：Git 分布式协作部署图

4. 实战速查手册

4.1 仓库操作

4.2 基本快照

4.3 分支与合并

4.4 远程协作

4.5 历史与追溯

4.6 撤销与修复

4.7 底层对象检查 (Plumbing)

4.8 分支工作流示例

GitHub Flow

git checkout -b feature/xxx       # 从 main 创建功能分支
# ... 开发 & 提交 ...
git push origin feature/xxx       # 推送功能分支
# 在 GitHub 上创建 Pull Request
# 审查通过后合并到 main
git checkout main
git pull origin main              # 拉取最新 main
git branch -d feature/xxx         # 删除本地功能分支

Git Flow（适用于有版本发布周期的项目）

# 主分支: main (生产) + develop (开发)
git checkout -b release/1.0 develop  # 创建发布分支
# ... 修复 bug ...
git checkout main
git merge --no-ff release/1.0     # 合并到主分支
git tag -a v1.0 -m "Release 1.0"  # 打版本标签
git checkout develop
git merge --no-ff release/1.0     # 合并回开发分支
git branch -d release/1.0

4.9 回滚到指定 commit

当需要将分支回滚到某个历史 commit 并推送到远程时，有三种方案，按安全性从低到高排列：

方案一：reset --hard + force push（最直接）

git reset --hard <commit-sha>
git push --force origin <branch>

原理：直接将 HEAD 和分支引用移动到目标 commit，然后 force push 覆盖远程。

方案二：git revert（安全，不改写历史）

# 假设当前在 9b58a06，目标回滚到 6eef430
# 6eef430 之前有 2 个 commit 需要撤销
git revert --no-commit HEAD~1..HEAD
git commit -m "Revert to <commit-sha>"
git push origin <branch>

原理：生成一个新的 revert commit，反向操作目标 commit 之后的所有变更，不修改已有历史。

方案三：备份分支 + reset + force push（推荐）

# 1. 备份当前状态
git branch backup-<branch>

# 2. 硬回滚
git reset --hard <commit-sha>

# 3. 强制推送
git push --force origin <branch>

原理：在方案一的基础上先创建备份分支，保留当前 HEAD 的引用（仅本地），万一需要恢复可以随时切回。

三种方案对比

4.10 git rebase 详解

git rebase 将一个分支的提交记录按顺序重放到目标分支的顶端，从而获得一条线性、整洁的历史。它本质上是"复制"提交——每个提交都会基于新基底重新生成，得到全新的 SHA-1 哈希，因此属于改写历史的操作。

4.10.1 rebase 与 merge 对比

图 8：git merge 与 git rebase 对比

4.10.2 基本用法

git rebase <branch>                 # 将当前分支的提交重放到 <branch> 顶端
git rebase origin/main              # 同步远程最新，常用在 push 被拒后
git pull --rebase origin main       # fetch + rebase（等价于上面两步）
git rebase -i HEAD~3                # 交互式重写最近 3 个提交
git rebase --continue               # 解决冲突后继续
git rebase --skip                   # 跳过当前提交（放弃该提交）
git rebase --abort                  # 放弃整个 rebase，回到操作前状态

典型场景：本地 push 被拒绝（远程有新提交）时，用 git rebase origin/main 将本地提交重放到远程最新提交之上，再 push，避免产生多余的 merge commit。

4.10.3 交互式 rebase（rebase -i）

git rebase -i <base> 打开一个编辑列表，每行是一个待重放的提交，可通过修改命令词来改写历史：

git rebase -i HEAD~3   # 示例：合并最近 3 个提交为 1 个
# 编辑器中调整：
#   pick  1a2b3c feat: 功能 A
#   fixup 4d5e6f 补丁修正
#   fixup 7g8h9i 格式调整
# 保存退出后，三个提交合并为一个

4.10.4 冲突处理

rebase 是逐提交重放，冲突会多次出现。处理流程：

git rebase origin/main       # 触发冲突
git status                   # 查看冲突文件（<<<<<<< HEAD ======= >>>>>>> 标记）
# 手动编辑冲突文件，保留正确内容
git add <file>              # 标记已解决
git rebase --continue        # 继续下一个提交
# 反复直到全部重放完成；想放弃则: git rebase --abort

4.10.5 黄金法则与风险

• 丢失提交信息：squash/fixup 会合并提交信息，原始的中间过程描述消失
• 与 force push 配合有风险：rebase 后 push 被拒时需 git push --force-with-lease（比 --force 安全，先检查远程未被他人更新）
• 可恢复性：误操作后可 git reflog 找回操作前的 SHA-1，再 git reset --hard <sha> 恢复

4.11 git pull 原理与冲突详解

4.11.1 pull 的内部原理

git pull 是一个组合命令，它从来不是单一操作，而是 fetch + merge 两个步骤的快捷方式（加 --rebase 则等价于 fetch + rebase）：

git pull origin main            # 等价于：git fetch origin && git merge origin/main
git pull --rebase origin main   # 等价于：git fetch origin && git rebase origin/main

4.11.2 为何会冲突：三方合并

Git 合并时不是简单的"逐行覆盖"，而是采用三方合并（three-way merge），需要三个输入：

merge base（共同祖先） + 我方提交（HEAD） + 对方提交（origin/main）
# 对比三方后，Git 自动合并双方互不影响的改动；
# 只有三方中"我方和对方都改了同一处"，才产生冲突

4.11.3 冲突如何解决

冲突后 Git 暂停合并，在冲突文件中写入标记：

<<<<<<< HEAD          ← 上方是我方版本
你写的代码
=======                  ← 分隔线
别人写的代码             ← 下方是对方版本
>>>>>>>> origin/main

解决流程：

git status                  # 查看哪些文件冲突（Unmerged paths）
# 手动编辑冲突文件：保留正确内容，删除 <<<<<<< ======= >>>>>>>> 标记行
git add <file>              # 标记为已解决
git merge --continue        # merge 时：完成合并提交
git rebase --continue       # rebase 时：继续重放下一个提交
# 想放弃本次合并，回到操作前状态：
git merge --abort           # 或 git rebase --abort

4.12 git worktree 原理详解

git worktree 让同一个仓库同时把多个分支检出到不同目录。一个仓库有 1 个主工作树（main worktree，即 git init/git clone 生成的那个），外加 0 到多个链接工作树（linked worktree）。所有工作树共享同一份对象库和 refs，但各有独立的 HEAD 和 index。

4.12.1 为什么需要 worktree

经典场景：你正在 feature 分支做一半重构，工作区一堆半成品，此时线上出现紧急 bug 需要立刻在 main 上修复。传统做法是 git stash 暂存改动再切分支，但工作区可能乱到不敢动；而 worktree 的解法是——另开一个目录检出 main，改完直接删掉目录，原来的工作区原封不动。

相比 git clone 多份仓库，worktree 的优势是：零拷贝对象库、共享分支命名空间，磁盘占用和"仓库间同步"成本都更低。

一个容易误解的点：worktree 复制的是「工作区文件」，不是「仓库本体」。每个工作树目录里都是一份完整的源码检出，所以磁盘上源码确实有 N 份；但 .git/objects 与 refs 只有一份，被所有工作树共享。这正是它和"切换分支"、clone 的本质区别：相比切换分支（工作区始终 1 份）它更贵——工作区从 1 份变 N 份；相比 clone（对象库也翻倍）它更省——对象库不复制。

4.12.2 存储原理（核心）

链接工作树的顶层是一个普通目录，但其中的 .git 是一个文件而非目录，内容只有一行：

gitdir: /path/main/.git/worktrees/<id>

主仓库的 .git/worktrees/<id>/ 目录则保存该工作树的私有管理文件。进入链接工作树后：

• $GIT_DIR 指向私有的 .git/worktrees/<id>/（放 HEAD、index、gitdir、可选 locked、config.worktree）
• $GIT_COMMON_DIR 指回主仓库的 .git（放共享的 objects/、refs/、config）

图 9：git worktree 存储结构与元数据关联

关键推论：因为 refs/heads 共享、分支是"某条 ref 指向的 commit"这一全局状态，所以同一个分支不能被两个工作树同时检出（否则两处的提交会互相打乱该分支的指向）。Git 默认拒绝，除非显式 --force。

图 10：git worktree 与 git clone 多副本对比

4.12.3 常用命令

# 紧急修 bug：不动当前工作区，另开目录在 main 上修
git worktree add -b emergency-fix ../repo-hotfix main
cd ../repo-hotfix
# ... 修改并提交 ...
git commit -am "emergency fix"
cd -
git worktree remove ../repo-hotfix        # 修完即删

# 查看所有工作树
git worktree list
# /repo             abcd1234 [main]
# /repo-hotfix      5678abc  [hotfix]
# /tmp/repo-test    1234abc  (detached HEAD)

# 并行开发：当前在 main，另开目录做 feature，两处同时推进
git worktree add -b feature/login ../repo-feature main   # 基于 main 新建分支并检出
cd ../repo-feature
# ...在 feature/login 上开发并提交...
git add -A && git commit -m "feat: login"
cd -                                                     # 回到主工作树（仍在 main）

# 方式一：本地合并（不需要 push，合并是独立的一步，push 从不自动合并）
git merge feature/login                                  # 在 main 工作树里把 feature 合进来
git push origin main                                     # 视需要再把合并结果推到远端

# 方式二：走远端 PR/MR（团队协作，多一道评审）
git push -u origin feature/login                         # 只上传 feature 分支，main 不受影响
# 在平台上开 PR 合并；合并后再本地更新：
# git fetch && git merge origin/main

# 收尾：删除工作树，再删已合并分支
git worktree remove ../repo-feature
git branch -d feature/login                              # 已合并才可 -d，否则用 -D

4.12.4 与 clone / stash 的对比

4.12.5 注意事项

• 分支唯一检出：同一分支不能在两个工作树同时检出，否则需 --force（危险）
• 主工作树不可删除：git worktree remove 不能作用于主工作树
• 手动删目录要 prune：直接 rm -rf 工作树目录后，用 git worktree prune 清掉残留元数据（gc.worktreePruneExpire 也会自动过期）
• 搬运后要 repair：手动移动工作树或主仓库位置后，用 git worktree repair 重建 gitdir 链接
• 可移动设备用 lock：工作树放在未常挂载的移动盘/网络盘时，git worktree lock 防止被误清理
• 子模块支持不完整：多个 checkout 总体仍是实验性特性，不推荐对超级项目做多重检出