代码管理V1.0完成了代码版本控制的由无到有，如果是小团队或者代码量不大这种配置架构不会有太大问题。但是当代码成指数增长人员超过10人以上就必须梳理配置管理方案。要在配置管理整体策略和软件平台化上做改进。在这种背景下，代码管理2.0诞生了。
一句话介绍Git&Gerrit
Git — 代码管理唯一工具，不接受反驳，即The stupid content tracker, 傻瓜内容跟踪器， 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
Gerrit —是一个免费、开放源代码的代码审查软件，利用网页浏览器，同一个团队的软件程序员，可以相互审阅彼此修改后的程序代码，决定是否能够提交，退回或者继续修改，出自google团队的开源项目。
代码管理V1.0方案的本质问题其实就是代码覆盖，违背了git的设计理念。于是有了以下代码管理V2.0优化方案：
1.代码建库方案
建立master分支用于代码提供商推送，建立debug分支用于调试，建立release分支用于输出版本。废弃代码覆盖方案，所有代码只可能在分支上存在差异，并严格控制分支数量禁止增加分支。
2.客制化方案及分支管理方案
客制化由于涉及到多个客户，是否每个客户分别创建一个分支，还是所有客户共用一个分支？如果分别创建，会有很多从平台merge的动作。如果共用分支，涉及不同客户的客制化代码的管理。而且某个客户的提交如果控制不好，可能影响到其他很多客户。为了照顾所有程序员的感受，最后的方案是：1）VIP客户独享分支，定期维护 2）其他客户通过编译控制feature实现差异化
3.引入代码审查机制
所有开发过程中的活动，包括代码、资源文件的改动，提交debug分支验证,完成自检和自测。
发起走读邀请，必须邀请一名模块相关同事和主管进行走读和代码审核；主管和同事都审核后决定是否提交到release分支；审核结果通过邮件通知团队成员。
代码管理V2.0建立了代码管理制度和代码质量控制，输出的版本质量直线上升，也解决了之前代码管理的混乱状况。
随着代码管理效率的提升于是诞生了一个真实的设计bug解决bug案例：某科技公司老板为结果论，对于能解决量产产品致命bug的程序员进行重奖。于是某猿设计了一个虚拟机重启的bug导致100万的订单无法交货，后来被他突然解决，顺利拿到了产品性能优化之星。贵公司有没有自己设计bug解决bug的程序员？
下期将继续谈谈配置管理的平台建设，进一步提升工作效率，让程序员有更多时间设计bug解决bug，多拿奖励。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。