Git是现在主流的版本控制工具，但是如何在软件开发过程中进行合理的分支管理，就见仁见智了。接下来，我将比较现有常见的分支机构管理方式与我在阿里时使用Aone的区别。GitFlow先看一张图。这张图来自Vincent在2010年提出的方案，完美诠释了GitFlow的工作模式。GitFlow作为一个已经提出了10多年的模型，还是比较简单的。只有两个稳定分支：develop和master。这两个分支不会被删除。master对应稳定版，develop是日常开发的稳定版。其他的feature、release、hotfix分支用完就删除。特性分支是大家的开发分支。如果有新的需求，应该基于develop拉出feature分支进行开发。发布分支是用于测试和发布的分支。修补程序用于紧急错误修复。开发流程如下：一开始我们创建了master分支，然后在master分支的基础上创建了develop分支。然后A和B基于某个版本的develop分支拉出代码进行开发。这些分支分别称为feature-A和feature。-B如果开发过程中需要修复bug并上线，则从master拉一个分支，命名为hotfix-xxx进行修复。修复完成后会合并到develop和master，然后hotfix分支会被删除，A代码会更快的推出。一步完成开发，将feature-A分支的代码合并到develop中，删除feature分支，然后我们在develop的基础上新建一个release-A分支进行测试。将代码合并到develop并转到release-A。测试完成并启动后，将代码合并到master和develop中，并删除release分支。这个时候B最终开发需求，然后合并到develop，然后新建一个release-B并合并到master和develop的过程，对于实际应用来说也比较简单。对于Mac，我们可以通过最方便的方式直接安装。首先安装GitFlow，brewinstallgit-flow-avh，安装完成后执行gitflowinit进行初始化。你可以输入你的master和develop分支名称，然后设置其他几个默认分支的前缀。然后执行gitflowfeaturestartirving进行初始化，创建一个feature分支用于开发。默认情况下，我们可以看到它是基于develop创建的。如果开发完成，我们执行命令gitflowfeaturefinishirving，那么我们的开发分支会自动合并到develop中，开发分支已经被删除了。然后我们的分支需要进行测试和发布。执行命令gitflowreleasestartirving。如果bug修复了，直接修复就可以了。测试完成后，执行命令gitflowreleasefinishirving，将代码合并到master和develop中，然后删除分支。原理和实现方法都说了，所以这个模型还是有同样的问题，就是更适合固定版本的迭代开发。难的。我今天对develop分支有10个需求，其中8个会上线，2个不会。代码也依赖顺序的顺序，所以我玩不好，但是提供了一个更好的规范和思路。GithubFlowGithubFlow可以说是非常简单了。2011年提出，主要针对GitFlow。它基于master分支拉取一个分支进行开发，然后在新分支进行开发，完成后提交pullrequest，验收后合并代码部署。图片来自Github官方PDF。详情请参考官方介绍。这种方式简单，但是在很多公司的业务开发过程中，一般会有开发、测试、预发布、生产等几个环境。如果没有强大的工具支持，我认为很难用这种简单的模型来实现管理。我觉得这种模式特别适合小团队，人少需求少，所以很容易。Trunk-Based模型提出的稍晚一些，是PaulHammant在2013年提出的，看图基本就能明白。这不是SVN模型吗？开发主干trunk，拉出新的分支进行开发部署，bug修复。使用过的方案我们之前用过一个方案，类似GitFlow，但是不依赖工具的支持，更多的是依赖团队自己的约定和规范。对于开发、测试、预发布和生产，分别使用分支develop、test、release和master。master分支是稳定分支，不能直接提交代码。同时，这些分支是固定的、唯一的分支。在第一个开发阶段，大家需要在master的基础上创建一个最新的特性开发分支，命名为feature/xxx。如果需要发布到开发环境，需要将大家的代码合并到develop中，只有develop分支才能发布开发环境。如果开发完成，需要测试的分支会被合并到test分支，还在开发阶段的会在develop。测试完成后，需要发布pre-release（当然叫grayscale或者uat），代码合并到release中发布。发布完成后，代码自动合并到master中。这样做的好处是首先规范了分支的开发和管理，这样在开发中不会出现太多的纠纷，而且在多个需求同时开发，不同时间上线的情况下也能很好的管理.缺点是一个有多个需求的项目需要开发上线，需要多次合并代码。从开发、测试到发布，代码必须一次合并，解决冲突。总的来说，这只是一个基于团队的规范，对环境和中间件CI/CD能力没有太多要求，可以很容易的应用到各个公司的场景中。阿里的解决方案阿里的解决方案基本上可以说是以上几种模式的结合，叫做AoneFlow，可能是因为这个工具本身就叫Aone。只有3个分支，master分支，function分支feature，release分支release。发布分支基本不需要开发人员参与管理。首先，分支的创建也是基于master。如果有需要，先创建一个特性分支。在部署之前，Aone会自动合并master代码，不用担心代码没有合并的问题。如果有冲突，需要手动解决，否则会自动生成一个新的分支进行部署，这个分支就是发布分支。阿里云霄的分支可以一直用来发布日常（理解为开发或测试环境的组合）、预发布和生产环境。如果同时开发多个需求有冲突，难道不需要合并代码吗？首先，Aone部署可以同时部署多个分支。如果选择部署多个功能分支，代码会自动合并。如果有冲突需要手动解决，也可以单独创建一个环境部署，互不影响。这个功能真的很棒。此规则对于登台和生产环境是相同的。在整个开发过程中，我们不需要去管理各个分支。我们只需要一个特性功能分支来发布每个环境。最终发布完成后，代码自动合并到master主分支（可选，或不合并）。整个模式看起来融合了各个模式的特点，参考了GitFlow分支的特点，但其他分支不需要开发者关注。分支开发是基于trunkmaster拉出来的，自动合并就像TrunkBased一样。最终，整个过程对于开发者来说就像是简化版的GithubFlow。文章参考：http://www.brofive.org/?p=2165https://mp.weixin.qq.com/s?__biz=MzAxNDU0MTE0OA==&mid=2661008528&idx=1&sn=748c3b5bdaa28c3c7b3c06614fd69d47&scene=21#wechat_uredirecthttps://clo.tencent.com/developer/article/1646937本文转载自微信公众号“爱小仙”，可通过以下二维码关注。转载本文请联系艾小仙公众号。
