这篇文章，不是写教如何使用 git 有哪些常用命令，跟svn有什么区别，代码管理流程有哪些？在网上有一大片，许多大佬都给我们整理不只几份。像阮一峰、廖雪峰等人。所以，你们没有必要看我搬运这些知识。
这里我说一下我的经验，我认为可能些许有些帮助，也比较基础，觉得掌握的同学可以跳过。
大家是否觉得，网上这些大佬的教程，是不是跟你司的git 代码管理操作差距较大，但是还能维持代码正常迭代？再者，公司有好多仓库，尤其是一些基础公共库，采用你压根没见过的流程？甚至有的仓库代码要快速迭代，管理者他说怎么来就怎么来，但也不影响代码正常迭代？
上面的3种情况，有的人没有遇到过，体会可能不深。说点实际的，假设你准备跳槽到另一家公司，那这家公司代码管理一样吗？显然多少不一样，如果不一样，那么是否合理，自己是否能改进了？再假设自己，想搞一个纯技术 git 代码管理流程，十部也需要走业务代码管理流程呢？
我想，有一部分git命名玩的很熟，但不明白git管理怎么各式各样的同学，急需知道下面这些内容和认知。
题外话，我是一名纯业务部门前端开发，对git 学习，不应该永无止境，而应该有边界。我司有一个架构平台，有人专门负责 gitlab 维护，有个500人群时不时提出各种问题。想想看看，你对 git 熟悉程度，能有这位负责的人强，不可能吧。具体边界因人而已，需要自己琢磨，自我认知。
1 常见的 Git 流程
常见的git 流程有3种，大家看这篇《Git 工作流程》，具体我就不详讲。
- Git flow
- Github flow
- Gitlab flow
只要你理解这3个流程，这篇文章核心是下面这段话
本文的三种工作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。 它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
说人话，我的理解是：不管哪个流程，都有以下4个步骤。
- 明确分支种类、数目、角色有哪些。
- 明确代码发布流程步骤（在哪个分支发布？发布后当前代码如何留痕，以备回退之用）。
- 明确测试阶段 bug 修复流程（具体到：开发调试bug分支和qa测试分支隔离，永远保证qa人员测试代码是最新的）。
- 明确生产 bug 修复流程。
在 git 代码管理这块，只要做到以上这些，保证发版部署不出问题，个人认为都是可以流程。但是作为工程师，仅仅可以不够的，还有效率。
2 git 流程效率问题
效率与什么有关？工程的复杂度，如果负责度够高，那么它的学习成本、实操人力成本都是比较高，反之，这两类成本低。
下面这张图，gitflow 流程的，有多少团队完全照这流程执行，还不是‘偷功减料’地简化，你看着图，就觉得很负责，想想开发学习很成本。
最开始我们团队，制定 git 流程完全照搬git flow，每次开发好都向 develop、release、hotfix 发起 merge request，这个不只在本地合并代码，也在 gitlab 操作，代码任何一次改动，小组长都是 codereview 的。
搞了几个迭代，发现开发大量时间浪费在合并代码，于是简化流程。最后没有那么多分支，只变成feature、release、master。大概是下面这样图。
如果你了解 gitlab flow，上图就是其中一种模式。几乎和下面这样图一样，分支名称换了。
为什么我们一开始不尝试 gitlab flow？说句实话，当时团队第1次扩充到十几号人，不好评估采用哪个流程合理，很多时候时候团队也是第1只螃蟹的人，只有实践踩了坑之后才知道。另外，经过这么折腾，我们git流程分支名不采用 gitlab flow 标准定义分支名，是有正确的。feature、release、master 好理解太多了，在与其他团队前端沟通时，不用做过多解释。
3 自制 git 流程
所谓自制 git 流程，实际上也不是完全自制，是现有流程改造，对就是git flow 、gitlab flow 改造，至于 github flow 流程，这个是开源的流程。
因为是前端，这里我以前端库为例子来说明。
在前端项目工程，有什么需要特殊自定流程？ npm 公共 js-sdk 库需要。
上图是我为一个npm 公共js-sdk库定的 git 流程，基本上是 git flow 流程简化后，再次继承上添加 npm version 流程。
首先，大家先看是不是我做下面4点？
- 明确分支种类、数目、角色有哪些。
- 明确代码发布流程步骤。
- 明确测试阶段 bug 修复流程。
- 明确生产 bug 修复流程。
npm 公共 js-sdk 库 有什么特殊？特殊在于 npm version 版本，假设有开发共能 feat1 开发完了，在业务项目进行移测，此时定 npm 包版本是 0.2.0，如果直接这么设置，0.2.0 就已经对外正式版本，并未完成测试通过，很有可能其他开发 npm install 安装这个库这个版本，引入这个模块报错，引发生产问题。所以，不是任何人和人和分支上定义 0.2.0 这样版本的。但开发也需要定义 npm 版本，发到 npm 库里去，进行调试。怎么办了，我们引入0.2.0-1这样版本。
综上所述，将 0.2.0-1 这样版本允许普通开发，在 hotfix 和 feature 定义，开发负责人可以在 relase 和 hotfix 定义 0.2.0或0.2.1 这样版本。具体，可以看上图。
ps: 有的人会说，不是可以使用 npm link，它有2个问题，问题1：如果feat1的 js-sdk 的开发与接入不是同一个人，也就是2台电脑，npm link 不适用；问题1，npm link 接入业务项目，它是不改写 package.json 版本，这个极容易忽略。 扯远了，这块不属于git 知识点。
4 任何流程不能满足所有场景
任何流程不能满足所有场景，需要灵活思考找解决方案。
举个例子：
某产品🐶，提了个需求，要求开发同时要做 feature1 和 feature2，其中 feature1 先提前好几天提测并发布到产线上，在当发布 feature2 当天，你发现 feature2 没有 feature1 的代码，然后心里各种羊驼 🦙，果断延迟上线，被产品、测试的领导投诉。
这种场景的问题，我在团队头1年半内，开发这种事情时不时出现，甚至1个月就3个迭代，连续出现3次，已老板已经发怒。解决方案：准备制定一个较长人工checklist流程，保证以后不在出现这种问题。
我那天恰好经过，我想了有什么办法解决？刚好想了一个点子，我当前开发分支在push的时候，能不能自动检测有无远程master 最后一个commitId。于是一个周六上午撸出来了 cli 小工具，大家也可以自己看看 check-has-master-last，后面团队，所有前端仓库都接入，2年多了没在发生这种事情，上次发生的，还是没有接入我工具放生的。
当然，这个应该是公司平台架构提供能力，后来他们也提供，但还是特殊场景没有覆盖到，所以我这个工具还可以做兜底。
（完）
