如果说什么是软件开发项目一定要使用的基础工具，那么版本控制系统应该算最重要的部分。不管是个人开发或是团队协作开发，都可以通过版本控制系统获得巨大的好处。
没有版本控制系统的话，代码可能被别人或自己不小心覆盖或遗失、也不知道是谁因为什么原因改了这段代码、也没办法可以复原回前几天的修改。有了版本控制系统，开发人员只要将每次程式码的变更都纪录（Commit）起来，并且透过版本控制系统中进行更新。
有了版本控制系统，我们可以浏览所有开发的历史纪录，掌握团队的开发进度，而且作任何修改都不再害怕，因为你可以轻易的复原回之前正常的版本。我们也可以透过分支和标签的功能来进行软件发行的不同版本，例如稳定版本、维护版本和开发中版本。
很多项目需求方还没有明白开发的定义，这里必须要跟大家说一点老生常谈的段子：“开发永远是个过程，而不是结果。”所以开发者一定要使用版本控制系统，Git或Mercurial是免费开源的版本系统系统、随处可用的网络、便宜的云端服务器，甚至有现成的第三方服务Github。
如果你还没有使用的话，建议马上为你的软件开发项目建立版本控制。接下来是几点使用版本控制系统的建议：
1.将所有东西都放进版本控制系统
是的，所有项目开发过程中的产出物都放到版本控制系统之中，这包括了程序源代码、测试程序、文件、设定档、各种自动化脚本等等。除了新成员可以很容易拉出最新的版本马上开始工作之外，我们也希望在测试环境、正式环境中，也可以随时更新到我们所指定的版本，因此将所有变更的纪录保存起来是非常重要的。
例如，数据库的变更也必须纳入版本控制。首先，在数据库中纪录它目前的版本编号。接着我们每次的修改都透过一个自动化脚本来执行，并将这个脚本放入版本控制之中，而不是手动用指令去修改纲要。这样的好处是团队中每个人都可以透过版本控制系统看到这个变更，并且升级他的数据库。测试和正式的服务器环境，也会透过这个脚本来自动进行升级。笔者熟悉的Ruby on Rails中就有内置这样的Migration机制，其他程序语言也有类似的数据库工具。
另外，以服务器应用来说，光是有源代码还是无法100%让软件工作起来，我们还需要知道服务器的配置设定，包括基础网络设定、操作系统设定、依赖的套件版本等等。因此最好这些配置设定也可以纳入版本管理系统之中。近年来云端技术的进步，已经可以将这些基础设施设定当作程序，无缝地让每个成员和所有环境都使用完全相同的设定，减少出错的可能性。
2.频繁且适当大小的递交
如果久久才递交一次修改到版本控制系统，那么你只是把版本控制系统当作一种备份工具而已，而没有享受到它真正的好处。频繁的递交可以帮助团队开发进度的透明化，减少多人开发时的代码冲突。当多人同时修改同一块代码时，解决代码冲突是很麻烦的事情。还有，我们也希望每一次的递交有适当的粒度大小，也就是每个提交的内容应该有高度相关性和独立性。例如是一个小功能或是一个小改进。如果你同时在做新功能A和修旧Bug，那么就应该分开两次递交。语法错误无法建构的程序也不应该提交从而造成团队困扰。
有良好大小的代码提交习惯的好处除了版本的历史纪录更加清楚之外，我们可以非常轻易的做代码的复原或移植，假设上述的新功能A有问题，我们可以只复原A而不影响修好的Bug，或是只挑选修Bug的移植到不同分支去。
3.良好的递交信息
每一次的递交程序员都必须附上一段解释信息，说明修改的内容和原因。这除了可以帮助团队合作之外，更重要的是让软件有更好的维护性，以便将来备查，以下的场景相信开发者都不陌生：
软件发现一个Bug，然后指派给你修复。
你追代码追到一段看不懂的程序，也没有任何注释。
透过版本控制系统，你找到了同事在一年前加了这行，递交的信息是BUG或简单的错误提示。
同事还在公司，可是他也不记得当初是哪一个BUG了。或是他已经下班或离职了，反正找不到。
你强行改了这行代码，发布出去。
这个功能是修好了，但是发现另一个功能又出现问题。
继续加班到凌晨，悲催ing....
一个好的递交信息应该包括一行摘要信息，描述你为什么做这段变更，可能是新增、移除、修正某个功能，而不是描述新增或修改哪些档案，重点应放在备注为什么修改而不是这段是bug这么简单。因为修改了哪些档案和行数我们看版本差异就知道了，无须重复描述。如果你发现很难摘要，那可能表示你包含太多变更在同一次递交了，请试着拆开。