git版本管理方式

工作到现在，遇到一些使用git做代码管理的仓库。个人觉得以下的分支管理方式比较合理。

git分支分类

首先git大概分【master】，【dev】，【test】，【stable（prepare）】等主要分支。还有【feature/***】，【hotfix/***】，【release/***】等分支以及【tag/***】标签。

【master】为线上环境，与线上环境一致

【dev】分支为开发环境，给开发使用的环境，会比较混乱

【test】分支为测试环境，主要给测试使用的环境，保证代码的干净

【stable（prepare）】分支为预生产环境，主要给上线测试使用的环境，保证代码的干净

【feature/***】 需求分支，建议以jira，redmine，issue的单号作为分支名，或者有代表性的名称，根据名称可以追溯开分支的原由。

【hotfix/***】 bug修复分支，建议以jira，redmine，issue的单号作为分支名，或者有代表性的名称，根据名称可以追溯开分支的原由。

【release/***】 发布分支，建议以版本号未分支名称，主要作用是适应多人并行开发。

【master】，【dev】，【test】，【stable（prepare）】等主要分支，理论上不允许直接修改，除非在合并代码时有冲突要解决，可以手动修改。

【feature/***】，【hotfix/***】，【release/***】 ，理论上是从master分支中切出来的。

【tag/***】标签是作为历史发版的一个备份，可以快速的回滚值上次版本。

开发-测试-上线过程

当有需求来时，根据任务拆分获取jira，redmine，issue的单号，从【master】中切出各个【feature/*** 】。

开发在本地测试通过自己的【feature/***】 需求分支后，合并至【dev】分支再次测试。dev测试通过后，【feature/***】 需求分支合并至【test】分支。

当需要上线时，从【master】切一个【release/***】分支，名字用上线的版本号。将要需要上线的【feature/***】，【hotfix/***】，合并到【release/***】分支。在将【release/***】分支合并到【stable（prepare）】分支，测试进行完整测试。

测试通过后，就可以将【release/***】准备上线。

上线前将【master】切一个【tag/***】，名称为当前的版本号，然后将【release/***】分支合并到【master】。

为什么这么玩

因为在开发过程中，可能由于一些外部因素，导致整批需求中有部分功能不能上或者需要配合其他团队单独先上某个功能，所以我们需要将功能拆分细，作为多个【feature/***】来开发。当需要上线时，就能灵活组合代码上线。而【release/***】作为一次发布，能够比较规整的管理上线的代码。

标准的gitflow流程不适合国内的开发环境，git适合多人并行开发多个版本。

标准的gitflow中，【release/***】是从【dev】切的，但现实情况【dev】的内容很可能是个远超【master】，因为你的任务总是做完了来新的，总是在不断往前走的，但是上线的节奏可能由于各个因素而延迟。如果从【dev】切，就会将不需要上的代码无形中合到了【master】.