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分支又健康的发展起来啦

使用图解

看到上面的图，有些小伙伴会问，为什么上线后要删除本地分支？那是因为，一个功能分支或者修复分支的生命周期就在新建的那一刻到上线，他的使命就完成了，它来自于master，最后又回到了master。那么如果上线之后，feature 还出 bug 呢？那就从master新建一个 bugfix 分支，生命周期和feature一样，用于修复bug。

关于tag

也有小伙伴会想，为什么要用tag呢，master不是有完整的版本信息吗，是的，也正是因为太完整，所以才没法看，因为我们需要一个清晰的每次发版的稳定的版本列表，出问题或者回退时我可以第一时间知道上一个或者某一个已上线的稳定版本是哪一个，而不是在一堆稳定或不稳定的版本里面寻找。

以上操作其实并不需要很强的git技能，主要用到的git命令

• 切换分支：git checkout master
• 新建分支：git checkout -b feature
• 删除分支：git branch -D feature
• 合并代码：git merge feature
• 推送代码：git push origin feature
• 拉取代码：git pull origin feature
• 新建标签：git tag -a v1.0.0 -m 'feature A'