源代码控制，或者有时候被称为版本控制，是用于跟踪不同版本的文件和软件项目的源代码，以及协调多个开发人员可能同时操作同一个文件集的工作的方式。
源代码控制还能帮助你协调多个同时工作在代码库里同一个文件集上的开发者的工作。
如果没有源代码控制帮忙管理开发者所做的不同的修改的话，就会很容易导致开发者们互相覆盖其他人的变更，或者被迫只能等待其他人对同一个文件的编辑完成之后，他才能继续编辑。
一个好的源代码控制系统可以允许你们同时在同一个文件上进行工作，然后可以将变更合并到一起。
源代码控制同时也解决了在同一个软件应用的源代码库的多个版本上同时工作的问题。
假设你有一个应用已经发布给了客户而它有一些bug需要解决，但同时你又开始开发一些新的功能为下一个版本做准备，而这些新功能还没有准备好。
CVS和Subversion是集中式源代码控制的两个例子。
Git和Mercurial是分布式源代码控制的两个例子。
分布式的是比较新的。在大部分人眼里它可能更能吸引人眼球，而且更加复杂些，但是更多的人在使用它。
如果你是在未来的某个时间阅读本书，这个列表可能会变化。
总有新的源代码控制的新星出现而炙手可热。
但是，目前来说，即在写本书的时代，我认为我会给你简要介绍一下你可能在野外看到的最常用的源代码控制系统。
注意：只是简短的介绍。
CVS
不，它并不是一个药店。它是源代码控制。
它以CVS或者并发版本系统为名而为人所知。 （我从来没有叫过它的全名；实际上我是查字典才查出来的。）
它是什么?
嗯，我知道当我说这些时有些人会生气，但是以我的观点来看，它是Subversion的前辈。
CVS是一个集中式的源代码控制系统，而且它相当的健壮。
它非常的强大，但是有一点慢。
大部分曾经使用CVS的组织最终都会转换使用Subversion，但是CVS仍然在处理一些东西时有一点异样，而有些人还是更喜欢这些异样的东西。
比如，打标签和分支以及回滚提交在CVS里都很不一样。
CVS狂热者会告诉你CVS做的正确，而Subversion做错了。
我并不真的关心这些，因此我只是点头，因为我不喜欢被人用叉子刺。
Subversion
偏见预警（以下只是偏见，仅供参考）
Subversion可能是我最熟悉的源代码控制系统。
我曾经以纯粹图形化的方式关于如何使用它给人讲过课程，我也写过关于如何使用它进行分支管理和合并策略的博客文章， 并且我曾使用这项技术为相当大的开发团队管理过SVN服务器，存储库和源代码控制系统策略。
那这意味着我是一个超级SVN迷而认为其他任何东西都很烂呢？
不，并不是这样。
就集中式源代码控制系统来说，我认为Subversion是最好的，但是它肯定也有一些缺点的。
然而，总体来说，它能使工作完成，并且非常简单易用，因此我喜欢它。
Git
Git基本上已经变成源代码控制的同义词了。
今天你去问一个不满25的开发人员什么是源代码控制，他或她 很有可能说，“什么，你是说Git吗？”
他/她会这么说是有理由的。
Git是… 嗯… 相当的棒。
真的，它就是这么棒。
就源代码控制软件来说，Git能够完成你能想到的几乎任何事情.
它极其的强大。
它的基础相当简单。
而且它快速，高效且通用。
Git甚至还有一个相当大的公司来支持开源并为Git项目提供托管服务，它叫GitHub。
如果你还不知道，绝对值得你去了解一下。
Mercurial
Mercurial有点像是Git的邪恶孪生兄弟。
有人说Git像麦吉弗，而Mercurial像詹姆斯•邦德。
我并不确切清楚他们到底说的是什么—或者他们在抽什么烟—但是我大概明白了。
Mercurial被描述得比Git更优雅和文雅。
相同的基础思想—他们都是分布式的源代码控制。
相同的基本功能和特性。
但是，以我的经验来看，Mercurial只是相对来说有一点更容易使用和理解而已，而Git则有一点晦涩难懂，但是有很多方式可以将东西结合起来。
源代码管理以及源代码管理系统有很多不同的版本和实现，但是它们都有一个共同的目标，就是帮助你最好的管理你的软件开发项目的源代码。