本文尝试介绍一下Git的过人之处。
目标读者是想了解Git,
或者对软件设计有兴趣的人。

Git作为一个极其灵活的工具,
从修改单机游戏数据文件的版本管理,
到多人协作一起堆屎的协作开发,
使用起来都是十分趁手。

那么Git灵活的奥秘在哪呢?
大概是因为Git设计正交、实现扎实吧。

总览

Git里面的术语/命令很多,
但是它们可以归并成几个大类,
每个大类的概念都是正交的,
也就是说交叉概念很少,
不会有模糊的概念定义。
基于这样的设计,
Git与之对应地实现了一套扎实的命令系统。

Git里的概念有些难以准确翻译,
本文涉及概念词的地方尽量用术语表达 。

比如经常用到的概念会有这些:

  • Line Diff
  • Commit
  • Branch
  • Repository
  • Remote


Line Diff

Git实现版本控制的方法是根据Line Diff,
推算出每个Commit具体改了哪些东西,
然后用多个Commit(实则是多份Line Diff)构建出所有历史。

这个基于Line Diff的先天设计决定了Git的一些特性:

  1. 可以存储所有历史。
    我们常听到“Git是一个分布式的版本控制系统”,
    这个指的就是Git不需要中心化的服务器,
    你就可以做完所有操作。
    因为本地存着所有的Line Diff,
    所以“查看昨天被改过的文件名列表”这个操作完全可以离线完成。

  2. 对二进制文件不友善。
    二进制文件是没法强行比Line Diff的。
    所以假如用Git管理二进制文件,
    Git只会显示一个Binary File Differ
    再把上面一条“存储所有历史”给叠加上,
    就会出现今天提交了一个200M的文件,
    明天后天我都修改覆盖了这个文件,
    最后整个目录就有600M大了…
    (也就是说一般不用Git来管理二进制大文件)

  3. 能检测文件重命名。
    假如在一个Commit中,
    从Line Diff的视角看,
    删除的文件和增加的文件相似度很高,
    Git就会判定这是一个重命名的操作。

Commit

Line Diff组成了Commit,
Commit是大部分Git操作的最小单位。
这个词既是动词,也是名词。

一个Commit包含了多种信息:

  • SHA hash:是根据line diff + 精确到秒的时间戳生成的一串唯一标识符
  • Author:写Line Diff的人
  • Committer:一个隐藏的属性,代表Commit的人
  • Date:包括AuthorDate和CommitDate
  • Message:Commit文本描述,Git会取Message第一行作为Subject,所以一般会遵循一定规范
  • Line Diffs:改动了哪些内容

这里还可以说的概念包括RootCommit、MergeCommit,
不过它们特殊之处不影响实际使用,
所以跳过它们,继续往下说。

Branch

多个Commit会组成一个Branch,
最初的Branch默认叫master(主干分支)。

Branch和Commit在很多命令里都是可以作为等价的操作对象的。
举个例子:

小成写了一天代码,
他在wechat这个分支上commit了很多次,
快下班了,小成想回顾一下今天的改动。
假设他的log长这样子:

> git log --oneline --graph
* f01c8d1 (HEAD -> wechat) refactor: improve project layout
* 2f9c867 feat: add rest api to create card
* 5d5242b feat: custom wechat card background
* 873e6ca fix: wechat card slow query
* 0dd06a9 fix: 500 when user unsubscribe
* fb91f98 (origin/master, master) feat: implement wechat card
* 176b4f0 feat: implement membership level
* 2727226 migration: add Settings.enable_level
...

那么以下命令是完全等价的:

# 查看从master到wechat的diff
> git diff master..wechat

# 查看从master到当前的diff(HEAD代表当前位置,也就是wechat分支)
> git diff master..HEAD

# 查看从master到当前的diff(HEAD是默认值,可省略)
> git diff master

# 查看master的commit到当前的diff
> git diff fb91f98

# 查看五个Commit以前倒当前的diff(master分支在五个Commit以前)
> git diff HEAD~5

所以也可以说“Branch是特殊的Commit”。
理解了这一点以后,
再去看大部分的Git命令,
发现它们都是git <operation> <range> -- <files>...这样的形式。

比如查看今天发布哪些内容就是git diff master..release
把某个文件回滚到200个Commit以前就是git checkout HEAD~200 -- some/path/some/file.txt
查看单个文件的改动历史就是git log -- some/path/some/file.txt

Repository

Repository包含了所有的操作历史。
git init命令可以初始化一个Repository。

一个Git Repository结构可能是这样的:

- .git/
  - hooks/
  - objects/
  - refs/
  - HEAD
  - config
- ForgiveDB/
- README.md
- requirements.txt

这里的.git目录就存储着上面讲的Line Diff、Commit、Branch的所有历史,
就像上面二进制大文件的那个例子,
这里可能存了几百M的文件历史。

Remote

Remote就是放在别的地方的Repository。
同一个Repository可以添加多个Remote。

除了push/pull/fetch这些基本操作以外,
关于Remote还有一个很骚的设定:
Git支持本地Remote。

比如样例的命令如下:

# 假设在服务器上的 /home/lirian/chinese-calendar 路径下有一个 Repository
> cd /home/lirian

# 把它 clone 到某一个地方
> git clone chinese-calendar /opt/git/repo/chinese-calendar --bare

# 同个服务器上的另一个用户就可以 clone 这个 Repository
> cd /home/ldsink && git clone file:///opt/git/repo/chinese-calendar && git remote -v
origin       file:///opt/git/repo/chinese-calendar (fetch)
origin       file:///opt/git/repo/chinese-calendar (push)

这样的设计之下,
Remote/Repository是完全分离的,
不会因为断网就修改不了历史。
我们甚至可以把Remote当成一种特殊的Branch,
比如fork - pull request就是这种模式的一种应用。

尾言

文中讲到的不少例子有一些浅尝辄止,
读者有兴趣的话可以尝试思考实现一下这几个拓展问题:

  • 关于Line Diff:改动的两个文件相似度多高,Git才会识别为重命名呢?
  • 关于Commit:如何修改Commit的Author?GitHub上能看出来Committer么?
  • 关于Branch:如何删除远程分支?git stash产生的Commit可以像Branch一样操作么?
  • 关于Repository:删除分支以后,Git目录会变小吗?
  • 关于Remote:文中用到的--bare参数是什么意思?

Git的设计理念中还有很强大的一部分是它关于历史(History)的管理,
那又是一个值得细说的话题。

总的来说,笔者眼中Git是一个科学且强大的工具。
Git优秀的原因在于它:

  • 正交的设计:术语定义清晰,重叠概念少,表现张力强大。
  • 扎实的实现:二级术语丰富,命令参数完善,贴合实际应用场景。

(完)