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

现现在，应该每一个开发者都在使用版本控制工具了吧。然而，若是你理解版本控制的基本规则，你便能更好地发挥它的效用。在此，咱们汇总了一些最佳实践，但愿你在使用Git作版本控制时可以了然于心、驾轻就熟。

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

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

2.  常常性地提交

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

3.  别提交半成品

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

4.  提交以前必须测试

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

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

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

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

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

7.  使用分支

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

8.  采用一致的工做流程

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

 

原文连接：http://www.git-tower.com/learn/version-control-best-practices.html