前言：有收获的话请加颗小星星 ，没有收获的话可以 反对 没有帮助 举报三连
最近由于一个同事git分支使用不当，影响了其他同事的开发，而且把一些不是本版本的内容发到了线上，还好没有造成线上bug，虚惊一场。所以我在公司对他们进行了一个分享，同时分享给大家。
说起git工作流，就不得不提起三种市面上的三种常见的工作流，Git Flow、GitHub Flow 以及 GitLab Flow。
1、Git Flow
诞生最早，且使用最为广泛的工作流。他的特点是会有两个长期存在的分支，分别是主分支master和开发分支develop，还会有三个临时分支，功能分支（feature branch）、修复分支（hotfix branch）、预发分支（release branch）。
主分支master对应线上版本，每次开发分支合并到主分支发版后，会打一个tag。
develop分支对应开发版本，新版本开发从develop分支为起点建立一个feature分支，功能开发完毕再合并到develop分支，合并时建议使用--no-off参数。
feature分支对应开发新功能，hotfix分支对应修复线上bug，release分支对应发布前功能验收。
2、GitHub Flow
如果你参与了开源项目并贡献代码的话，这个你肯定不会陌生。github拥有自己独特的方式，fork、pull request（简称PR）、issue tracking，首先它会有一个远程仓库(remote repository)，然后各自fork到自己的仓库，开发完成后PR到远程仓库，如果有疑问可以提issue，负责人审核通过之后合并进master。它的核心思想就是PR和审核，审核过程是天然的code review过程，可以帮助开发者减少bug，从而使代码库更稳健。如果是不是公司开发，我更偏向于这种。
3、GitLab Flow
GitLab Flow有一个最主要的原则：上游优先（upsteam first），只存在一个主分支master，该分支是所有其它分支的上游，所以发布顺序是很重要的，比如开发环境是master，预发布环境是pre-production，生产环境是production，如果生产环境发送错误，此时需要先拉出一个hotfix分支，改完之后合并到master，验收完之后合并到pre-production，再次验收后合并到production，除非是紧急情况，否则不能跳过以上步骤。
分享完成之后我问了他们一个问题，请问你们认为最佳实践是怎么样的？
同事A说GitLab Flow，我对他说答对一半，经过我多年的实践，以下是我得出的最佳实践。
开发环境：production 预发布环境：pre-production 主分支：master 测试环境：test 本地环境：dev-feature-v1.0.0 bug分支：hotfix
正常开发流程：master->dev-feature-v1.0.0->test->master->pre-production->production
一般修复bug流程：master->hotfix->test->master->pre-production->production
紧急修复bug流程：master->hotfix->master->production