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继续开发。

多人合作开发

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

原文地址:https://www.cnblogs.com/webARM/p/7808380.html