什么是VC:即版本控
版本控制系统是一种软件，它可以帮助您跟踪代码随时间的变化。在编辑代码时，您告诉版本控制系统对文件进行快照。版本控制系统将永久保存该快照，以便在以后需要时可以收回它。如果没有版本控制，您可能想在计算机上保留多个代码副本。这是很危险的——很容易在错误的代码副本中更改或删除文件，可能会丢失工作。版本控制系统通过管理代码的所有版本来解决这个问题，但是每次只显示一个版本。
VC的作用:
最基本最重要的原因当然是版本回复reversion。
随着开发，代码不断地在演化。如果你在写代码的时候发现一秒钟前错误的删除了一行代码，你会很快的用ctrl+z来撤销修改，从而回复你错删的代码。但是如果你经过一个小时的努力，改了很多的代码文件，你发现这个修改是不可行的，需要倒退回去，你改怎么办？有人有比较好的习惯，当认为目前有里程碑意义的时候就把代码全备份，如果后面发现想倒退回来的时候就删除修改后的，重新启用之前备份的。这样可以解决一些问题，但是这是手工的，很麻烦。只要是麻烦的事情都会容易让你懒于去做。如果有可以工具，让你很方便的退回到以前的某个时候的代码状态，是不是很好？这就是版本控制系统要解决的问题。
还有一个重要的原因就是变更跟踪。如果你手工备份，是不是也得写一个readme文件，说明为什么要修改。如果是多人协同开发，你还想知道是谁修改的。如果有一个工具可以帮你自动维护这些信息，让你很容易达到目的，何乐而不为呢？
另外一个重要的原因就是bug跟踪。如果你在一个稳定的版本上做了修改，发布以后发现有bug了。你首先想到的肯定是你修改导致的，如果你能快速的找到你的修改点，是不是很容易定位错误。还有另一种情况，在发现bug的时候你的代码又前进了很多，你要想重现bug是不是要利用之前的哪一个版本来测试？
综合这些问题，我们需要一个版本控制系统来：
1. 维护代码的演化历史
2. 记录历史变化的原因和说明
3. 如果是多人开发，就会发生多人修改同一个文件的可能，还得保证彼此不会覆盖他人的代码，甚至能智能地合同。
常用的VC:
就分布式版本控制系统 - Git 而言.
1. repository
因为没有一个集中式的repository，那么每一个人都有自己的一个repository。
2. branch
和一般的分支没有什么区别，每个分支都是一个开发演化路径，也就是由一系列的commit构成的。每个commit都对应这个项目的一个snapshot。可以通过“git branch”来查看当前的分支。
3. head
既然分支是由一系列的commit构成的，那么最近的一个commit对应的那个snapshot就是这个分支的head。
4. master
master就是主干分支。
5. clone
既然每个人都有一个，当你想在一个已有的repository上继续工作的话，你就可以clone一个。刚刚clone的repository就源repository的master的head。
6. remote-tracking branches
虽然clone的时候只是copy了master的head，但是也有对源repository上其他的分支的track。那就是remote-tracking branches。你可以通过“git branch -r”来查看。