Page tree
Skip to end of metadata
Go to start of metadata

模型

目前遵循以下规则:

  1. 所有功能都在feature branches里面开发,每个feature建立一个分支。
  2. 单元测试在feature branch上做
  3. 单元测试后在gitlab上面发merge request(feature->develop)
  4. 值班同学review通过后accept并merge回develop
  5. sprint结束后代码合并到release并提测,测试跟bug修复也在release上进行,修复的bug及时合并回develop
  6. 测试通过后在master上打好标签,并发布到生产环境,打上版本标签
  7. 线上的bug在master上面创建hot fix分支修正,测试通过后同时merge回master和develop
  8. 原则上,分支合并的方向为feature -> develop -> master,不允许反向合并 **

说明:

  1. feature分支特点:仅包含单一功能,未合并其他功能集
  2. develop分支特点:已合并功能集,不稳定
  3. master分支特点:已合并功能集
  4. ** 当我自己的分支feature1需要别人的分支feature2上代码的时候,常规的做法是,两个分支都合并到develop分支。当某些情况下,我希望自己的feature分支能包含别的分支上的代码,但又不希望我自己的分支合并到develop,可以采取的做法是feature2先合并到develop,然后从develop拉一个集成分支integrate出来,然后将feature1合并到integrate,测试没问题之后,再把integrate合并到develop。
  5. 为了保持清晰的分支结构,当从feature分支合并到develop分支,或者从develop合并到master分支,在合并的时候不要用fast forward合并,具体做法:
     

命名规范

Feature分支命名的时候用 feature/<release号>/<feature描述> 这样的的格式,比如feature/0.6/unit_test_powermock。目录只包含大版本号,如0.6, 1.2,不要分得过细。

Hotfix分支命名用hotfix/<release号>/<hotfix描述>,hotfix/0.6.1/fix_user_nick_name

注:这样有个好处,在sourceTree里面,会按release号分目录放,即便是服务端的分支不删除,看起来也不会很乱了,也能很容易找到最新的。而且这样的话我们也就没必要去删除服务器上的远程分支了。

合并过程

1. 一般过程

在feature分支上开发好之后,feature的owner在GitLab上提交merge request给当天值班的Reviewer,Reviewer检查代码没问题之后,可以点Accept接受merge request。如果Merge没有冲突,GitLab会自动进行合并,并关闭merge request。

2. 有冲突的情况

Merge request如果有冲突,不能自动合并,建议按照以下方法处理:

方法一

由Reviewer在SourceTree中手工合并,解决冲突后提交,然后到GitLab关闭merge request。

好处:简单,遵守流程。

适用场景:适用于冲突较少,且Reviewer有把握的情况下。Reviewer可以跟Feature Owner沟通获取信息。

方法二

由Feature Owner在最新的develop分支上建一个新的feature integration分支(命名建议按照<feature_branch>_intg,后面可以加编号,比如feature/0.7/dispatcher_refactoring_intg1),然后在SourceTree中把feature分支手工合并到feature integration分支,手工解决冲突后push到服务器;然后,Feature Owner再到Gitlab上提交一个从feature integration分支到develop分支的merge request。

原理:因为feature_integration分支是从最新的develop代码上创建的,在把feature分支合并过来,解决冲突之后,再从feature_integration合并到develop的时候就不会有冲突了。

好处:可以统一流程,所有的合并都由GitLab的Merge request来做。

适用场景:所有,推荐

方法三

由Feature Owner手工合并,然后Reviewer在GitLab里面直接关闭merge request。

坏处:绕开了merge request,破坏Code Review流程,不推荐。

参考资料

Git常用命令图解
来源:http://blog.sina.com.cn/s/blog_6ec3c9ce01015nwv.html

A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/

Git branch naming conventions

http://www.guyroutledge.co.uk/blog/git-branch-naming-conventions/

  • No labels