1.1.1 版本控制的重要性

不同于硬件开发或建筑工程，一旦施工，如果设计失误往往意味着高昂的返工甚至推倒重来，对前期设计的要求近乎苛刻。软件项目允许一定的失误，而版本控制在软件项目开发中具有不可替代的核心地位：

• 支持多人高效协作：如linux内核开发，全球超千名开发者通过Git协作管理超3000万行代码
• 保障项目安全与稳定性：生产环境问题可快速回滚至上一稳定版本

版本控制，可认为是软件开发的时空操纵术：

• 空间维度：允许多双手在代码宇宙并行建造（Linux级协作）
• 时间维度：赋予版本自由穿梭的能力（秒级回滚）
• 进化本质：支持多人共造一辆行进中的原型车——在行驶中持续改造升级引擎，从自行车蜕变为法拉利

1.1.2 版本控制工具演进史

​原始阶段​：手动对目录管理，复制整个项目目录来保存不同的版本，简单但容易出错，想象一下有成千上万个不同版本的目录，查找、比较、团队协作几乎不可能，文件混淆版本风险极高。

​本地版本控制系统​(LVCS:= Local Version Control System)：在单台计算机上管理文件的版本历史，通常采用“反向差异”存储（只存储版本间的差异），节省空间。仅支持本地操作，无法满足多人协作需求。典型代表是RCS, 于1982年由普渡大学的Walter F. Tichy首次发布，目前由GNU维护，最新发布是2022年。

​集中化的版本控制系统​(CVCS:= Centralized VCS)：通过引入一个单一的中央服务器存储项目的完整历史，允许多个开发者通过客户端连接到服务器取出最新的版本及提交更新，解决了多人协作的基本问题。但有几个显著缺点：

• 单点故障：中央服务器宕机时，所有开发者无法提交更改，甚至可能无法查看历史。
• 依赖网络：大部分操作需要网络连接。
• 客户端限制： 开发者本地通常只保存文件的最新快照，完整历史需依赖服务器。

典型代表是SVN/Subversion，于2004年首次发布，目前由APACHE维护。

​分布式版本控制系统​(DVCS:= Distributed VCS)：通过分布式设计(每个开发者的本地仓库都是项目的完整镜像，包含所有文件的历史记录、分支和标签)进行了革命性变革：

• 去中心化/高可用：无单点故障。即使中央服务器（常仍用于协调）宕机，本地工作与历史查询不受影响，提交可暂存本地。
• 离线工作： 绝大多数操作（提交、分支、查看历史、差异比较）可在本地完成。
• 高效灵活： 分支创建、合并操作通常非常快速和轻量。
• 数据完整性： 使用内容寻址（如Git的SHA-1哈希）确保历史不可篡改。

典型代表有:

• BitKeeper：第一个被广泛使用的DVCS，linux内核的开发曾在2002-2005使用bitkeeper管理版本，由于不是开源的，2005撤销了对开源社区的授权。Linus一怒之下带领一帮人开发设计了Git，从此git席卷世界。讽刺的是，BitKeeper在2016年选择了以Apache协议开源。有兴趣的可以看:git的前世，和BitKeeper
• Git：由Linus Torvalds为Linux内核开发而创建（C语言实现）。凭借其强大功能、灵活性和Linux社区的巨大影响力，迅速成为最主流的DVCS。
• Mercurial： 与Git同期诞生（Python语言实现）。设计哲学更强调简洁性和命令一致性，曾广受许多开发者喜爱并被不少公司采用，但市场份额逐渐被Git超越。

1.2.1 手动补丁管理

1991年-2002年间，Linux内核的版本维护主要依赖基于邮件列表的手动补丁管理，通过​diff​对比新旧代码生成补丁文件，审核通过后，通过​diff​进行补丁应用到本地源码，定期打包完整的内核源码。​diff/patch+邮件列表​的模式在早期支撑了Linux内核的雏形，但本质是“无版本控制”的临时方案。其低效与局限直接推动了BitKeeper的引入，进而为Git的诞生埋下伏笔。

1.2.2 BitKeeper: 商业化的DVCS

随着内核复杂度飙升，传统方式难以传统方式难以为继，分布式版本控制系统BitKeeper支持分布式开发，允许维护者独立管理子模块分支，显著提升合并效率；自动记录完整提交历史（如作者、时间），解决了补丁邮件的碎片化问题。2002年-2005年间，尽管社区对闭源的BitKeeper有争议，Torvalds坚持采用当时唯一满足高性能分布式协作的工具BitKeeper来管理和维护代码。

1.2.3 Git：开源的DVCS

2005年，开发BitKeeper的商业公司同Linux内核开源社区的合作关系结束，收回了Linux内核社区免费使用BitKeeper的权力。2005年 Linux 开源社区（特别是Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统Git，从此Git开始席卷世界。

1.2.4 GitHub

最大程序员社区

GitHub是成千上万的开发者和项目能够合作进行的中心网站，本质是一个在线SaaS服务，提供 Git 仓库托管及扩展协作功能（通过Pull Requests完成代码审查与合并流程标准化，通过Issues完成任务跟踪与问题管理，通过Actions进行自动化CI/CD流水线），目前属于微软。尽管GitHub不是Git开源项目的直接部分，但如果想要专业地使用Git，将不可避免地与 GitHub打交道，同时GitHub也是一个宝藏，近十年火热的大数据、深度学习、大语言模型都离不开GitHub。

1.3.1 分布式优先

• 去中心化存储：每个开发者仓库都是完整的副本（含全部历史和分支），彻底消除单点故障风险。
• 网络非必需：提交、分支、合并等核心操作均在本地完成，仅在同步时需网络（颠覆 CVCS 的集中式模型）。

1.3.2 基于快照的数据模型

内容寻址 (Content-Addressable)

• 所有对象（文件/目录/提交）通过 SHA-1 哈希唯一标识（如 a5d8f324...），任何数据损坏均可被检测，相同文件内容仅存储一次（高效处理重复资源）。

• 每次提交捕获整个项目的全量瞬时状态快照（而非增量差异），避免依赖历史链。git更像是一个文件系统，git逻辑上是基于不同时刻的全量快照来做版本管理。

  • 轻量级分支：创建一个新分支仅需要生成一个 41 字节的引用文件（如refs/heads/branch_name），这41个字节是一次提交的hash标识，本质上是一次整个项目的某个版本的全量快照，创建分支极快，鼓励开发人员频繁地创建和使用分支。
  • 分支切换、历史回溯高效极快，不需要在根据历史链回溯计算全量状态。

Note

1.3.3 时间切片机：三区机制与DAG

通过工作区、暂存区、版本库的设计，允许开发者精细化控制提交内容，将提交合并，分支形成DAG拓扑图，支持复杂开发流可视化。

1.4.1 安装

Linux系统：

sudo apt install git # debian
sudo yum install git # centos

MacOS: 安装Homebrew后，

brew install git 

Windows: 从官网下载Window版本的安装程序，双击安装即可。

如果能显示版本号，说明证安装成功。

git --version

1.4.2 配置加载机制

Git的配置项加载机制遵循 "层级配置、单值覆盖、多值合并"的原则。

Git会按​系统级、用户级、仓库级、命令行​的顺序读取配置文件：

• 系统级配置(system): /etc/gitconfig，影响所有用户和项目的全局默认
• 用户级配置(global): ~/.config/git/config，当前用户的个性化配置
• 仓库级配置(local): <repo>/.git/config，仅作用于特定仓库的配置
• 命令行配置(​-c <key>=<value>​)，单次命令的最高优先级配置

对于单值配置项，同一键名只能存在一个有效值，后加载的配置会覆盖先前值。按上述的层级配置顺序读取，​后​读取的配置会覆盖先前同名的配置项。

某些配置项支持多个值共存（通常是列表型配置，如​push.pushOption​），此时所有层级的同名配置会被合并。

总之，单值配置后读取值覆盖先读取的值，多值配置合并。

1.4.3 常见配置

# 提交用户名及邮箱
git config --global user.name "Your Name"
git config --global user.email your_name@example.com

# 默认分支名: main
git config --global init.defaultBranch main

# 自动为本地分支设置一个上游跟踪分支（upstream tracking branch），并在第一次推送时在远程仓库创建该分支
# 它自动化了 git push -u origin <branch-name> 这个命令
# 强烈推荐开发者全局启用此配置
# 在这个分支上你只需要输入 git push 和 git pull 即可，无需再指定远程和分支名 更流畅
git config --global push.autoSetupRemote true

# 编辑器: 二选一或配置其他编辑器
git config --global core.editor "emacs -nw -q"
# git config --global core.editor "vi"

# pull.rebase: 三选一
git config --global pull.rebase false
# git config --global pull.rebase true
# git config --global pull.ff only

# 查看配置
git config list --show-origin --show-scope

Note

1.4.4 获取帮助

# 常用子命令
git
git help -a

# 全面的手册
git <verb> --help

# 快速参考
git <verb> -h

2.2.1 文件状态

本地开发中，编辑、暂存、提交会导致文件的状态发生变化，可通过​git status -s​命令输出的两个字符​XY​快速判断文件的状态。

Note

具体XY的明细含义：

• 如果处于合并成功或非合并状态

  • X表示暂存区的状态，具体指暂存区相对于上个commit(HEAD)的变化，即HEAD ->暂存区， (git diff HEAD --staged <file>)
  • Y表示工作区的状态，具体指工作区相对于暂存区(INDEX)的变化, 即暂存区->工作区(git diff <file>)

• 如果是处于合并且冲突未解决状态，三方合并中，

  • X表示我们相对于共同祖先base版本的修改
  • Y表示他们相对于base版本的修改

2.2.2 参考命令

# 查看文件的XY状态，包含已忽略文件
git status -s --ignored

# 查看暂存区的所有文件: mode/hash/stage_number/file
git ls-files --stage

# 查看具体的变化
git diff [<commit=HEAD>] --cached/staged  # <commit=HEAD> -> 暂存区
git diff      # 暂存区 -> 工作区
git diff HEAD # HEAD -> 工作区
git diff commit1 commit2

# GUI工具
git difftool

# 查看历史
git log --oneline --decorate --graph --all --format="%h %an %cn %s"
git log --oneline --stat --graph --patch --format="%h %an %cn %s" [<file>]
git log -p/--patch

2.3.1 三方合并

要理解三方合并，首先要明白两方合并（Two-way Merge）的不足。

• 两方合并：只比较两个文件的最终状态（例如，分支 A 的 file.txt 和分支B 的 file.txt）。如果同一行在两个版本中都发生了变化，合并工具将无法智能地判断应该采用哪个更改，从而导致冲突，必须人工解决。
• 三方合并：它不只比较两个最终版本，而是会引入第三个版本——两个分支的最新共同祖先（Common Ancestor）。这个共同祖像是“分歧开始的地方”，它为判断“谁修改了什么”提供了至关重要的上下文，故能够​完成自动合并​(当然不是100%的成功率)。

2.3.2 远程仓库

远程仓库指托管在因特网中的版本库，各个开发者通过远程仓库进行团队协作，比如团队某成员从同一个远程仓库clone到本地，将自己开发的代码push到远程仓库；另外一成员拉取远程仓库的最新代码，在其他成员的代码基础上开发新功能。

Git 作为分布式版本控制系统，其核心优势之一在于单个本地仓库可以灵活地关联多个远程仓库。这与只能连接单一中央服务器的集中式版本工具形成鲜明对比。

这种多远程仓库的配置策略在实际开发中非常实用，例如：

• 将同一个项目同时托管于 GitHub 和 Gitee（码云），即可根据网络状况选择最优平台进行访问和推送；
• 或者在 GitHub 上维护多个不同贡献者的 Fork 版本，便于直接获取特定成员的提交，方便协作与代码整合。

正所谓“狡兔三窟”，这种多远程配置既提升了容灾性和访问灵活性，也支持了更开放的协作模式。

当你首次使用​git clone​命令克隆一个仓库时，Git 会自动将源仓库地址记录在名为 origin 的默认远程仓库配置中，作为初始的远程参考。

gitk中，远程分支以 remotes/<remote_name>/<branch_name> 形式命名。

2.3.3 标签和分支管理

git中每个commit都用一串hash值标识(类似68301504e236508059bfb43d65b5b69f93d839ca)，不适合人类读取。

分支和标签，让提交(Commit)有一定的意义，容易让人记住。两者本质上都是一个指向某个提交（Commit）的引用，但分支代表一条​活跃的、持续演进的开发线​，是一个可移动的指针，用来开发、协作；标签用来标记​关键里程碑​，是一个固定的指针，用来发布、标记。

分支、标签，都有本地和远程的概念，本地创建后，如果需要共享给团队，需要推送到远程。对应的删除，也有远程、本地删除。

标签、分支、HEAD的创建，底层实现是创建一个40字节的文件，故能瞬时完成：

• 新建标签:

  • 创建本地标签: .git/refs/tags/<tag_name>，内容为40字节的sha1值
  • 推送到远程

• 新建分支:

  • 本地创建分支 .git/refs/heads/<branch_name>，内容为40字节的sha1值
  • 推送到远程
• HEAD内容： .git/HEAD, 内容为 ref:refs/heads/<current_branch_name>