Git 分支在团队中的一种简易管理方式

我们在个人项目上使用 git 往往比较随心随意，下面记录一种团队开发时比较稳妥而且不需要太高超的git 技术的管理方式。

首先来模拟个场景

假设我们目前有一个项目 A

根据公司提供的开发资源，我们可以为项目分出几个分支，分别是dev、test、pre、master，这是一个项目迭代周期比较周全的方案。少的可能只有本地开发环境和线上环境，稍微好点的可能也只多一个线上测试环境。

• dev —— 开发分支，负责项目开发期的分支，具有最新的正在开发的功能

• test —— 测试分支，负责项目测试期的分支，具有最新的已开发好的功能

• pre —— 预发布分支（灰度分支），负责最终测试阶段的分支，该分支测试通过后即可等待发布，具有与生产环境一样的数据及相对稳定的功能。

• master —— 生产分支，master分支最新版本应该是稳定的，可提供线上使用的代码，同时也是 tag 的来源。

• tag —— tag 是每一个生产环境上线时的版本标签，通过tag，我们可以清晰的看到每一个已发布过的稳定版本

假设现在需要开发功能 feature，那么我们从master分支新建一个 feature 分支

• feature —— 功能分支，每一个功能开发时的分支，功能开发完合并到dev分支进行开发联调

这时可能会有小伙伴问，在feature分支开发完不是可以直接联调吗，为什么还要合到dev才去联调呢，这是因为有时可能会有多个功能同时开发，有时如果两个功能互补干扰，有可能会谁先做完谁先上，这是就需要分开 feature1 和 feature2 分支，开发完后再统一合并到dev环境，联调无大问题即可提测，谁先测好谁先上pre环境，这些都是血淋淋的经验教训。所以为了保险起见，建议不同功能不同分支，当然也可以团队协商好把大版本拆小版本然后按版本开发。

这么些个分支的关系

所有这些分支，都从 master 主分支来，所以其中一个分支崩了也无所谓，那就删掉分支，从master分支重新建一个分支，然后把相应的功能分支合并上去即可。比如test分支不小心合并坏了（骚操作导致大量冲突），那就删掉test分支，
从master分支重新拉一个test分支，并把pre环境有的且生产环境没有功能分支合并上去，并且把以通过dev环境的功能分支也合并上，这时test分支又健康的发展起来啦

使用图解