代码管理的规范

目录

分支管理

master

release分支

hotfix分支

feature分支

develop / test分支

版本分支的管理

图1:保持相对稳定的test分支

图2:定期基于最新的master拉取新的test分支


为了规范代码仓库主干和分支的管理,使代码分支管理及版本关系清晰,方便维护,避免由于管理混乱导致的错误代码发布等问题。代码分支管理规范因此而生。

分支管理

master

  • master主分支,也是持续保持相对稳定的分支。
  • 一般在develop分支测试稳定后,才会将稳定的代码合到master。

release分支

  • release分支是用来发布上线的专用分支。所有release分支的单独改动都需要合回到master。
  • release分支的代码一定是稳定的,但不一定是最新的。
  • release分支是不允许做大的未经测试的变更的,只允许小的紧急问题以hotfix的方式缺陷修正。

hotfix分支

  • hotfix分支一般规范命名为hotfix-*。
  • hotfix分支一般基于release分支拉取,通过紧急修复、回归测试后,再立即合回到release进行发布。
  • hotfix分支的改动在合并release到同时,也需要合到master,合到最新的developer分支。

feature分支

  • feature分支一般是匹配产品需求或者开发技术的,以开发一项新的功能或一项新的优化为目的,相应也需要以feature-* 或者tech-*的规范命名。
  • feature分支一般会从比较稳定的master拉取,但特殊情况下,当多个开发需求有冲突或依赖的时候,也会基于一个不稳定的feature分支,或者是最新的develop分支来拉取新feature分支。
  • feature分支的代码,也是未经过测试,极其不稳定的。
  • feature分支开发的代码,一旦合到master后就可以被弃掉,后续基本不会再用到。

develop / test分支

  • develop分支,一般所有分支中代码是最全的。不仅包含了稳定的master代码,以及所有最新的feature分支的代码,是用来测试的分支。
  • develop分支是不稳定的,用于测试的,因此有的公司也会直接命名为test分支。

版本分支的管理

至于怎么保证test分支所包含的代码一定是最全的,一般可以有两种方案:

  • 一种保持固定的test分支,并定期同步最新的master到test分支。此时的test分支相当于起到了一个集成测试分支的作用。
  • 另一种是定期基于最新的master拉取新的test分支。这里的test分支相当于一个阶段测试分支的作用。

至于哪种方式更好,和不同团队的项目流程和版本迭代节奏有关。

可以看看下方这两个图的比较:

图1:保持相对稳定的test分支

  • 优势在于:开发只需要解决一次冲突:从feature分支到test分支。master的代码和release分支都非常稳定,可作为发布分支。
  • 缺点在于:同一批集成测试的内容必须要同时稳定下来,才可合并到master并最终完成上线。一旦个别feature未稳定,则会影响到整个分支内容的上线时间。

因此这个分支管理,只适合团队默契度非常高,版本节奏非常固定,并且相对迭代节奏比较慢的团队使用。

图2:定期基于最新的master拉取新的test分支

  • 优势在于:测试稳定的项目不用互相等待,随时可以合并到master,并且尽早完成上线
  • 缺点在于:开发需要解决至少两次冲突:从feature分支到test分支,再从feature分支到release分支(因为存在test分支一起测试的代码并不会一起上线的可能)。同时因为要解决冲突,master也承担了集成测试分支的作用,因此master的代码只是相对稳定,不会像图1流程一样做到绝对的稳定。

至于各个团队的代码分支管理,都会有适合自己团队的规范。没有最完美的,只有最合适自己项目和团队的,遵守自己团队的代码分支管理规范,才能减少生产问题。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值