Git分支管理策略推荐

推荐使用gitflow演化的分支管理策略。（关于分支策略选取详细解说请参考：分支策略）

git-flow

master分支： 长期可发布分支，uat验收测试将从该分支拉取代码。修复问题需要新启hotfix_xxx进行热修复进行PR。

release分支： 迭代可上线分支，st 测试环境将从该分支拉取代码。迭代任务完成后，将重组一个release分支来进行质量打磨。该分支严格上不再接受新特性，只做bugfix_xxx等内容

develop分支：最新的开发分支，dev集成环境从该分支拉取代码。所有新特性feature_xxx和最新迭代任务从该分支进行开发。（暂且假定我们可以使用自己的开发分支也可作为特性分支 如dev_myself）

注意：

所以使用gitflow命令创建分支时候，应当先设置下前缀，注意将“/”替换为“”，如默认前缀“feature/”改为“feature”形式

2 推荐安装sourceTree管理工具，有gitflow可视化管理界面，可以帮助理解gitflow命令，但不一定用这个管理，进行操作还是建议使用命令行模式

3 推荐使用git merge --no-ff feature_xx命令

特性分支feature_xx或dev_xxx开发完一个完整特性，回归到develop分支时候；如果不添加–no-ff ，默认是fast-forword方式。同理dev_xxx也建议如此。

why？使用–no-ff 能够将自己开发的一个特性整体打包提交，使得我们develop分支提交的节点更为清晰，并且方便后续release_xx进行特性重组；

4 该模式下如何进行线上修复bug？hotfix_xx

（1）切换到主发布分支 git checkout master

（2）创建热修复分支git checkout -b hotfix_1544

（3）推到远程 git push origin hotfix_1544

（4）远程进行PR合并到master,develop

注意第4步，不在合并到release_xx分支。

因为release_v2表示迭代2的预发布内容，最终走向还是要并向master主发布分支，这样hotfix_1544修复的内容也会涵盖在我们下次预发布的内容中，没必要进行这个合并。

如果进行cherry-pick到release_v2中，在进行合并到master还会产生额外的冲突。因此hotfix_1544需要回归到develop，下个迭代进入st的release_v3也将包含我们热修复的内容。