程序员日常工作之代码版本管理

March 22, 2016

技术管理

作为一个开发工作者,每天都需要和代码打交道,在团队开发中,代码版本管理工具是咱们日常工作中经常使用的,下面是我在这么些年工作中碰见的问题的一个小结。

一般代码会被分成 开发分支 和 发布分支。发布分支上的代码是必须经过测试通过的代码,才可以提交到发布分支上,一般不需要,也不允许直接提交代码到发布分支上。开发分支是在开发一个功能或者模块开始的时候,从发布分支上拉出来的分支。

1.不允许提交不能工作的代码

意思是说你提交的代码不能引起其他人不能编译或者不能正常运行。在我经历的项目中,偶尔能碰见刚更新下来的代码不能正常编译,或者一运行起来就报错,这种情况大部分是有人少提交代码了,或者提交了多余的代码。在小项目或者小团队中,这种只能通过强调来约束开发者,在规模比较大或者成熟的团队中,可以借助一些自动化工具来避免这种情况发生。

2.代码要及时提交

在满足 1 的条件下,尽量及时提交代码。在项目开发中,碰见有人觉得合并代码比较麻烦,所以不愿意频繁的提交代码,曾碰见过有人从项目开始到整个功能完成才开始提交代码,结果合并代码的时候碰见了N多问题。也有人代码没有及时提交,搞了几天的代码由于电脑坏了,只能从头再写一遍,虽然这种事情是小概率事件,但是却是很致命的。

在一些项目中,如果你负责的是一个比较复杂的模块,需要的工期比较长,可以通过拉个人分支来解决问题,这样你可以放心的提交代码。

3.不堆攒代码一起提交

和 2 所说的及时提交大概一个意思。在项目开始的时候,你可能在短时间内完成了大部分代码,这些代码并不一定是完整的,但是在开发分支中,只要在能满足 1 的要求下,是可以提交的。这样保证在完成一个大的功能模块的一个小里程碑的时候,能及时提交代码。

4.一次提交只解决一个问题

一次提交只解决一个问题。一次提交只修改一个bug,多个bug分成多次提交。这样至少有两个好处,一是可以及时提交。二是方便追踪。很多时候咱们碰见问题,经常需要通过代码版本管理工具往回找原因,看看是哪次提交引入的问题,是什么时候提交的,由谁提交的,这样可以快速的找到问题,问清当时这样的改动是无意的还是有其他的原因。在往历史记录里找的时候,最怕的就是看见一个大的提交,在一次提交中修改了很多不同的功能,这样不能很直观的看出之间的相互影响。

5.提交尽量干净

干净的意思就是不要提交跟本次修改没有任何关系的代码。比如说你修改了一个bug,在修改的过程中,你修改了 N 多个文件的代码,但最终修改这个 bug 只需要修改一个文件的一行代码,那么只能提交这一行代码,其他在修改 bug 过程中改动的代码不能提交。比如你提交了一个代码,有 10 个地方修改了,其中有 9 个地方是你新增的打印日志的代码,并且提交前你又把它们注释掉了,而只有一个地方的修改才是有效的,如果你就这样提交了,会给看代码的人增加很多额外的工作。所以在提交前,要清除一下代码,把没必要提交的代码去掉,这样别人拿到代码一看,很清晰的看出了你修改了哪一行,增加了什么,删除了什么,很简单明了。

6.碰见没有格式化的代码怎么办

跟 5 说的大概一个意思。当你在一个没有格式化的代码里修改完 bug 后,提交的时候尽量保持提交的干净。不要把其他没有的因为格式化引起的代码变化提交了。如果你是在看不下去,可以单独提交一次格式化代码,然后加上备注,别人在看代码的时候就知道这次提交没有任何修改,只是格式化,基本上不会出现问题,在追溯代码的时候,可以简单的跳过去。

7.提交前格式化

提交代码前记得格式化代码。团队工作的时候,尽量保持团结成员的格式化工具或者格式化规则一致。当出现格式化工具或格式化规则不一致时,作为提交者,需要记住的是,你只能格式化你的代码。一个文件有 100 行,你修改了其中的 10 行,你只能格式化这 10 行,不能格式化整个文件。

8.尽量不使用 /**/ 来注释代码。

在 Java 中,/**/ 可以用来注释多行代码,但是我个人觉得不应该这样子使用。如果你使用这样的方式注释一个 100 行的代码,代码版本工具一般会显示只修改了 2 行,而中间的那些代码不被显示出来,别人在看代码的时候不能很直观的看出被注释掉的那 100 行代码,它还得付出额外的工作。现在主流的开发工具都有很快捷的方式使用 // 来注释多行,这样被注释掉的代码肯定被代码版本工具标识为修改。Java/Android 开发中如何正确使用注释 这篇文章中比较详细的说明了多行注释。

--- EOF ---

添加新评论