A successful Git branching model的理解

文章末尾的这张图，很多人都看过，我在好多年前就看过，一直没有理解，觉得要同时维护这么多的分支，基本上就不用做事了，所以在团队中，一直都是使用master分支一撸到底，还好这些年没有出大问题。

今天临下班的时候，有点闲时间，再次翻到这张图，仔细看了20来分钟，恍然大悟，原来这个模型简单又好用，以前之所以觉得复杂，一方面是我看书不够细心，另外一方面，也是网上的绝大部分文章，根本就没有讲清楚这张图的重点。

这张图，只要注意竖线的颜色，黑色是分支存在的生命阶段，浅灰色是相反。所以，日常开发，在git remote server上长期存在的分支，就两个“master”和“develop”。

master分支：作为稳定的产品发布后的分支，平时改动很少，tag也只打在这个分支上。

develop分支：就是团队日常开发使用的分支，代码提交频繁，基本上其它的分支，都是从develop分支上创建的，并且其它分支上的修改，都要合并到develop分支上。

至于其它的分支，都是短期存在的临时分支，从右到左把他们的功用听我简单一说就明白了。

hotfixes分支：这个分支用于已经正式发布的生产版本（也就是master上打了tag）出现bug的时候，从master分支的某个tag（一般是最新的一个，除非同时维护多个发布版本）里，branch一个分支，一般起名hotfixNN（NN代表两位数字），用于修复bug。当bug修复后，就合并到master和dev分支，并且在master分支上打上新的tag，hotfixes生命周期结束，就可以删除了。这个分支存在时间较短，一般情况下不推送到remote。

release分支：当开发到一定时间后，准备发布新版本，从develop分支branch一个新的分支，取名release，或者是1.0这样的版本号，接下来这个分支只进行bug修复，不再从别的分支合并新特性，并且每修复一个bug，就要合并到develop分支。等到bug修复得差不多了，可以发布新版了，就把release分支合并到master和develop，并在master分支上打上tag，release分支生命周期结束，删除。这个分支一般会存在一段时间，也需要团队一起修复多个bug，所以推送到remote。

feature分支：这类分支是很频繁的从develop分支上branch出来，完成开发和本地测试后，又频繁的合并到develop。这类分支不论存在时间长短，一般只存在开发人员的本地，不推送到remote。在某些情况下，当需求变更,某些特性不需要了时,分支直接就放弃删除了。

以后的团队协作，就用这个模型了。