Git分支GitFlow开发规范

规范化管理代码库分支有助于版本库在演进过程中始终保持简洁，主干结构清晰。各个分支各司其职，有利于后续的维护更新，避免版本发布带来的混乱问题。

参阅资料

《A successful Git branching model》

《Git官方文档--Branching Workflows》

以下为Git分支开发规范的简单总结

分支结构

主要分支

master

• 主分支，用于部署生产环境的分支，需确保master分支稳定性
• master分支存储了正式发布的历史
• 属于只读唯一分支，只能从其它分支（如develop，hotfix）合并，不能直接在此修改
• 所有向master分支的Push推送都应当打TAG标签做记录,方便追溯

develop

• 开发分支，基于master分支检出的平行分支
• develop分支始终保持最新完成以及bug修复后的代码
• 属于只读唯一分支，只能从master以外的分支（如feature，hotfix）合并，不能直接在此修改

下为master和develop平行分支示意图：

支持分支

feature（官方亦称topic）

• 功能分支，基于develop分支检出，用于新功能的开发
• feature分支可同时存在多个，用于团队中多个功能同时开发
• 命名规则： feature/*，如feature/shopping_cart，feature/user_login
• 属于临时分支，最终会被合并回develop（作为新版本功能）或丢弃（放弃功能），最后可选删除
• feature通常仅存在于开发人员存储库中(本地库)，而不存在于远程origin

下为feature分支应用示意图：

release

• 发布分支，基于develop分支检出，用于准备发布新阶段版本
• 用于Bug测试及修复，文档生成和其它面向发布任务
• 属于临时分支，最终会先被合并到master（发布新版本），打TAG标签，再被合并到develop，最后可选删除
• 命名规则：推荐为release-*或release/*，如release-1.0

下为release分支应用示意图：

hotfix

• 补丁分支，基于master分支检出，用于对线上发布的版本进行BUG修复
• 属于临时分支，最终会先被合并到master（发布新版本，亦称修复版本），打TAG标签，再被合并到develop，可选删除
• 命名规则：推荐为hotfix-*或hotfix/*，如hotfix-1.0.1

下为hotfix分支应用示意图：

最后

推荐使用对Git Flow很好应用的图形工具SourceTree，可以帮助我们很好的理解和管理git分支。

下图为SourceTree工作流默认配置：