Git 分支管理前言多人协作，项目复杂到一定程度，简单的 dev、test 两种分支，无法满足开发需要。而且从项目角度

多人协作，项目复杂到一定程度，简单的 dev、test 两种分支，无法满足开发需要。而且从项目角度来说，项目始终从0到1，从简单走向复杂。如果一开始，不去做规范，等后面复杂到一定程度，更加难以开发和纠正。

就目前H5以及小程序都是这种分支管理，会出现测试环境（dev）没有问题，上生产（test）时发现问题。尽管及时处理，但这也如同定时炸弹一样，不知道什么时候就爆了。

既然目前的分支管理存在这样大的隐患，那么大厂是如何管理自己的分支呢？如何保证自己的代码正常、完整的上线呢？

Master 分支：即保存已发布到线上的代码。这个分支只能从其他分支合并，不能直接在这个分支修改代码。
Develop 分支：主开发分支。基于 Master 分支创建。用于开发和第一阶段测试（即初次提测）。包含所有下一个准备发生产的代码。
Release 分支：即将上线分支。基于 Develop 分支创建。在 Develop 分支提测后，Bug 改的差不多了，版本趋于稳定后，基于当前 Develop 分支创建一个 Release 分支，完成所有的验收后，即可上线该分支。上线完后，需要将该 Release 分支合并到 Master 和 Develop 。在合并到 Master 分支时，需要打一个 Tag 。
Feature 分支：开发分支。基于 Develop 分支创建。用于多人开发同一个迭代，分别开发不同功能。开发完成后，合入 Develop 分支进入下一个 Release 分支。在多人协作开发时，应该及时更新拉取最新的 Develop 代码。
Hotfixes 分支：当我们发现线上 Bug，需要紧急修复时。这是，我们就可以基于 Master 创建一个 Hotfix 分支。在这个 Hotfix 分支修复完 bug 后，直接发布这个 Hotfix 到线上即可。发布完成后，还应该将这个 Hotfix 分支的代码合回 Master 和 Develop 分支。这样这个 Hotfix 分支的改动就会进入下一个 Release。

Master/Develop 分支：所有在 Master 分支上的合并操作都应该打上 Tag 。Develop 基于 Master 分支创建。
Release 分支：Release 分支基于 Develop 分支创建。我们可以在这个 Release 分支上测试，修改 Bug 等。一旦创建完 Release 分支之后，不要从 Develop 分支合并新的改动到 Release 分支。需要修改应该直接在这条 Release 分支做操作。所以创建 Release 分支的时机不宜过早，应该等版本趋于稳定后创建。发布 Release 分支时，合并 Release 分支到 Master 和 Develop，同时在Master分支打上 Tag 记住版本号，然后就可以删除这个分支了。打 Tag 可以标记每个版本，后续想用哪个版本都能快速提取。
Feature 分支：开发分支，功能开发完成后合入 Develop 分支提测。合并完分支后一般会删点这个 Feature 分支。
Hotfix 分支：紧急修复线上 Bug。基于 Master 创建。修复完成后上线该 Hotfix 分支。并合回 Master 和 Develop 分支。同时在 Master 上打一个 Tag。