本文是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资源:
转载本文请注明作者和出处[Gary的影响力]http://garyelephant.me,请勿用于任何商业用途!
Author: Gary Gao( garygaowork[at]gmail.com) 关注互联网、分布式、高性能、NoSQL、自动化、软件团队
支持我的工作: https://me.alipay.com/garygao