理论是灰色的，生命之树常青。简介任何一家公司，甚至是一个小型组织，只要有写代码的地方，就有代码版本管理的归宿。初入职场，总会遇到第一个绊脚石的git管理流程，但是每个公司似乎都有自己的Git管理流程，如果我们能够掌握常用的git分支管理模式，那么不管是哪种git我们遇到的管理流程，只是这些管理模式的推导和简化。背景目前笔者所在的前端部门，技术栈以React&RN为主，Vue为辅，也就是说React和Vue双栈并存。可以说研发环境比较复杂，运维部门也制定了相应的git管理模型，但是也比较笼统，所以如何制定适合前端部门的git管理模型尤为重要important，又不能和运维部门的管理模式冲突，于是就有了这篇文章。GitFlow是著名大亨VincentDriessen在文章《A successful Git branching model》中提出的一种影响深远的git代码管理模式，至今仍被许多大中型企业所采用。以下是他提出的流程图：优点：分支管理严格，代码Merge清晰，适合中大型团队应用。缺点：过多的分支过程也是一个缺点。GitHubFlowGitHub创建于2011年，遵循以下6条原则：master分支始终准备好部署和发布需要基于master分支添加，并创建语义分支定期将本地分支推送到master处远端，需要提交PRPR。一旦codereview无误，就可以合并到mastermaster了。一旦您收到合并请求，您可以立即部署和发布它。并且符合人的思维逻辑，适用于持续发布场景缺点：GitLabFlow不适用于多版本产品线。GitLab在2014年提出了11条最佳实践。更多请点击这里。与GitHub相比，它增加了一个环境分支，代码必须从上游（master）开发到下游（staging），并提出了相应的持续发布和版本发布指南，下面是它的大体流程图：优点：gitcommit历史更清晰、简洁、易读缺点：对开发者的能力提出了更高的要求。产品线多时，TrunkBased研发团队只在master分支开发功能。顾名思义，读分支不接收任何新的代码合并，并在只读分支上进行修改；当开发人员比较多的时候，可以使用可伸缩版本，增加一个功能分支，但是功能分支如果不超过两三天就必须合并到master分支，大致流程图如下：优点：简单明了，单兵实战最佳选择，适合后期维护超稳定的项目缺点：不适用于多版本共存项目2017年提出的OneFlowAdamRuka，简单易懂是Git的简化版流动。除了develop分支和master分支的最新发布，其余都是临时分支。开发完成后，可以删除临时分支。具体细节可以在这里找到。以下是它的大致流程图：优点：单一版本首选，gitcommithistory的简单介绍清晰易读缺点：不适合持续交付或持续部署项目，也不适合多版本共存项目AoneFlowis阿里巴巴技术专家林凡基于TrunkBased和GitFlow提出的一个新的改进，其主要分为三种分支：trunk分支、feature分支和release分支，并提出了三个基本的指导方针：trunk创建一个feature分支并做不允许合并回主干分支合并Feature分支，形成一个release分支发布到线上正式环境，合并对应的release分支到trunk，给trunk添加tag，删除release分支关联的feature分支。下面是它的大致流程图：优点：灵活易上手，多种进阶玩法往往可以通过组合分支方案实现呢？这里做了一个思维导图，具体如下：参考：[1]a-successful-git-branching-model[2]githubflow[3]what-are-gitlab-flow-best-practices[4]oneflow-a-git-branching-model-and-workflow[5]在阿里，我们如何管理代码分支？
