在知乎上，《pro git》作为入门“殿堂级”教程推荐。很早就想在项目上推行git作为配置管理工具，囿于原公司的各种信息安全傻规定，无法实现。现在有了条件，就好好学习一下，把git用好。
我发现一个适用于自己的方法–强迫自己写读书笔记对理解业务或者技术都大有裨益，同时在博客中加入一些对软件开发的理解也会对其他人有一点点帮助。所以有了这篇。
刚入行的时候（1999年），没人关注配置管理。在一家自封为中国第四大软件公司做开发。项目组有10来个人，大家就用微软的VSS做文档和代码的管理。经常遇到你覆盖我，我干掉你的囧局。虽然当时很气愤，也很想弄好，能力不济，也没什么人指导。但觉得对团队协同开发来说，配置管理作为一项基础性的工作非常有必要做好的。
再后来到了菊花公司，软件开发非常的规范。使用SVN，只要掌握了“修改之前一定要update”的口诀，断然不能出错了。对于代码量在10万以内的项目来说，SVN表现的不错。我们团队在菊花公司变态QA审查之后还得了个质量奖。
后来就开始做大项目，说好听的是企业级百万以上后台代码的工程，说不好听的是经年累月的史诗级史前巨坑的遗留系统。如果一个新人进项目组，不折腾三天，开发工程都搭建不起来，更遑论持续集成和自动化测试了。当时领导听说总部不少团队用clearcase，鸡冻的很，我一看，cao啊，更是“豪门深似海”的架势，就以工程替换量太大，开发人员不熟悉耽误开发效率为由拒绝了。
在菊花公司研发体系，效率是法宝，说服领导采用“效率”一词的次数与成功率成正比，不管你是想拒绝还是想引导。
后来跟业界的接触多了，知道了git。心向往之，当时也找兄弟学习了，强制在项目组内使用，效果却很差。在进度面前，这些都成了装逼。有个兄弟开玩笑的说，用git提交了代码今天居然保存住了！让我印象深刻。知道近期，看了《pro git》这本书，有点“相见恨晚”，反过头来看之前的问题，其实还是没有正确的学习和使用git吧。
git的产生过程是一段传奇，我就不再貂尾续狗。
学习和使用git，首先要thinking in git，不要拿传统的集中配置管理工具的概念来套git。他们的主要差异点：
快照 VS 比较差异
git只关心文件数据的整体是否有变化，传统工具只关心具体文件是否有变化。git更像是把变化的文件做一次快照后，记录在一个微型的文件系统中。每次有代码提交，git会纵览一遍所有文件的指纹信息并对文件做一次快照，然后保存一个指向本次快照的索引。
几乎所有操作都可本地执行
由于是分布式的配置管理，只要是开始用git，本地磁盘保存着所有有关当前项目的历史更新。所以操作起来非常快。可以在任何时间和地点进行git操作，而不用连接网络。
时刻保持数据的完整性
在保存到git之前，所有数据都要进行内容的校验和chechsum计算，并将此结果作为数据的唯一标识和索引。使用SHA-1算法进行校验和checksum计算，会产生一个SHA-1的哈希值，作为指纹字符串。类似：24b9da6552252987aa493b52f8696cd6d3b00373 这个样子的。
多数操作只添加数据
添加数据是可逆的，删除数据是不可逆的。如果经常提交快照，就不会产生数据丢失的问题。可靠性非常好。
接下来我们看看，git的三种状态，核心概念务必理解。
对于任何一个文件，git内只有三种状态：
有了这三种状态也就有了三类目录：
每个项目都有一个git目录，用来保存元数据和对象数据库的地方。每次克隆镜像仓库的时候，实际拷贝的就是这个目录里面的数据。从项目中取出的某个版本所有文件和目录，用以开始后续工作的叫做工作目录。这些文件实际上都是从git目录中的压缩对象数据中提取出来的，接下来就可以在工作目录中对这些文件进行编辑。
而暂存区只不过是一个简单的文件，一般存放在git目录中。有时候人们会把这个文件叫做索引文件。
基本的git工作流程是：
1 在工作目录中修改某些文件。 2 对这些修改的文件做快照，并保存到暂存区。 3 提交更新，将保存在暂存区域的文件快照转储到git目录中。
好了，掌握了这些基础知识，将非常有助于实际操作。不会乱了方寸。
=== 未完待续 ===