Git分支模型（GitFlow）

Git分支模型（GitFlow）

分支合并建议

merge --no-ff

使用–no-ff合并时，在删除develop分支之后，该分支的合并信息仍然被保留，在以后的代码分析中可以便捷的查看到历史信息，而fast forward方式则无法辨识代码的合并信息

master分支（默认主分支）

master分支的HEAD节点始终处于“准备好进行生产的状态”，即master分支的HEAD节点所指向的版本始终是可以用于生产环境的正式版本。

当其他分支的代码版本合并到master分支时（随后打上版本标签），通常意味着一个新的正式版本已经发布

develop分支（主分支、整合分支）

其HEAD节点总是指向下一个待发布版本的最新变化

develop分支的版本变更通常来源于***辅助分支***的合并

当develop分支达到某一稳定点，可进行新版本的发布时，develop分支上的所有变更应该被合并到master分支并打上tag标签

feature-*分支（辅助分支、需求分支）

分支来源：develop分支

分支去向：develop分支

需求分支最终会被合并到develop分支中作为下一个待发布版本的功能之一，或者由于该需求无法实现从而被抛弃

release-*分支（辅助分支、发布分支）

分支来源：develop分支

分支去向：develop分支和master分支

发布分支用于辅助新版本（生产环境）发布的准备工作，例如小bug的修复，或者版本号的修改等等

当从develop分支中创建发布分支以后，develop分支便可以进行新版本之后需求的研发工作，从而既不会影响到最新的研发进度，也不会影响到新版本的发布

hotfix-*分支（辅助分支、修复分支）

分支来源：master分支

分支去向：develop分支和master分支

修复分支用于正式版本的紧急修复，在紧急修复完成以后必须同时被合并到master分支和develop分支，最后进行tag操作