总诀：“归妹趋无妄，无妄趋同人，同人趋大有。甲转丙，丙转庚，庚转癸。子丑之交，辰巳之交，午未之交。风雷是一变，山泽是一变，水火是一变。乾坤相激，震兑相激，离巽相激。三增而成五，五增而成九……”（共三千余字）
独孤九剑讲究料敌先机，无招胜有招。在程序世界里，需要根据不同的需求不断的迭代。系统不能像剑法一样随手变更，往往需要花费无数个人月「最近体会到可以把变化做成接口，留给用户，来应对一部分需求变更」。程序＝算法＋数据结构, 很少有像 TeX 那样，在算法和数据结构两方面都趋近完美，Donald 独自完成了 99.99%，甚至连 bug 数，都少到了惊人的地步。我认为程序设计最重要的是数据结构，深刻理解数据结构，设计最合适的数据结构，以不变应万变，才能抓住需求的本质，解决用户的痛点，做到在需求变化或者转型时，改变最小。
总决
以不变应万变
烂程序员关心的是代码。好程序员关心的是数据结构和它们之间的关系。
数据结构
Git 数据结构设计的非常精良，据说在之后十几年的开发中，feature 扩展了无数，基础数据结构却很少变动。体会一下 Linus 的一段话：
Git 的设计其实非常的简单，它的数据结构很稳定，并且有丰富的文档描述。事实上，我非常的赞同应该围绕我们的数据结构来设计代码，而不是依据其它的，我认为这也是 Git 之所以成功的原因之一[…], 依我的观点，好程序员和烂程序员之间的差别就在于他们认为是代码更重要还是数据结构更重要。
心里痒痒的，就让我们来一窥 Git 的奥秘吧。
Git的设计思想
- 直接记录快照，而非差异比较
Git 不存储文件差异，把数据看作是对小型文件系统的一组快照。每次你提交更新，或在 Git 中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。下图中如果与前一个版本相比文件有改变，则存储新文件(快照)到下一个版本中。如果没有改变，则只存储之前文件的索引，如图虚线框所示。
- 近乎所有操作都是本地执行
在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。你能愉快地提交，直到有网络连接时再上传。
- Git 保证完整性
Git 中所有数据在存储前都计算校验和(使用 SHA-1 散列)，然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件，Git 就能发现。
- Git 一般只添加数据
你执行的 Git 操作，几乎只往 Git 数据库中增加数据。 很难让 Git 执行任何不可逆操作，或者让它以任何方式清除数据。
- Git 的三种状态
Git 有三种状态，你的文件可能处于其中之一：已提交（committed）、已修改（modified）和已暂存（staged）。 已提交表示数据已经安全的保存在本地数据库中。 已修改表示修改了文件，但还没保存到数据库中。 已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。
由此引入 Git 项目的三个工作区域的概念：Git 仓库、工作目录以及暂存区域。
基本的 Git 工作流程如下：
在工作目录中修改文件。
暂存文件，将文件的快照放入暂存区域。
提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。
Git 文件的生命周期
工作目录下的每一个文件都不外乎这两种状态：已跟踪或未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能处于未修改，已修改或已放入暂存区。 工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有放入暂存区。 初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态。
编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。 我们逐步将这些修改过的文件放入暂存区，然后提交所有暂存了的修改，如此反复。所以使用 Git 时文件的生命周期如下：
Git 保存数据的方式
为了说的更加形象，我们假设现在有一个工作目录，里面包含了三个将要被暂存和提交的文件。 暂存操作会为每一个文件计算校验和(使用 SHA-1 哈希算法)，然后会把当前版本的文件快照保存到 Git 仓库中（Git 使用 blob 对象来保存它们），最终将校验和加入到暂存区域等待提交：
$ git add README blob.go LICENSE
$ git commit -m 'The initial commit of dit'
当使用 git commit 进行提交操作时，Git 会先计算每一个子目录（本例中只有项目根目录）的校验和，然后在 Git 仓库中这些校验和保存为树对象。 随后，Git 便会创建一个提交对象，它除了包含上面提到的那些信息外，还包含指向这个树对象（项目根目录）的指针。如此一来，Git 就可以在需要的时候重现此次保存的快照。
现在，Git 仓库中有五个对象：三个 blob 对象（保存着文件快照）、一个树对象（记录着目录结构和 blob 对象索引）以及一个提交对象（包含着指向前述树对象的指针和所有提交信息）。
做些修改后再次提交，那么这次产生的提交对象会包含一个指向上次提交对象（父对象）的指针。