身处制造业，看着新闻报道、公众号文章、各种互联网相关行业会议演讲中一个个先进而高效的软件开发方法、工具、实践，也是会眼红的嘛。这个系列主要讲讲这几年我所在的软件开发团队成功和失败的改变。顺便，展望一下未来的发展方向，立一些flag。

✅ 引入Git和GitLab进行代码版本控制

我是2013-11-11光棍节入职的，现在回看GitLab上最老的一个commit，是2013-11-14中午提交的。

入职后不了解产品，不了解团队，还是个战斗力只有五的渣渣，看通信协议的同时，能做什么呢？当时的选择是申请了一台服务器，做代码版本控制用。

在此之前，团队是以文件名包含软件名称、版本、日期的压缩包发给专人的方式进行存档的。开发工程师7位，设计师1位，几乎没有2个人合作编辑同一个源文件的情况。

2014-01-11 装上了GitLab CE 6.3，开始在团队内提供服务。

（不用尝试往这个邮箱发信调戏我，公网上没有对应的MX record，会退信的~）

2014-01-13 先是通过在工作日报里包含指向GitLab commit的超链接，让部门领导在系统上线两天后注册了账号看到了我的项目和代码提交。

2014-04-14 在我参与的两人项目里，影响了第一位小伙伴与开始一同使用git管理代码版本。这第四位用户的注册，距离系统上线整整经历了一个季度。

2014-08-13~22 一次使用培训+一周时间，当时在职的开发工程师，陆续注册了账号，系统用户数达到9人，基本覆盖了目标用户群体。此后GitLab注册和git基本命令的掌握成为新员工入职checklist上的两行。

2020-01-01 系统一共有162个用户，其中105个active user，已经不局限在软件开发的团队。

我付出了什么？

服务器运维往往在下班时间进行。

要在工作之余准备不同层次的Git相关培训。

要伤脑筋考虑怎么对非开岗和合作部门安利这个系统对他们的使用价值，并碰N次钉子。

团队得到了什么？

（按时间先后排序）

不怕硬盘故障、丢失。项目代码多处完整历史。哪怕是单人项目，也有本地+服务器两份。17年之后服务器也有了异地备份。

效率提升。用软件而不是人工进行版本控制本就是为了更高效。分支、放弃修改、回退、合并等日常用到的，以及还不怎么被使用的bisect（已知无bug的commit和发现bug的commit间二分查找问题commit）、cherry pick（挑选某个commit合并到当前分支）

可以了解代码形成过程，通过git blame得知具体问题可以向谁咨询。这在单人项目中完全没有需求，但是多版本迭代、多人合作、项目间人员流动的情况下，逐渐显示出价值。

建立了集成自动化分析过程和工具的基础。不论是后面的CI还是CD，版本控制服务器总是一个必不可少的前提。

经验教训

硬技能光培训不考试，掌握起来就是慢！

同部门的推广障碍小，因为大家利益高度一致。跨部门的推广非常困难，必须找到一个或多个切入点，使得学习一个新系统使用的成本远低于获得的收益，才有可能被接受。其实GitLab的issues里讨论和论坛回帖有啥区别呢？在我们不要求外部用户用Markdown语法来评论的前提下，一点都没有。可事实就是，除非对具体目标的实现或者过程的控制有明显帮助，多一事确实不如少一事。

系统的引入是典型的一把手工程。当部门领导意识到系统的收益，就能快速并入工作流程。

当一把手踌躇的时候，可以缩小范围，从个别人、个别项目开始，做成功案例，再逐渐推广到更多人、更多项目。这样虽然慢，但是阻力小很多。

下一篇讲讲上系统之后的跟着GitLab的功能发展，逐渐做CI的经历。