版本控制的极佳实践

本文是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

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



你可能感兴趣的:(版本控制)