Git分支管理规范
来源:互联网 发布:在淘宝上搜春药怎么搜 编辑:程序博客网 时间:2024/05/18 00:50
基本原则
- 分支命名不能包含中文,英文不行就是用全拼,不要在乎长度。
- 不同渠道或不同语种的版本,应该通过工程配置来区分打包,用架构设计来消灭“不同版本使用不同分支”的做法。
- 分支既然叫“分支”,就是要被“修剪”的。达成目的后的分支都该删除,否则就像僵尸代码。
命名格式总览
feature/login 个人分支 person/{developer-fullname}/{what-for} person/gongbenwuzang/network-cache
person/jimgreen/bugfix-12345-crash tag {version-code}/{timestamp} 1.2.3.456/1712031723 特殊分支 special/{what-for} special/blind-apple
special/temp/version/1.0.2
master(主干)
master
上肯定是最近一个发布版本的代码。每个版本发布后,从版本分支合并或变基而来。
版本分支
在版本立项后开出。需注意分支名中的版本号中不包括构建号(build code),打tag时才包括。 因为有些hotfix或灰度发布并不会修改版本号,只改动构建号。这样的hotfix应继续在该版本分支上开发,并在打tag时用构建号区分。
在版本提测前,所有在此版本发布的需求分支都要合并过来。
正在开发的版本分支可在下个版本发布后删除。例如1.0.0
分支应在1.0.1
发布后删除,或在1.0.2
开出时删除。要找回该版本的代码,应从Tag里面找。实际操作中不删除也可以。
需求分支
在快速迭代的开发过程中,需求确立时未必就确定了在哪个版本,所以需求分支名不包括版本号。需求分支可从任何节点开出,为了减少后续合并麻烦,一般基于版本分支开出,或在开发过程中做变基操作。
如果公司的资源足够多,需求分支可在做完本需求的测试后再合入版本分支。
合入版本分支后,此需求分支应删除,在log中体现该需求。
个人分支
一个需求如果由多个人完成且代码修改范围交集较小,则每个人可以从需求分支开出个人分支做开发,完成后合并回需求分支。合并后,个人分支应删除。
解bug也在个人分支中进行。完成验证后,合并到版本分支并删除。
个人分支也可以用作研究和试验用途。有结论后应把有意义的试验代码通过文档来体现,然后删除此个人分支,否则可能过一段时间后也没人知道这是干嘛的了。
Tag
需注意tag名包含构建号;时间戳精确到分钟,年不要20前缀。保证信息充足的前提下尽量简短。
tag应该都是从版本分支打出,需求独立提测也可以在需求分支打出。提测或者发布版本时都要打tag。通过时间戳来看哪个是最后一版。
发布后,没用作发布的tag都应该删除。
特殊分支
各种莫(shen)名(jing)其(bing)妙的需求都有,特殊分支还是有存在的必要的,例如做个马甲版。一般特殊分支也是要发布的,但不会多次迭代。如果也迭代了几个版本,那么也可以参考主版本有多级结构。例如special/majia/version/1.0.1
。
- Git分支管理规范
- Git分支管理规范和解析
- Git各开发分支管理规范
- GIT分支开发规范
- Git分支使用规范
- 3.3 Git 分支 - 分支管理
- git 分支管理-----本地分支,远程分支
- Git分支管理
- Git 创建管理分支
- Git分支管理策略
- Git分支管理策略
- Git分支管理策略
- Git分支管理策略
- Git分支管理策略
- Git分支管理
- git分支管理
- Git远程分支管理
- git分支管理策略
- 微信红包订单存储架构变迁的最佳实践
- Spread Studio跨平台表格控件集发布V11版本,速度更快、内存更省
- Kotlin 开发
- YYCache学习
- 第14周项目1(6)- 验证算法 堆排序
- Git分支管理规范
- 打开层级比较深的Activity并返回到App的主页面
- 实现图片上传至OSS(阿里云)
- 常见优化算法 (tensorflow对应参数)
- EventBus粘性的简单使用
- 【python】打印带中文的list
- 删除war包
- BI到AI,大数据商业智能分析工具将更智能
- IDEA同时查看多个文件