代码管理 详解，用好Git

大家好，欢迎来到停止重构的频道

接着之前的Git介绍，本期我们讨论在实际项目中，如何用Git做好代码管理。

实际软件项目中，代码是由多人参与开发的，也会有多版本、多环境的副本。即使选用了Git，也会经常出现代码覆盖、冲突等问题。

一旦出现这些问题，都需要花时间去恢复、排查，一来二去会花很多时间。

我们按以下顺序展开讨论

1、代码管理存在哪些问题

2、多环境代码管理

3、多版本代码管理

4、多人协同开发

5、日志规范

代码管理存在哪些问题

​我们需要清楚代码管理存在哪些问题，才能更好地解决。

一般具有一定规模的项目，都存在多环境/多版本代码、多人协同开发、日志规范的问题。

首先是多环境代码的问题。

​多环境指的是，一般项目都会有开发环境、测试环境、生产环境，一些更大型的项目甚至有子系统开发环境、灰度发布环境等。

不同环境对应不同的代码。

理想情况下，多个环境的代码是按发布流程顺序更新的，这看起来只是顺序的版本覆盖。

所以在理想情况下，多环境代码管理并没有什么问题。

例如在一个迭代周期内，开发完成后会更新测试环境代码，测试通过后会更新生产环境代码。

但是实际过程却并不都是顺利的。

例如，测试阶段发现BUG，而开发代码已经进入新版本开发。

或者，生产环境发现紧急BUG需要立刻修改，但是开发、测试流程已经处在新版本阶段。

这些情况应该如何处理，是多环境代码管理应该关注的问题。

接下来是多版本代码的问题。

多版本代码指的是，需要同时维护的多个版本的代码。

例如软件产品推出了新版本，但某几个lts版本仍然需要维护修改bug，或者基于同一Base的多个版本代码，业务上可能分为lite版、专业版、旗舰版。

​多版本代码一般是完全独立的，每个版本会有各自的迭代计划。

但是多版本代码一些时候会有一些联动。

例如某个版本代码发现了基础的BUG，需要同时升级全部版本代码。​或者业务功能分级变化，一些旗舰版的功能需要移植到别的版本中。

​这些情况应该如何处理，是多版本代码应该关注的问题。

接下来是多人协同开发的问题。

多人协同开发指的是，多人同时参与一份代码的开发。多人开发看起来不会有什么问题，毕竟Git能提示更新冲突。

但实际上经常会出现代码覆盖的问题，即使开发人员可以耐心处理更新冲突，但处理起来还是特别麻烦的。

特别是多人同时提交代码时，经常是刚处理完更新冲突又出现新的更新冲突。

多人协同开发的主要问题是如何避免更新冲突。

接下来是日志规范。

日志规范是经常被忽略的，但是却是非常重要的。

Git等版本管理系统的作用在于记录变化，方便日后翻查记录，而日志是翻看记录时很重要的标识。

如果开发人员的更新日志是胡乱写的，如11月20日更新、更新bug等，则日志变得毫无意义，日后翻查也会变得非常艰难。

多环境代码管理

接下来详细展开多环境代码管理问题。

本小节以最常见的开发-测试-生产这3个环境为例展开。

对于多个环境的代码，通常是为不同的环境代码建立不同的Git仓库分支。

​也就是开发分支、测试分支、生产分支，通常直接采用主分支作为开发分支。

一般情况下，按照一个迭代周期。

开发完成后，将开发分支代码合并到测试分支并编译发布到测试环境。

测试流程通过后，将测试分支代码合并到生产分支并编译发布到生产环境。

线上主要功能测试通过后，即可视为一个迭代周期结束。

这种顺序流程的代码分支合并是简单的，因为不会出现修改冲突，所以一般在Git的管理网页做一下分支合并即可。

一个迭代周期结束后，最好是对生产分支新建一个tag标识，以标记迭代节点方便日后查看。

而实际项目过程中，并不是完成一个迭代周期后再进入下一个迭代周期的。

当开发完成后进入测试流程时，测试是需要时间的，测试期间开发人员并不会原地等待，开发一般会进入下一个版本的开发，但是测试过程中也可能会发现问题。

这时推荐的做法是，对开发分支复制一个临时分支作为下一个版本的开发副本。​

而开发环境也应该是两个，一个对应当前版本的开发、修改测试发现的BUG，一个对应下一个版本的开发。

测试过程中发现的问题在开发分支上修改，这样能防止污染当前迭代版本的代码。

当前迭代版本流程完成后，再将临时分支代码合并到开发分支并删除，这里可能会发生修改冲突而需要人工处理。

另外，当生产环境发现BUG，而开发、测试已经处在新版本阶段时。

如果不太严重，可以作为下一迭代周期的任务，这样能防止打乱计划。

如果特别紧急需要马上解决，则对生产分支复制一个临时分支作为修改的副本，而代码运行的环境可以是内部的生产环境。

通过测试后将临时分支合并到生产分支并进行紧急发布，临时分支的修改需要在紧急发布后同步到开发分支再删除。

并记录作为下一发布版本的修改点，走正常的测试、发布流程，防止临时修改的代码影响到其他新功能。

多版本代码管理

接下来详细展开多版本代码管理问题。

多版本指的是多个需要独立迭代维护的软件版本，如lite版、专业版、旗舰版。

如果仅仅是迭代版本，也就是说，8月版本会覆盖7月版本，且7月版本不再单独维护修改，则只需要打tag标记即可。

多版本的代码可以对应建立多个远程仓库管理，因为多版本代码实际上是完全独立的，每个版本有独立的迭代计划，甚至由不同的开发团队维护。​

​多版本代码管理的重点，主要是当某个版本出现BUG并修复后，可能需要给某些版本同步修改，其次是从某个版本中移植一些功能到别的版本。

这些工作并不是简单的代码合并就可以了，因为各个版本是独自维护迭代的，所以即使表面功能一致，内部的代码也可能不一样。

实际上Git对多版本代码管理的帮助是很少的，更多是依赖工程结构规范和清晰的版本功能清单。

我们一直推荐将工程分为业务代码、模块代码，多版本代码共用一套模块代码。

模块代码BUG修改后，同步更新全部版本。

业务代码需要按功能清单的功能模块分类进行划分，这样根据功能清单就能快速定位代码位置。

其次是在工作安排上需要预留多版本修改的时间，因为确实多版本修改并不是合并代码这么简单，实际情况要复杂得多，很多时候内部代码会存在差别，需要人工判断修改。

多人协同开发

接下来是多人协同开发的问题。

多人协同开发最严重的问题是，由于某个开发人员强制提交Git远程仓库，导致把别人刚更新的代码覆盖了。

针对这种情况，可以对仓库分支设置禁止Git强制提交，Gitlab设置如图所示。

设置后就不能强制提交相互覆盖了，​强迫开发人员手工处理更新冲突。

而实际情况是，更新冲突的处理特别麻烦。​特别是多个开发人员集中时间提交的时候，经常刚处理完更新冲突再提交时，又出现了新的更新冲突。

实际上，多人协同开发的冲突问题，是多人同时改一个文件造成的。

​只要不存在多人同时改一个文件的情况，就不存在更新冲突了。

对于这个问题，只能通过合理的项目工程结构、合理的分工解决。

划分工程结构时不要仅仅考虑代码复用，这样会造成过多的通用文件，过多的通用文件机会造成源源不断的修改冲突。

分配任务时，应该按一个较大的功能模块划分，而不是按每个人几个功能，这样也能缓解多个人同时修改相同文件的问题。

​关于工程结构规整化的问题，可以翻看我们之前的《前端规整化》、《后端规整化》​。

日志规范

​​接下来是日志规范的问题，Git要求在提交更新时填写更新日志。

​更新日志需要写明更新目的，推荐在日志前缀标识功能更新还是bug修复，如果团队使用项目管理系统管理任务的话，可以在日志中加上对应任务ID标识​。

另外，更新提交应该是按某个功能、某个bug修改为单位的。

如果是按天或一定周期提交一次代码的话，则更新日志就变得没有意义了，这样也会造成过多的碎片记录，对翻看历史记录造成阻碍

​随着人员、时间流动，混乱的日志等于没有日志。

如果编写某个功能需要几天，且害怕期间的代码会丢失，可以建立个人的临时代码分支保存​。

总结

​本期讨论了在多人参与、多版本、多环境等情况下，如何更好地用Git做好代码管理。

通篇下来会发现，单纯地使用Git，并不能直接解决所有的代码管理问题，还需要制定合理的项目流程和合作规则。

这也说明一个道理，技术工具是能解决场景下某个具体问题的。

但只依赖技术工具的话，是处理不好整个场景的。