在做项目的时候，不管是多人协作，还是单兵作战，都需要用版本管理工具对项目进行管理。市面上的版本管理工具很多，比如有我们比较熟悉的 svn 和 git。它们的优缺点，我们这边不做讨论，大家可以网上搜索。本文主要讨论 git 的一个显著优点：版本的分支管理。下面介绍的是一种实践中证明运行比较良好的版本分支管理方式。
主分支
在实际开发中，一个项目的仓库主要有两个主分支：master 与 develop 分支。这个两个分支伴随着整个项目周期。且不允许直接 push 到这两个分支上。
master：创建 git 仓库时自动生成的原始分支。
这个分支代表项目处于可发布的状态。其他无关代码不得随便往 master 上合并。只有计划发布的版本功能在 develop 分支上全部完成，而且测试通过后才会合并到 master 上。develop：基于 master 分支创建，与 master 分支平行，为开发的整合分支。
主要来源为各程序员的开发功能分支的合并（Feature branches，下面会讲到）。
功能分支
除了上面的主分支外，我们在开发中还会用到其他功能分支，以帮助团队成员之间进行并行开发，简化功能跟踪，为生产发布做准备并协助快速解决生产中的实际问题。与主分支不同，这些分支的生命周期总是有限的，因为它们被合并后就会被删除。
Feature branches：功能分支。程序员在开发每个功能的时候都需要在各自的功能分支上开发。
每次开发新功能都必须从 develop 分支创建，开发完成合并回到 develop 分支后删除。分支命名可以是除 master、develop、release-*、hotfix-* 外的任何内容，建议使用 feature-*（如 feature-register，代表用户注册的开发分支）。Release branches：预发布分支。在 master 要发布正式版本之前（即合并到 master 分支之前），我们可能需要有一个预发布的版本进行测试。
测试过程中如有小调整（比如调整位置、宽度，修改文案等不会引入新 bug），直接在该分支上修改。如果出现大 bug 必须通过创建 feature 分支，走正常流程。如果是一些无关紧要的小 bug，可以推迟到下个版本更新修复。
预发布分支是基于 develop 分支创建，预发布结束以后，如有修改必须合并到 develop 和 master 分支。最后删除该分支。分支命名使用 release-*（如 release-0.1，即 release-预发布版本号）。正式发布时，一般会基于 master 分支创建一个 tag，命名为 tag-*（如 tag-0.1，即 tag-线上版本号）Hotfix branches：线上 bug 修复分支。项目发布上线后，出现的 bug，在这个分支上修复。
该分支基于线上版本对应的 master 分支（或 tag）创建，修复完 bug，必须合并到 develop 和 master 分支。最后删除该分支。分支命名使用 fixbug-*（如 fixbug-0.1，即 fixbug-线上版本号）。
总结图
参考文章：https://nvie.com/posts/a-successful-git-branching-model/
版权属于：瞭月
本文链接：https://www.lervor.com/archives/123/
版权声明：本文为瞭月原创文章，转载请附上原文出处链接和本声明。