谈一谈开发中git版本管理方式


在这里插入图片描述
参考git flow管理方式。

说明

涉及到的主要版本,master,dev及v(x)分支,其他分支均为临时分支,开发完毕并merge到master后,应及时删除分支。

master: 一定是线上上线版本,merge其他代码要慎重,要有merge request及code review。

dev: 自测版本,名称可自由定义,开发的某个feature,merge到该分支上,在开发机上进行自测。

v(x):提测版本,名称可自由定义,待提测的版本都需要merge到该分支上,可能包含多个feature同时提测,在测试机上由测试同学进行测试。

feature(x):功能分支,名称可自由定义,经过自测,提测,bug修改的多轮迭代,确认自己开发的分支无问题后,merge到master上线。

hotfix:紧急修复分支,名称可自由定义,紧急修复线上bug,修复后简单自测,无问题后merge到master上线修复。

为什么要分支管理(Why)?

开发过程中,分支管理太乱,如果只有大版本管理,如v(x),dev,上线时一般是将v(x) merge进master进行上线,但此时有些feature可能并不想上线,导致线上代码会包含一些新feature,影响稳定性。

原则

  1. v(x)、dev只能merge master代码,不能将这两个分支的代码merge到master。
  2. 新feature分支的branch,一定要由master检出,遵循包含最少代码原则。这两条原则都是为了保证上线代码不要包含多余的feature。
  3. hotfix一定要从master分支检出,并保证fix上线的代码同步merge进dev和v(x)。
  4. 已经merge进master分支并上线的feature分支要及时删除。

问题

  1. 如果有多个feature需要上线,怎么办?
    多个分支merge进某个分支如feature1,然后将feature1 merge进master进行上线。

欢迎大家评论和补充不足的地方!

发布了35 篇原创文章 · 获赞 81 · 访问量 3万+

猜你喜欢

转载自blog.csdn.net/chanllenge/article/details/90476988