使用版本控制系统的 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的移植到不同分支去。

3. 良好的递交讯息

每一次的递交我们都必须附上一段解释讯息，说明修改的内容和原因。这除了可以帮助团队合作之外，更重要的是让软体有更好的维护性，以便将来备查，以下的场景相信开发者都不陌生：

1. 软体发现一个Bug，下班前指派给你修

2. 你追Code 追到一段看不懂的程式，也没有任何注解

3. 透过版本控制系统，你找到了某A 君在一年前加了这行，递交的讯息是Fixed shit bug 或一个单字Tweaks

4. A 君还在公司，可是他也不记得当初是哪一个shit。或是他已经下班或离职了，反正找不到

5. 你硬改了这行code，发布出去

6. 这个功能是修好了，但是发现另一个功能烂了

7. 继续加班到凌晨

一个好的递交讯息应该包括一行摘要讯息，描述你为什么做这段变更，可能是新增、移除、修正某个功能，而不是描述新增或修改哪些档案，重点应放在Why 而不是What 。因为修改了哪些档案和行数我们看版本差异就知道了，无须重复描述。如果你发现很难摘要，那可能表示你包含太多变更在同一次递交了，请试着拆开。

更多讯息细节可能包括1. 为什么这个修改是必要的？因为某种Workaround？2. 解决问题背后的原理是什么？3. 影响的副作用是什么？5. 专案管理系统(Issue Tracking System)的关联票号等等