如何高效的管理团队的git分支

问题由来:

最近,越来越感觉到分支管理的混乱对代码编写的恶劣影响,大家基本是每个人开一个自己的个人分支,然后所有的需求都在这个上面开发,开发完了之后合到realse发布。

且不提测试的安全性问题,就说对我写代码时的影响:

  1. 一个发布周期有两周,不可能两周只开发一个任务,那也太慢了吧!大多数时候会有大量的需求并发涌向你,而且有的任务虽然是最早开始的,但是中间很可能因为一些自己无法控制的原因不得不闲置,那这个时候我们的分支怎么办?难不成stash掉,到时候再unstash回来?
  2. 包版本难以控制,我们的项目通常会分成许许多多的jar包,为核心服务提供组件,每个jar包有自己独立的版本,如果这个地方只有一个唯一的开发分支,根本就不知道之前那个版本的Jar包版本长什么样子,也很快就会忘记当时定义的snapshot版本是什么了。
  3. 无法codereivew,我们进行codereview的时候,一般都是一个一个需求/功能的过,而如果没有明确的分支定义,单从commit和merge request,区分代码还是有很大的难度。

解决方案:

  1. 明确主分支,主分支即生产分支,一定保证是唯一的,所有的其他分支都应该是最终基于此的。
  2. 每个发布周期定义一个dev分支,如dev-20190107,即定义2019.1.7日需要发布的分支,也可以是一个唯一的dev分支,但是要保证每个新的发布周期,dev分支一定是从master分支同步过来的。
  3. future/hotfix分支,这两个其实差不太多,只不过future是新增功能,hotfix是bug修复。这个分支就是开发用来写代码的地方了,每次有新的需求,就从当时的dev分支新建一个分支,然后在其上开发。当开发完毕后,便将代码合并到dev分支,并提供给测试。测试通过后,发布日当天,将代码合到release上,我觉得这样做的好处是,才测试的时候,测试拿到的是真正要发布的代码,因为一个项目可能同时多个人在开发,那么如果在仅仅只是在自己的分支上测试的话,很可能最后的生产结果被其他同事的代码修改所影响。还有就是把合并代码的动作提前,规避了因合并代码出现问题,而到发布日措手不及。
  4. codereview:当3中所提到的future/hotfix分支合到dev分支时,进行codereview,可以设置dev分支权限,必须提交merge request才能合并代码,这样所有的修改都会经过开发负责人的过目。

2019-01-07-23-23-49-201917

这张图是从其他博客copy来的,但是思想与我说的基本一致,只不过还进一步区分了release和master,如果对发布控制非常严格的话,的确有必要这样。

分支类型 名称格式 说明
Release release 有且只有一个
Develop dev-* *通常是班车发布日期
Feature feature-* *通常是具体的功能简称
Hotfix hotfix-* *通常是需要修复Bug的简称

参考

https://www.cnblogs.com/ken-io/p/gitlab-code-review-tutorial.html

https://blog.csdn.net/jake9602/article/details/24316199

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×