版本控制之最佳实践（Git版）

http://blog.csdn.net/happydeer/article/details/17679369

现如今，应该每个开发者都在使用版本控制工具了吧。然而，如果你理解版本控制的基本规则，你便能更好地发挥它的效用。在此，我们汇总了一些最佳实践，希望你在使用Git做版本控制时能够了然于心、得心应手。

1.  相关的改动才放一起提交

一次提交（git commit）应该只包含相关的改动。比如说，修复两个不同的bug就应该分开来做两次提交。提交的改动越小（或越少），其他开发者理解起来就越容易；如果改动有问题，退回去也比较方便。Git有一个暂存区域（staging area）的概念，它还允许你暂存文件的某些部分，这更便于你创建非常细粒度的提交。

2.  经常性地提交

经常提交势必让你每次提交的东西都很少，也有助于你只提交相关的改动。并且，你还能更频繁地与别人共享代码。通过这种方式，所有人在集成代码时都会感觉更轻松，也就能避免一些不必要的冲突。相比之下，如果每次提交的东西很多、改动很大、时间间隔很长，那么在代码合并（merge）过程中产生的冲突就很难解决了。

3.  别提交半成品

你应该只在完工之后才提交。这并不是逼你把一个大块头功能完整实现好之后再提交。恰恰相反！你应该把大功能的实现分解成合乎逻辑的小块工作，并且记住要早一些、经常性地提交你的代码。只是要切忌为了提交而提交，比如在下班离开公司之前把一些东西仓促放入仓库中。如果你这么做只是为了从服务器抓取一份干净的代码（git checkout 或者git pull），可以考虑使用Git的“Stash”功能。

4.  提交之前必须测试

你“认为”已经完工了，然后就可以提交了吗？千万要抵得住这种诱惑！你应该进行全面的测试，以确保你真的是“完工”了，并且（在你能够识别的范围内）没有副作用。尽管将半成品提交到本地仓库不伤大雅（原谅你的庸人自扰），但当你把代码推送（git push）到服务器与别人共享时，这个问题就大了——在这之前，请务必测试你的代码！

5.  提交时须带上适当的描述

在描述的开头部分，你应该简单总结一下你所做的改动（别超过50个字）。然后，用一个空行将开头与主体部分隔离开来。在主体部分，你应该详细回答这些问题：为什么要做这次改动？跟以前的实现有什么不一样？请使用祈使语气和现在时态（比如，要使用“change”这个单词，而不用使用“changed”或“changes”），为的是与像git merge这样的命令自动产生的描述保持一致。

6.  版本控制有别于备份系统

把你的文件备份到远程的服务器上是版本控制系统的一个不错的副作用。但是，你不应该只把版本控制当备份系统来使用。版本控制追求的是每次提交的意义（请回过去阅读第一条：把相关的改动放在一次提交里）——你不应该填鸭式地塞入一堆毫不相干的文件。

7.  使用分支

分支是Git最强大的功能之一。这并不是偶然的——从一开始，简单、快速创建分支的能力就是对Git的一个核心需求。使用分支能够有效地避免不同开发工作之间的相关干扰。你应该在开发过程中广泛使用分支，它可以用于开发新功能、修复bug、试验新的想法……

8.  采用一致的工作流程

Git允许你采纳很多种不同的工作流程：持久存在的分支、主题分支、合并或复位、Gitflow（点我！）……你到底应该选择哪一种呢？这取决于几个因素：你的项目，开发与部署的整体流程，还有（可能是最重要的）就是大家的个人偏好。不管你们选择哪种工作流程，请确保团队中的每个人都对工作流程有相同的理解并且严格遵循。