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操作

Git分支模型(GitFlow)_第1张图片

你可能感兴趣的:(Git)