版本控制的极佳实践

本文是www.git-tower.com总结的使用Git的最佳实践，其中的大部分实践具有普适性，可用其他版本控制工具SVN，CVS等。　　

原文:http://www.git-tower.com/files/cheatsheet/Git_Cheat_Sheet_grey.pdf

"Best Practice of Version Control in Git"

1. 提交相互关联的变化(Commit Related Changes)

每次提交的应该是一系列有关联的变化。例如，修复了两个不同的bug应该分别提交两次。提交的变化少，

其他开发者更容易理解变化的内容，出现问题更容易回滚到原来的状态。　　

译者注：假想现在有2个bug，第一次提交时第1个bug修复完毕，第2个bug修复了一半，第二次提交时2个bug修复完毕。

后来发现需要先仅修复第1个bug，因为第一次提交时包含了第1个bug的修复代码与第2个bug的半成品，所以需要恢复到上次

提交状态之外的额外努力，使用版本控制带来的便利就大打折扣了。

2.经常提交(Commit Often)

经常提交可以保证提交的变化少而且相互关联。而且，可以更快地使其他开发者看到最新的代码。这样更容易让所有人快速

合并变化，避免发生冲突。若偶尔提交一次且代码变化较大，将使冲突很难解决。

3.不要提交半成品(Don’t Commit Half-done Work)

不要提交未完成的代码。这并不是要求你完成某个全面、大型的功能的代码后再提交，而是：按逻辑将其分解成多个部分并尽早提交。

不要为了将代码存储到服务器上而在下班前匆忙提交，如果仅仅是为了提交今天的工作内容，尝试使用“git stash”代替”git commit”。

4.提交之前先测试(Test Code Before You Commit)

不要提交你”认为”已经完成的内容。先对改变的代码作详尽的测试并确保所做的改变没有副作用。虽然提交半成品仅仅需要的

是原谅自己，然而向服务器提交测试过的代码再让其他开发者使用更重要。

5.写有用的提交记录(Write Good Commit Message)

先简短地总结对文件所做的改变，插入空行，再写详细内容。详细内容应该提供了以下几个问题的答案：

— 改变的目的？

— 改变后与上次实现的区别？

6.版本控制不是文件备份(Version Control Is Not A Backup System)

将文件备份到服务器上是版本控制工具带来的副产品，但是你不应该把版本控制系统用来备份文件。使用版本控制时，应力求

每次提交的都是相关联的变化(见第一条)——而不是提交一堆文件。

译者注：版本控制的目的是易于追踪文件变化，方便多人协作，实现开发中的工作流(branch, merge, tag...)

7.使用分支(Use Branches)

分支是Git最强大的特性之一——这并非偶然：Git最初的核心目标就是快速简单地建立分支。分支是帮助划分多个开发路线的完美

工具。你应该在开发工作流中广泛应用分支:如增加新功能，修复bug，验证想法...

8.寻求帮助(Help & Documentation)

通过 git help <command>获取git命令的帮助　　

Git 官方网站: http://www.git-scm.com　　

学习Git资源:

http://progit.org　　

http://book.git-scm.org　　

http://gitref.org

译者：

Garyelephant

mail:garygaowork#gmail.com

关注软件团队的高效运行，团队管理。