Git工作流
Gitflow模式
特点：使用发布分支、特性分支、bug 修复分支以及预发布分支。主要分支包括 master、develop、feature、release、hotfix。
由于Gitflow模式涉及到了很多不同的分支名称，所以这里我打算用一系列的图来和大家介绍下这些分支的概念。
master/feature/develop 分支
首先我们的master分支一定是最终发布上线使用的分支代码，所有的需求开发，都需要通过master分支中去checkout出来，生成对应的feature分支。
当同一个项目涉及到多个分支改动的时候，就难免会需要进行分支合并后再发布到开发环境的情况发生。
这时候可以通过利用新增一条develop分支的做法，将同一个项目的多条feature分支进行merge后，再发布到开发环境中。如下图所示：
图片
采用新增develop分支的模式可以解决开发环境多分支合并部署的问题了。那么release分支又是做什么的呢？
release 分支
开发环境一般主要是给开发调试程序时候使用的，而如果要从开发状态转变为测试状态的话，需要的是一个能够长期保障稳定性和逻辑顺畅性的代码环境，这个时候建议可以通过新增一套release分支来进行测试环境的代码管理。如下图所示：
图片
从图中可以看到，不同开发负责的feature分支，在进行提测的时候都需要往相同的release分支进行合并。
当release分支上的代码通过测试回归之后，我们可以视作此时的release分支的代码是属于可合并到master的状态。因此一般这个时候会将release分支的代码分别合并到master和develop分支上，以此来保证准确性。同时此时可以将master分支的代码发布到预发环境进行最后的回归验证。
hotfix分支
其实hotfix分支在使用上可以说和feature分支基本一样，它的定位是：对master分支上的bug进行修复。hotfix分支也是需要从master分支中checkout出来，然后进行修改，最后合并到develop/release分支上进行回归验证，最后并入到master分支进行发布。在一定程度上，hotfix属于feature分支的一种特殊类型。
图片
git-flow模式的痛点
其实用久了git-flow模式后，你会很容易发现，这种模式对于分支的领域划分是非常清晰的。例如develop分支专门用于开发，release分支专门用于测试，hotfix分支专门用于打补丁。
但是随着迭代的增加，这些分支的管理是一件比较容易出错的事情。例如：手误将feature分支合并到release分支。hotfix分支忘记合并到develop分支等等。release分支包含了太多feature分支代码，其中部分feature分支延迟上线导致release分支代码需要移除部分commit后再合并到master分支。
这是我认为的git-flow模式的一大痛点。虽然它强调于对分支的标准化管理，但是实际落地在团队使用的时候，很多毛病都会体现出来。
Github flow模式
特点：Github flow 是Git flow的简化版，专门配合"持续发布"。它是 Github.com 使用的工作流程。
步骤
- 拉取最新的代码：git pull origin master
- 创建新的功能分支：git checkout -b feature-branch master
- 开发功能：在新创建的分支上进行修改、提交和测试
- 合并到master：git checkout master -> git merge feature-branch
- 推送到中央存储库：git push origin master
图片
这种模式比较适合于合作人数较少的场景中进行快速开发和迭代。在实际使用中，团队leader只需要保障master分支的“干净”即可。各个团队成员的特性分支代码独立。但是如果是涉及到需要多人合作对同一个项目进行并行开发，需要多次进行代码合并的话，这种开发模式就很痛苦。
Gitlab flow 模式
采用Github flow模式虽然说很灵活，但是它有个强制的要求就是master分支的代码一定要和生产环境的代码对齐。
但是在一些特殊的应用场景中，例如IOS开发（需要有审核时间），某些SAAS平台的一些特殊功能开发，在那类场景中经常是会出现代码合并到master，但是需要延迟一段时间才发布到生产环境。
Gitlab flow模式就是在上述的Github flow模式中进行的衍生，增加了一个所谓的pre-production分支，用于作为待发布状态的环境分支，它的代码合并流程如下所示：
图片
处于pre-production分支的代码是经过验证可以合并到生产环境的代码，而production分支的代码则是生产正在运行中的代码。这个由pre-production到production分支的合并动作，需要由CICD平台自动化来实现。
说实话，我在实际工作中主要还是用的Github flow模式，Gitlab flow模式个人接触得并不多。
我的看法
早些年工作的时候，经历过一些多人合作修改同一个项目的开发工作。那会团队采用的是git flow的工作流，当时总是会出现合并冲突，分支错乱，git命令使用错误导致代码丢失等问题。
但是随着这些年微服务的普及，很多公司其实都已经陆续意识到了大单体架构的痛点，于是也按照领域划分拆解为了多个微服务。
实际上，随着微服务粒度在不断降低，每个开发所负责的领域也开始进行了划分。如果服务划分合理，其实一个项目基本上主需要一个 主程 （core developer，有些公司习惯叫项目owner）去维护基本就OK了。如果是这种模式下进行代码开发的话，其实采用经典的 github flow 或者 gitlab flow 模式进行开发即可满足。
我认为，随着日后的发展，业内技术的走向一定是将事情由繁化简。随着企业内部的CICD技术体系完善，git flow这种笨重的模式也会渐渐被摒弃，github flow/gitlab flow 这种灵活轻便的模式会越来越受人追崇。
对于git工作流模式来说，我认为没有绝对完美的方案，只能说结合当前所遇到的业务场景来灵活制定，见招拆招。
