使用版本控制系统的 3 个建议

如果说有什么是开发软体专案一定要使用的基础工具，使用「版本控制系统」应该可以记上一笔。无论是个人或是团队开发，都可以透过版本控制系统获得巨大的好处。

没有版本控制系统的话，档案可能被别人或自己不小心覆盖或遗失、也不知道是谁因为什么原因改了这段程式码、也没办法可以复原回前几天的修改。有了版本控制系统，开发人员只要将每次程式码的变更都纪录(Commit)起来，并且透过版本控制系统中进行更新。

有了版本控制系统，我们可以浏览所有开发的历史纪录，掌握团队的开发进度，而且作任何修改都不再害怕，因为你可以轻易的复原回之前正常的版本。我们也可以透过分支(Branching)和标签(Tagging)的功能来进行软体发行的不同版本，例如稳定版本、维护版本和开发中版本。

已经没有什么可以阻碍你使用版本控制系统，Git 或Mercurial 是免费开源的版本系统系统、随处可用的网路、便宜的云端伺服器，甚至有现成的第三方服务Github 或Bitbucket。

如果你还没有使用的话，建议马上为你的软体专案建立版本控制。接下来是几点使用版本控制系统的建议：

1. 把所有东西都放进版本控制系统

是的，「所有」专案中的产出物(Source Artifact)都放到版本控制系统之中，这包括了程式原始码、测试程式、文件、设定档、各种自动化脚本等等。除了新成员可以很容易拉出最新的版本马上开始工作之外，我们也希望在测试环境、正式环境中，也可以随时更新到我们所指定的版本，因此将所有变更的纪录保存起来是非常重要的。

例如，资料库纲要(Schema)的变更也必须纳入版本控制。首先，我们在资料库中纪录它目前的版本编号。接着我们每次的修改都透过一个自动化脚本来执行，并将这个脚本放入版本控制之中，而不是手动用指令去修改纲要。这样的好处是团队中每个人都可以透过版本控制系统看到这个变更，并且升级他的资料库。测试和正式的伺服器环境，也会透过这个脚本来自动进行升级。笔者熟悉的Ruby on Rails 中就有内建这样的Migration 机制，其他程式语言也有类似的资料库工具。

另外，以伺服器应用来说，光是有「程式原始码」还是无法100%让软体正确地跑起来，我们还需要知道伺服器的配置设定，包括基础网路设定、作业系统设定、依赖的套件版本等等。因此最好这些配置设定也可以纳入版本管理系统之中。近年来云端技术的进步，已经可以将这些基础设施设定当作程式( Infrastructure as Code )，无缝地让每个成员和所有环境都使用完全相同的设定，减少出错的可能性。

2. 频繁且适当大小的递交

如果久久才递交(Commit)一次修改到版本控制系统，那么你只是把版本控制系统当作一种备份工具而已，而没有享受到它真正的好处。频繁的递交可以帮助团队开发进度的透明化，减少多人开发时的程式码冲突。当多人同时修改同一块程式码时，解决程式码冲突是很麻烦的事情。还有，我们也希望每一次的递交有适当的粒度大小，也就是每个Commit 的内容应该有高度相关性和独立性。例如是一个小功能或是一个小改进。如果你同时在做新功能A和修旧Bug，那么就应该分开两次递交。语法错误无法建构的程式也不应Commit 造成团队困扰。

有良好大小的Commit 的好处除了版本的历史纪录更加清楚之外，我们可以非常轻易的做程式码的复原或移植，假设上述的新功能A有问题，我们可以只复原A而不影响修好的Bug ，或是只挑选修Bug的移植到不同分支去。