从人们开始用电脑开始就面临着文件版本控制的问题，从最原始的同一个文档多个不同命名表示版本到使用本地的文件版本管理，到后面集中式版本管理如2000年的SVN，到再后来的分布式的版本控制系统，如2005年的Git。到现在用的最多的版本控制库依旧是SVN和Git，Git多用于个人、代码库的管理。
与SVN的使用简单相比，Gti是入门复杂，不过网上有大量视频、文档教程，作为技术人员学习并使用理解Git会是一件很值的事。
虽然Git在分布式、分支管理等方便领先SVN，但并不代表它能代替SVN，两者的理念设计原则不同，Git更适合文本文件如代码库的管理，尤其是并行远程异地开发、分支较多的情况，而SVN则适用于集中式文件版本管理、权限控制严格等场景，我们要根据需求选对的工具。
Git的每次提交都会生成一个完整的文件快照，对应一个文件目录tree。Git工程有工作区、暂存区、本地仓库3个工作区域，引入暂存区是个不错的设计，它能够实现部分提交，记录文件的修改时间等信息，提高文件的比对效率。
与SVN分支策略相比，Git分支流程复杂了很多，除了要维护两个长期的分支master和develop外，还有很多临时性分支如hotfix等，甚至有些用SVN分支思维的同学还有疑问，这种模式分支合并后岂不是增加了很多重复测试的工作量，因为理论上分支测试后，任何代码的改动合并到其它分支都是要重新回归测试才可以的。对此要用Git分支思维才能更好理解，Git用这样的分支策略就是为了应对实际中常出现的多人多版本并行开发的情况更方便有效率，如果实际开发过程中真像SVN开发分支线性向前迭代，则分支合并只是简单的移动分支指针并不用重新测试（因为它们是同一套代码）。
rebase 会把从 Merge Base 以来的所有提交，以补丁的形式一个一个重新达到目标分支上。这使得目标分支合并该分支的时候会直接 Fast Forward，即不会产生任何冲突。提交历史是一条线，这对强迫症患者可谓是一大福音。stash 将工作区与暂存区中的内容做一个提交，保存起来，然后使用reset hard选项恢复工作区与暂存区内容。我们可以随时使用 stash apply 将修改应用回来。stash 实现思路将我们的修改提交到本地仓库，使用特殊的分支指针（.git/refs/stash）引用该提交，然后在恢复的时候，将该提交恢复即可。
