Git 分支管理流程
分支管理流程基于 GitLab Flow
原则
上游优先 ：只存在一个主分支 main，它是所有其他分支的“上游”。只有上游分支采纳的代码变化，才能应用到其他分支。
分支命名规范
默认分支（受保护分支）
开发分支 main，用于发布到测试环境，上游分支为各临时分支
固定分支（受保护分支）
-
持续发布
- 预发分支
pre-production，用于发布到预发环境，上游分支为main - 正式分支
production， 用于发布到正式环境的分支，上游分支为pre-production
- 预发分支
-
版本发布
-
版本分支
release/xxxx, xxxx 指代对应版本号，上游分支为main只有修改 bug 才允许合并到这些分支，此时需要更新小版本号
-
临时分支
这些分支在提交完合并请求后应从仓库和本地中删除
- 功能分支
feature-xxx，用于新功能开发 - 修复分支
fix-xxx，用于 bug 的修复
Message 编写规范
规范格式
<type|>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
Header
-
type
feat/feature：新功能 fix：修补bug docs：文档（documentation） style： 格式（不影响代码运行的变动,空格,格式化,等等） refactor：重构（即不是新增功能，也不是修改bug的代码变动） perf: 性能 (提高代码性能的改变) test：增加测试或者修改测试 build: 影响构建系统或外部依赖项的更改(maven,gradle,npm 等等) ci: 对CI配置文件和脚本的更改 chore：对非 src 和 test 目录的修改 revert: Revert a commit release: 版本发布 -
scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同 -
subject
subject是 commit 目的的简短描述，不超过50个字符。- 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
- 结尾不加句号（.）
Body
Body 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。
如有必要，更详细的说明文本。包装它
大概72个字左右。
后面的段落在空行之后。
-要点也可以
-使用悬挂缩进
应该说明代码变动的动机，以及与以前行为的对比。
Footer
-
不兼容变动
如果当前代码与上一个版本不兼容，则 Footer 部分以
BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。 -
关闭 Issue
如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。也可以一次关闭多个 issue 。
Closes #123, #245, #992
发布方式
- 见名知意：创建分支时需按照分支命名规范命名
- 小步快跑：每项功能或每个 bug 一次提交，message 必须按照规范格式编写
持续发布
-
从
main、pre-production、production创建自有分支 -
功能开发或 bug 修复
-
完成开发后在云效新建合并请求合并到
main分支若需要将 bug 修复提交到
pre-production、production分支，请使用云效在main找到修复 bug 的提交，使用 cherry-pick 新建分支并合并到pre-production；默认情况下，不允许直接向pre-production、production合并代码。 -
本次迭代功能开发、测试完成后需要预发布时，在云效中提交
main=>pre-production的合并请求 -
测试完成后发布正式包时，在云效中提交
pre-production=>production的合并请求
持续发布流程
版本发布
-
从
main、release/xxx创建自有分支 -
功能开发或 bug 修复
-
完成开发后在云效新建合并请求合并到
main分支管理员需要在代码合并完成修改版本号并进行提交（message 使用 release type），同时需要创建对应版本的 TAG 。
-
本次迭代功能开发、测试完成后需要发布时，需创建
release/xxx版本分支
版本发布流程
网友评论