背景
随着同一业务线研发人力增多，混乱往往就逐渐成为了必不可免的问题。此时如果没有一套科学的流程规范，成员「个性」将会导致项目维护成本越来越高
本文主要从分支和日志两个方面来谈谈git在项目版本管理中的策略
分支管理策略
说到分支管理，就不得不提工作流。目前业内广泛使用的工作流有三种：Git flow、Github flow、Gitlab flow
在写这篇文章之前，我用过的也只有Git flow一种，我原以为其一招鲜就可吃遍天，结果发现这事还没那么简单。对于这三种工作流的介绍，阮一峰老师的博客里写的很清楚，科普请自提之。这里主要说使用策略
阶段性版本发布项目（Git flow）
对于目标是一段时间以后产出一个新版本的项目，Git flow是合适的。特别是对于小团队单线开发，不会有多需求同时开发的情况。使用 Git-flow 可以最大程度保证项目安全、有节奏的完成发布和管理。因此 Git-flow 适合有节奏按版本发布的项目，团队人员在 4 人以下
在这种流程下，需要同时维护两个长期分支：master、develop。比较合适的场景有：
- 开源类库
- 客户端项目（如 iOS App）
持续发布项目（Github flow 与 Gitlab flow）
对于发版不固定，甚至代码一有变动，就部署一次的项目。Github flow是合适的。因为这种流程足够简单，就一个长期分支master维护。比较合适的场景有：
- Web 或者动态化业务（RN、Weex）
- 后端接口服务
上图是Github flow的一个单线使用流程。而在互联网公司中往往为了最大化产研资源利用率，当前功能刚提测，下一轮评审可能就来了，即一波赶一波。目前在我的团队，工作流以这个思想为前提稍加了改造，如图：
关于 CI 部署方面，统一走 Tag 事件，避免不小心合并到主分支导致提前发布
另外
gitlab flow倡导的上游优先策略不仅有能适应不同开发环境的弹性，也有单一分支管理的简单和便利。不过个人感觉没有前两种来的爽快…维护成本也不低。所以具体用哪种，还是综合下来看场景
合并小插曲
快速合并（Fast Forward）
常规合并（–no-ff）
从sourceTree图可以看到，如果执行快速合并，开发者根本不会看到被合并的分支，就像在当前分支直接 commit 一样
正常合并如果没有合并冲突，都会进行快速合并。但是对于大多数功能驱动式项目开发来说，要尽量避免快速合并，毕竟有些时候还是要追溯 log，不仅对于代码分析特别有用，另外保证整个项目提交链的完整性也很有必要
日志管理策略
起因
某次项目质量管理时发现了如下图这样的提交…一个修 bug 的操作，commit 却密集的提交了 7 次之多
git 日志过于随意会有什么问题？也许你会说代码写对、项目正常跑不就完了呗，何必纠结那些细节。但如果意识到以下问题，可能你就不这么想了：
- 正常运行的功能出问题，要回滚代码到某个改动前或者查哪个改动引起的问题
- Code review，试想一些很小的改动，却多次无效提交，一个个看会不会崩溃
- 提取迭代的记录（CHANGELOG）做某项总结，结果发现这段时间都 TM 干了些啥
- 破窗效应，分支污染将导致恶性循环，对往后的管理和维护是在埋雷
策略
此模块包含以下两个部分
- commit lint：用于在提交前检查 commit message 是否符合规范
- commit tool：帮助我们简便生成符合规范的 commit message
具体用法教程太多，比如这个帖子：https://juejin.im/post/6844903710112350221
逼格
如果想在日志里做点骚操作，可以考虑emoji。要实现这个你需要关注两个库：gitmoji、emojify
库安装好以后，在项目根目录执行：gitmoji -i，用来加 git 钩子，使得 commit 时可以弹出交互式 moji 对话框。另外配合 zsh 增加别名，让 git log 色彩斑斓
alias gl="git log --color | emojify | less -r"