git 分支管理方案

现有一般的公司项目均使用git（大多数是gitLab）管理。

开发组

我们的项目都要建立在 开发组的名下 （git.xxcompany.com/xxgroup），除需要公司内部开源的项目，都必须设置为 私有（private） ，只对团队内部开源。

ssh key

使用前建议大家在本地用自己的公司邮箱配置ssh key，并讲ssh key 添加到git系统的个人页，（方法如下： https://segmentfault.com/a/1190000002645623） 
虽然有一些公司的git 仓库不使用ssh也能正常的clone，但考虑到后续的一些内部工具的权限校验，建议配置ssh key

分支管理

因为前端开发不走终端的发版模式，可以随时上线，因此分支管理显得十分重要。 
默认主线为master （永远与线上代码一致），我们采用现在大多数公司使用的feature开发模式： 
1、接到需求后以线上（master）为基准，创建feature 分支命名规则： feature_xxx。 
以xxx需求为例

$ git checkout master
$ git checkout -b feature_xxx

2、开发阶段，完成需求 
3、提测前，拿到最新的master分支合并到feature_xxx,将feature_xxx的代码发到测试环境。

$ git checkout master
$ git pull
$ git checkout feature_xxx
$ git merge master

4、每一轮提测包括集成测试和上线前重复3，保证我们的feature兼容线上。 
5、将feature的代码上线，即：以feature_xxx为基准打一个tag，将tag上线。 
6、线上回测没有问题后，将feature_xxx合入master，然后除feature_xxx

$ git checkout master
$ git merge feature_xxx
$ git branch -D feature_xxx
$ git push origin :feature_xxx  //(注意“:”后面没有空格)

这样做的原因是永远以一个 正确的基准 开始新需求的开发，也永远将 正确的分支 合并到主线可以形成一个开发 闭环 ，这种方法要比commit打分支更便于理解和操作。可以应对 多人多需求并发场景

最主要的是应对在开发一个长期需求（feature_long）的过程中，插入另一个短期需求或线上bug（feature_short），长线需求可以在短期需求上线后（短期需求feature_short 合并merge 进master后，删除feature_short），将master 合并进feature_long，然后feature_long继续开发。

多人合作开发

我们会遇到对人开发同一个需求，比如前后端两个人，请在 开发前约定 分支名，并由一个人创建好。