近期，所在的4人小型团队完成了一个重大节点。在这几个月中，我尝试在团队中推行Git，作为代码版本管理和项目跟进的工具。总的来说，不算成功也不算失败。虽然尝试推广的是一个工具，但也许会给其他类型的技术推行提供参考。
1. 背景
离开背景谈经历也许是耍流氓。
团队人员为4人，在这个规模沟通起来是比较容易的。沟通的方式我们没有采用企业OA系统，就是最普通的聊天工具——微信。
团队成员背景更偏重于汽车电子软件项目，对汽车行业的嵌入式软件开发流程比较熟悉，但是没有进行过其他类型的软件开发工作。在这个背景下，开发人员更注重的模型代码、功能安全、可靠工具链、V型开发流程、HIL硬件在环测试等内容，对于现代IT企业的敏捷开发、DevOps等概念了解较少。
但本项目的要求不同于汽车电子软件项目。随着项目推进，软件开发本身带来的效率和沟通、文档需求，一些先进的软件工程的方法论和工作流需要被提上日程。
另外，该项目内容不100%为软件开发，意味着也需要一个工具来对整个项目进行项目跟踪和管理。
简短来说：
- 4人小型团队
- 无现代软件开发背景
- 代码管理和项目管理需求
因此，就有了这篇在团队中推广Git版本管理系统经历记录。
Git这个工具虽然早已司空见惯，不过笔者作为一名刚刚下山的菜鸟，本文更想探讨的内容是这次经历本身，例如对项目的影响、成员的反馈、行动阻力等等。
本文的行文分为两条线索：
- 工具（Git），包括选型、建设、推广
- 经历，包括阻力、影响因素和心得
2 建设
自我实践
想要推广技术，我的想法是首先自身积累一定经验。自己信服后，才能说服他人。
18年9月，个人最开始使用的Github作为自身的学习积累和代码管理平台，并产出博文。
如下：
- PAT机考代码纪录 & 考点管理
- Git Playground
- Reinforcement Learning Playground
- 个人小车 – RaspTank代码库
通过实际使用，掌握了常用的工作流和使用方法。
平台选型建设
回归工具本身，少不了调研和建设的过程。
因为较早接触了Git先入为主，考虑熟练和推广就没用考虑SVN等平台。
对于团队需要的版本管理系统，有如下方案：
1.公有平台的企业服务：
这一类服务商就比较多了，从Github的私有库套餐，到国内Coding.NET和Gitee，都提供了私有团队的托管服务。
2. 自建服务
典型的自建服务器使用Gitlab等软件。
最终选择了购买小型云服务器，使用Gogs自建Git平台。
- 项目周期在5月末即结束
- 代码安全与隐私
- 牵扯精力
- Gogs相对Gitlab硬件要求低，部署简便
如果团队更大，基础设施这部分可能就会涉及到一个部门的职责了。
说安全性，这类自建平台的安全性也不可控。恰好前段时间的Github部分私有库被脱，归根结底还是社会工程学和安全意识的问题。
二次评估
我需要明确的是，我在这里折腾的动机是什么？是要解决代码版本管理和项目跟踪管理的根本需求。
所以，我进行了二次评估：使用这套工作流程，真的会解决问题吗？
如果读者是一位很熟悉Git的人，你的答案很可能是Yes。不过结合背景，考虑到工期，熟悉上手时间，或是更不可控的反弹呢？
我专门和前项目负责人（指师兄）进行了探讨。达成的共识如下：
- 结合一直以来容易发生的问题，我们确实急缺版本管理系统
- 提高效率，会大大节省工作时间，反而划算
- 但不要追求完美，可以在本次普及部分功能，由有经验的人指导主管，形成工作流的习惯
回想起来，个人觉得最后一点很重要，即普及部分功能，一旦节省出的时间＞学习工具的时间，就是划算。
经过二次评估后，这件事可以做。
3 运行
技术交流会
作为起步，整理了一份分享在小型碰头会上分享，主要内容：
- 系统介绍
- 优势
- 代码版本管理和项目管理需求
得到的反馈非常积极。
然后着手准备了一次培训会，主要是
- 工具链的版本控制系统（其实本来用的工具链中就集成了SVM和Git）
- 拉取、分支、合并
- issue使用
- wiki使用
现在觉得感谢战友的耐心和理解。
实际使用
实际使用中，涉及的部分如下
版本管理
基本的代码版本管理功能。分支创建合并由1人负责进行。
项目跟踪
使用issue进行重要节点、里程碑设定。
项目问题讨论、发现、追踪。
文档编写
使用内建Wiki系统作为文档系统。实际使用简洁又方便。
尾声与总结
在中期，工作流使用习惯发展得比较理想，现在回想，一个重要原因是 大家还有心情去习惯新的工作流方式。
之前提到了“不算成功也不算失败”，在后期，进入了1周时间的集中办公，导致之前养成的工作流习惯受到极大影响。
- 本项目不是100%的软件开发，所以会分许多精力到其他事宜上（客观原因）
- 后期的工作状态逐渐失调，进入赶工状态，步调被打断。在代码整洁之道和一些博客中常常提到这种不健康的工作状态（主观原因）
接下来，可能会做以下事情
- 将工作流整理成共同守约，不能因为步调失稳废弃，得不偿失
- 将工作流维护上升成团队共同负责
