经历记录：在团队中推广Git版本管理系统

近期，所在的4人小型团队完成了一个重大节点。在这几个月中，我尝试在团队中推行Git，作为代码版本管理和项目跟进的工具。总的来说，不算成功也不算失败。虽然尝试推广的是一个工具，但也许会给其他类型的技术推行提供参考。

1. 背景

离开背景谈经历也许是耍流氓。

团队人员为4人，在这个规模沟通起来是比较容易的。沟通的方式我们没有采用企业OA系统，就是最普通的聊天工具——微信。

团队成员背景更偏重于汽车电子软件项目，对汽车行业的嵌入式软件开发流程比较熟悉，但是没有进行过其他类型的软件开发工作。在这个背景下，开发人员更注重的模型代码、功能安全、可靠工具链、V型开发流程、HIL硬件在环测试等内容，对于现代IT企业的敏捷开发、DevOps等概念了解较少。

但本项目的要求不同于汽车电子软件项目。随着项目推进，软件开发本身带来的效率和沟通、文档需求，一些先进的软件工程的方法论和工作流需要被提上日程。

另外，该项目内容不100%为软件开发，意味着也需要一个工具来对整个项目进行项目跟踪和管理。

简短来说：

• 4人小型团队
• 无现代软件开发背景
• 代码管理和项目管理需求

因此，就有了这篇在团队中推广Git版本管理系统经历记录。

Git这个工具虽然早已司空见惯，不过笔者作为一名刚刚下山的菜鸟，本文更想探讨的内容是这次经历本身，例如对项目的影响、成员的反馈、行动阻力等等。

本文的行文分为两条线索：

1. 工具（Git），包括选型、建设、推广
2. 经历，包括阻力、影响因素和心得

2 建设

自我实践

想要推广技术，我的想法是首先自身积累一定经验。自己信服后，才能说服他人。

18年9月，个人最开始使用的Github作为自身的学习积累和代码管理平台，并产出博文。

https://steinslab.io/archives/1520

如下：

• PAT机考代码纪录 & 考点管理
• Git Playground
• Reinforcement Learning Playground
• 个人小车 - RaspTank代码库

通过实际使用，掌握了常用的工作流和使用方法。

平台选型建设

回归工具本身，少不了调研和建设的过程。

因为较早接触了Git先入为主，考虑熟练和推广就没用考虑SVN等平台。

对于团队需要的版本管理系统，有如下方案：

1.公有平台的企业服务：

这一类服务商就比较多了，从Github的私有库套餐，到国内Coding.NET和Gitee，都提供了私有团队的托管服务。

2. 自建服务

典型的自建服务器使用Gitlab等软件。

最终选择了购买小型云服务器，使用Gogs自建Git平台。

• 项目周期在5月末即结束
• 代码安全与隐私
• 牵扯精力
• Gogs相对Gitlab硬件要求低，部署简便

如果团队更大，基础设施这部分可能就会涉及到一个部门的职责了。

说安全性，这类自建平台的安全性也不可控。恰好前段时间的Github部分私有库被脱，归根结底还是社会工程学和安全意识的问题。

GitHub源码被黑客洗劫和勒索事件 微软也未能幸免

二次评估

我需要明确的是，我在这里折腾的动机是什么？是要解决代码版本管理和项目跟踪管理的根本需求。

所以，我进行了二次评估：使用这套工作流程，真的会解决问题吗？

如果读者是一位很熟悉Git的人，你的答案很可能是Yes。不过结合背景，考虑到工期，熟悉上手时间，或是更不可控的反弹呢？

我专门和前项目负责人（指师兄）进行了探讨。达成的共识如下：

• 结合一直以来容易发生的问题，我们确实急缺版本管理系统
• 提高效率，会大大节省工作时间，反而划算
• 但不要追求完美，可以在本次普及部分功能，由有经验的人指导主管，形成工作流的习惯

回想起来，个人觉得最后一点很重要，即普及部分功能，一旦节省出的时间＞学习工具的时间，就是划算。

经过二次评估后，这件事可以做。

3 运行

技术交流会

作为起步，整理了一份分享在小型碰头会上分享，主要内容：

• 系统介绍
• 优势
• 代码版本管理和项目管理需求

得到的反馈非常积极。

然后着手准备了一次培训会，主要是

• 工具链的版本控制系统（其实本来用的工具链中就集成了SVM和Git）
• 拉取、分支、合并
• issue使用
• wiki使用

现在觉得感谢战友的耐心和理解。

实际使用

实际使用中，涉及的部分如下

版本管理

基本的代码版本管理功能。分支创建合并由1人负责进行。

项目跟踪

使用issue进行重要节点、里程碑设定。

项目问题讨论、发现、追踪。

文档编写

使用内建Wiki系统作为文档系统。实际使用简洁又方便。

尾声与总结

在中期，工作流使用习惯发展得比较理想，现在回想，一个重要原因是 大家还有心情去习惯新的工作流方式。

之前提到了“不算成功也不算失败”，在后期，进入了1周时间的集中办公，导致之前养成的工作流习惯受到极大影响。

• 本项目不是100%的软件开发，所以会分许多精力到其他事宜上（客观原因）
• 后期的工作状态逐渐失调，进入赶工状态，步调被打断。在代码整洁之道和一些博客中常常提到这种不健康的工作状态（主观原因）

接下来，可能会做以下事情

• 将工作流整理成共同守约，不能因为步调失稳废弃，得不偿失
• 将工作流维护上升成团队共同负责