最近有人问我，不知道怎么维护Android端Git的分支模型与代码，恰好之前和同事讨论过git代码的维护，并在公司项目的实际应用过，证明这套方案是完全可行的，在此特地做一下相关的笔记。git命令在这里就不提了，这里只是一套维护代码的的思路。
实际上，相关的文章也是有蛮多的，最主要的还是这篇国外的文章A successful Git branching model 文章是10年的，但是里面的思想是一脉相承下来的。这篇英文文章，也有人进行了翻译和理解。详见GIT分支管理是一门艺术。其中最主要的还是文章里的这张图。
有些人不喜欢看这种英文和生搬硬套的翻译和可以看下面图二的方案
这里，master的每个tag代表这每个稳定版的分支出现。上图git模型的中心思想是：1.有两个核心master,release的稳定分支贯穿整个项目 2.master永远是最稳定的代码。
根据这中思路以及当时我们公司的实际情况， 我们讨论后稍微做了一些改变，也将部分分支和解释通俗具体化了一些，做成了如下图的效果，方便公司内部快速的交流和学习。图比较粗劣，使用微软自带的画图工具画的，但是核心思想已经得到了完全的体现。
图二中 master分支与图一没有多大差别，主要是维护着最稳定的，可以随时打包的代码，从而随时随地可以打出目前为止最稳定的包，这种方式让master分支结合自动化打包脚本，每当master分支一旦获得了合并代码的权限，被允许新版本代码合并上去，自动打包就会执行脚本，从而生成相应的渠道包，这样大大方便了程序员的操作，使流程自动化程度大大提高。当出现重大问题，需要回退到上一版本时候，直接在master分支上执行自动打包命令，指定相对的tag。这种思路和图一是一脉相承的。
上图中release分支承担的是提交测试的包，当develop的版本开发结束时候，就将代码合并到release，每当新的版本开发开始，就从release拉取分支代码到develop上进行开发。按照正常逻辑的话，只要不是测试阶段release的代码和master应该是一致的。
上图中develop分支的的功能跟传统的develop分支差不多，主要在开发阶段每个开发人员进行代码的拉取和合并，另外新功能技术储备开发，也可以在release中或者这里的下拉结点直接拉取代码进行技术储备的开发，大家看图应该就很容易理解了，这里没必要赘述。
上图中关于紧急修复。大家发现有一条土黄色的线和一条灰色的线，一般情况下是走土黄色的流程，只有当release恰好也处测试阶段，而测试没完成，此时恰好HotFix发生， 这时候就需要走蓝线而不是土黄色的线了，因为这时候走传统的土黄色的线，release代码是没有测试完的，这种情况非常少的几率发生。另外还有一条灰色的虚线，实际上是可选的，有些人习惯HotFix修复后直接merge到正在开发的分支上， 有些人不习惯在开发的时候merge， 觉得这样会影响正常开发，喜欢开发完毕之后，再merge，这个视个人情况而定。
关于git分支的模型大致就如上图，其实大家也可以灵活的视自己公司情况而定，但是主体思想基本就是这样，不会有太大的变化了。如果有任何问题，欢迎大家前来交流，指正。
以上为原创，转载请标明出处。
