-
版本管理规约
分支单词中可使用驼峰命名，单词之前统一使用下划线( 禁止使用中划线等其他分隔符
- release分支为最终功能发版分支，test集成测试分支必须在前一天由测试人员合并到release分支进行版本发布，目前由 shihu担任
任何的产品包释出，发布，效能组为唯一出口，每次发布均需要构建产品包，打tag
分支类型及命名
master 分支
简称：master
- 简介：主干分支，用于生成环境(与saas保持一致)的发布
- 责任人：shihu
- 受保护：是
- 命名规则：master
- 命名示例：master
注意事项
简称：dev
- 简介：研发侧用于集成测试的分支
- 责任人：产品研发负责人
- 受保护：是
- 命名规则：dev
- 命名示例：dev
注意事项
简称：feat
- 简介：特性分支，用于新功能的开发；
- 责任人：功能开发的主程
- 受保护：否
- 命名规则：feat_[functionName]
- 命名示例：feat_multiEngine、feat_multiEngine_xx（若出现某个分支的功能是定制的，则以项目代号或者客户简称为分支后缀）
注意事项
- feature分支用于特定功能的开发，在需求评审完毕完成功能模块分解之后由研发TL基于最新的发布里程碑创建（划分原则是团队开发尽量少代码冲突）
- feature分支在版本发布之后打完里程碑后，由分支研发的主程删除
- 若分支是针对某个客户定制（原则上定制功能通过主干分支的开关来启用和禁用），则分支的命名规则为 feat[functionName][customerCode]，如feat_sso_xx（xx银行定制单点登录）、feat_noLogin_fuli（xx地产免登）
- 若在开发集成测试出现严重冲突必须合并dev分支时，则主程基于feat分支再创建一个分支并合并dev解决冲突，每次修改仍旧在feat分支进行，修改完后合并到新的分支，新分支命名规则为feat_[functionName]_mergedDev，命名示例如feat_mutliEngine_mergedDev、feat_noLogin_fuli_mergedDev
- 若在测试集成环境出现严重冲突必须合并test分支时，则主程基于feat分支再创建一个分支并合并test解决冲突，每次修改人就在feat分支进行，修改完后合并到新分支，再合并到test分支，新的分支命名规则为feat_[functionName]_mergedTest，命名示例如feat_mutliEngine_mergedTest
- release分支由test分支演变而来，若出现合并冲突，则修改feat[functionName]分支并合并到feat[functionName]_mergedTest分支，在最终合并到release分支
test 分支
- feature分支用于特定功能的开发，在需求评审完毕完成功能模块分解之后由研发TL基于最新的发布里程碑创建（划分原则是团队开发尽量少代码冲突）
简称：test
- 简介：测试分支，会将版本迭代的特性合并到改分支进行测试侧的集成测试，最终也是基于本分支进行最终的版本发布；
- 责任人：测试负责人
- 受保护：否
- 命名规则：test_3.10.x
- 命名示例：test_3.10.x、test_3.10.x_hxb
注意事项
简称：release
- 简介：可认为是master分支的未测试版，用于UAT环境的发布，比如某一个迭代开发完成，并发布test分支进行测试，此时test分支将被合并到release分支，再经过UAT及业务测试通过后，可合并到master分支进行发布
- 责任人：测试负责人
- 受保护：否
- 命名规则：release_3.10.x
- 命名示例：release_3.9.x、release_3.8.x、release_3.9.x_xxb
注意事项
简称：hotfix
- 简介：线上bug修复分支，从问题点的里程碑拉取，bug修复后将合并到release分支
- 责任人：缺陷修复者
- 受保护：否
- 命名规则：hotfix3.7.x[issueID]
- 命名示例：hotfix_3.7.x_186723、hotfix_3.8.x_19823_xxb
注意事项
简称：tmp
- 简介：临时分支，用于临时测试使用
- 责任人：分支建立者
- 受保护：否
- 密码规则：tmp[functionName][花名缩写]
- 命名示例：tmp_sso_mb、tmp_sso_yss
注意事项
命名规则:vx.y.z_beta[d]
- 命名示例：v3.8.1、v3.8.2_beta2、v3.8.3_xxb、v3.8.2_beta4_xxb
注意事项
tag 标签，里程碑，为了标记某种事物
- tag 是git版本库的一个快照，指向某个commit 的指针
tag 在发布版本时需要用到，另外git 提供了 tag的crud一系列操作，
tag 与 branch 的区别与各自使用场景
tag 对应某次commit ，为一个点，不可移动
branch 对应一系列的commit ，想想自己编写代码的时候是不是一连串的commit都在一个分支上，有一个HEAD指针，可以依靠HEAD指针移动。
tag 与 branch 配合使用
下例来源于网络，未实践
例如 已经发布了 v1.0 v2.0 v3.0 三个版本，这个时候，我突然想不改现有代码的前提下，在 v2.0 的基础上加个新功能，作为 v4.0 发布。就可以 检出 v2.0 的代码作为一个 branch ，然后作为开发分支。
tag 的简单使用
创建标签
- 创建tag基于本地分支的commit ，而且与分支的推送是两回事，分支已经推送到远程，但是tag并没有，如果吧tag推送到远程分支上，需要另外执行tag的推送命令
git tag tagname // 创建本地tag`<br />git push origin tagname // 推送到远程仓库`
- 存在很多未推送的本地标签的情况下，全推送
`git push origin --tags
- 以上是基于本地当前分支的最后的一个 commit 创建的 tag ，但是如果不想以最后一个，只想以某一个特定的提交为 tag ，也是可以的，只要你知道 commit 的 id。
未完待续。。。
若有收获，就点个赞吧
0 人点赞
