作为一个开发工作者，每天都需要和代码打交道，在团队开发中，代码版本管理工具是咱们日常工作中经常使用的，下面是我在这么些年工作中碰见的问题的一个小结。
一般代码会被分成 开发分支 和 发布分支。发布分支上的代码是必须经过测试通过的代码，才可以提交到发布分支上，一般不需要，也不允许直接提交代码到发布分支上。开发分支是在开发一个功能或者模块开始的时候，从发布分支上拉出来的分支。
意思是说你提交的代码不能引起其他人不能编译或者不能正常运行。在我经历的项目中，偶尔能碰见刚更新下来的代码不能正常编译，或者一运行起来就报错，这种情况大部分是有人少提交代码了，或者提交了多余的代码。在小项目或者小团队中，这种只能通过强调来约束开发者，在规模比较大或者成熟的团队中，可以借助一些自动化工具来避免这种情况发生。
在满足 1 的条件下，尽量及时提交代码。在项目开发中，碰见有人觉得合并代码比较麻烦，所以不愿意频繁的提交代码，曾碰见过有人从项目开始到整个功能完成才开始提交代码，结果合并代码的时候碰见了N多问题。也有人代码没有及时提交，搞了几天的代码由于电脑坏了，只能从头再写一遍，虽然这种事情是小概率事件，但是却是很致命的。
在一些项目中，如果你负责的是一个比较复杂的模块，需要的工期比较长，可以通过拉个人分支来解决问题，这样你可以放心的提交代码。
和 2 所说的及时提交大概一个意思。在项目开始的时候，你可能在短时间内完成了大部分代码，这些代码并不一定是完整的，但是在开发分支中，只要在能满足 1 的要求下，是可以提交的。这样保证在完成一个大的功能模块的一个小里程碑的时候，能及时提交代码。
一次提交只解决一个问题。一次提交只修改一个bug，多个bug分成多次提交。这样至少有两个好处，一是可以及时提交。二是方便追踪。很多时候咱们碰见问题，经常需要通过代码版本管理工具往回找原因，看看是哪次提交引入的问题，是什么时候提交的，由谁提交的，这样可以快速的找到问题，问清当时这样的改动是无意的还是有其他的原因。在往历史记录里找的时候，最怕的就是看见一个大的提交，在一次提交中修改了很多不同的功能，这样不能很直观的看出之间的相互影响。
干净的意思就是不要提交跟本次修改没有任何关系的代码。比如说你修改了一个bug，在修改的过程中，你修改了 N 多个文件的代码，但最终修改这个 bug 只需要修改一个文件的一行代码，那么只能提交这一行代码，其他在修改 bug 过程中改动的代码不能提交。比如你提交了一个代码，有 10 个地方修改了，其中有 9 个地方是你新增的打印日志的代码，并且提交前你又把它们注释掉了，而只有一个地方的修改才是有效的，如果你就这样提交了，会给看代码的人增加很多额外的工作。所以在提交前，要清除一下代码，把没必要提交的代码去掉，这样别人拿到代码一看，很清晰的看出了你修改了哪一行，增加了什么，删除了什么，很简单明了。
跟 5 说的大概一个意思。当你在一个没有格式化的代码里修改完 bug 后，提交的时候尽量保持提交的干净。不要把其他没有的因为格式化引起的代码变化提交了。如果你是在看不下去，可以单独提交一次格式化代码，然后加上备注，别人在看代码的时候就知道这次提交没有任何修改，只是格式化，基本上不会出现问题，在追溯代码的时候，可以简单的跳过去。
提交代码前记得格式化代码。团队工作的时候，尽量保持团结成员的格式化工具或者格式化规则一致。当出现格式化工具或格式化规则不一致时，作为提交者，需要记住的是，你只能格式化你的代码。一个文件有 100 行，你修改了其中的 10 行，你只能格式化这 10 行，不能格式化整个文件。
在 Java 中，/**/ 可以用来注释多行代码，但是我个人觉得不应该这样子使用。如果你使用这样的方式注释一个 100 行的代码，代码版本工具一般会显示只修改了 2 行，而中间的那些代码不被显示出来，别人在看代码的时候不能很直观的看出被注释掉的那 100 行代码，它还得付出额外的工作。现在主流的开发工具都有很快捷的方式使用 // 来注释多行，这样被注释掉的代码肯定被代码版本工具标识为修改。Java/Android 开发中如何正确使用注释 这篇文章中比较详细的说明了多行注释。
- EOF -
本站文章除注明转载外，均为本站原创或编译。欢迎任何形式的转载，但请务必注明出处，尊重他人劳动。
转载请注明：文章转载自 Binkery 技术博客 [https://binkery.com]
本文标题： 程序员日常工作之代码版本管理
本文地址： https://binkery.com/archives/526.html