Git分支管理策略浅识

崔同学说逃避解决不了问题,那就勇敢面对。

两年前看过阮一峰老师的文章,认识了git分支管理策略,但那时项目代码是用SVN管理,接触git是因为github,github一直停留在单人单分支的阶段。后来换工作了必须用git,发现分支管理的强大之处,所以写一篇记录一下。

如何管理好git分支,国外的nvie发表了博客 a-successful-git-branching-model, 文章讲解了他是如何让自己的Git仓库保持整洁,阮一峰老师说的也是基于nvie的思想,推荐大家看完阮老师的文章,好好感悟感悟,然后在再来纠正一下我的理解,哈哈。

基本流程一张图足以说明;

一张图就够了

有人说这张图要横着看,我就得并没有什么影响,竖着看吧。下面就基于这张图,针对项目的实际情况,分析每一个分支的意义;

首页,这张图从上往下是时间轴,代表项目进展或者代码的迭代,这个没问题。

分支作用:

  • master分支
    master永远保持线上的稳定版本,不要在master上做开发;

  • develop分支
    develop是开发分支,一般一个工程只有一个develop分支,在多人多项目同时开发时,它是一条大河,一般不会直接在develop分支上写代码,都是从feature分支合并过来;

  • feature分支
    feature分支不是单独的一个分支,是一个个的分支,根据需求而定了,它们从develop分支check出来,是一条一条的小溪,我等小弟就是在这样的分支上coding,等一个功能开发的差不多了,develop分支就把它合并过去,这就是溪水流入大河的过程;等功能开发完毕,它们就没用了,可以当做垃圾清理掉;

  • release分支
    release分支是上线前的预发布分支,是临时分支,这个分支是从develop分支check而来,它是记录即将发版的代码,在release里可以做上线前的bug修改工作,但是不能再增加新的功能,此时develop分支可以继续开发新的功能,release最终还要合到master和develope分支,因为在release中有可能改过bug;

  • hotfixes分支
    hotfixes听着像是热修复,其实就是线上bug修改分支,他从master分支check代码,修改完再合并到master和develop分支,也是临时的分支,用完之后可以删掉;

推荐阅读更多精彩内容