网站首页 文章专栏 git分支及发布管理方式
git分支及发布管理方式
编辑时间:2019-08-18 21:47:18 作者:原点 浏览量:139

如果git(icode)不加管理,可能出现枝节蔓生、四处开放的版本库。到处都是分支,完全看不出主干发展的脉络,造成下图的局面:

为了降低合并和版本管理的成本,团队引入一种值得借鉴的管理方式(link

1.存在一条主分支(master)。所有用户可见的正式版本,都从master发布。主分支作为稳定的唯一代码库,不做任何开发使用。

拉取源:无需。

合并目标:无需。

修改:不允许。

生命期:持续。

2.存在一条开发分支(develop)。这个分支维护了当前开发中代码的主线,始终保持代码新于master。持续集成、最新隔夜版本的生成等都是基于这个分支。由于当前版本迭代较快,开发分支只提供拉取,不进行实际开发。

拉取源:master。

合并目标:无需。

修改:不允许。

生命期:持续。

 

3.临时性多个功能分支(feature)。从develop拉取。开发feature完成,merge回develop。为了降低对其他feature的影响,一般在提测前merge回develop分支。

拉取源:develop。

合并目标:develop。

修改:允许。

生命期:合并后删除。

4.临时性多个预发布(测试)分支(release),用于QA测试。从develop拉取,测试完成merge回master和develop。如果测试期间,有其他版本合并入master,需要同步到release版本,并进行测试。

拉取源:develop。

合并目标:master & develop。

修改:允许。

生命期:合并后删除。

 

4. 临时性多个bug修复分支(fixbug),用于修复线上问题。从master拉取,修复并测试完成merge回master和develop。如果修复期间,有其他版本合并入master ,需要同步到fixbug版本,并进行测试。

拉取源:master。

合并目标:master,develop。

修改:允许。

生命期:合并后删除。

原文链接:https://www.cnblogs.com/charlesblc/p/6051569.html

来说两句吧
最新评论