Git 规范
2022-07-20 14:08:28 1 举报AI智能生成
Git 开发使用规范
作者其他创作
大纲/内容
Git
开发阶段
分支命名规范
生命周期
常驻
发布分支
说明
用于发布正式版本的 主干分支 或 版本分支
常驻, 受保护, 仅允许具有发版权限的成员进行 Merge 操作, 不允许 push 操作
分类
master：主干分支
release/*：版本分支
集成分支
说明
用于构建公共开发环境, 汇集各个需求开发成果
分类
dev
sit
test
临时
需求开发分支
分类
feature/*：特性分支
bugfix/*：bug 修复分支
说明
用于完成需求开发任务的分支
合并到上级之后立即删除, 不重复使用
允许被个人使用
个人使用时, 允许直接 push 代码
多人协作使用时, 不允许直接 push 代码, 必须走 Code Review 流程, 详情参考: Code Review 规范
多人协作使用时, 每参与者可以派生自己的个人分支, 规则详见具体类别
个人派生命名规则
feature/{topic}-personal/{user}-{日期或序号}
bugfix/{topic}-personal/{user}-{日期或序号}
hotfix/{topic}-personal/{user}-{日期或序号}
热修复分支
hotfix/*
用于紧急修复线上问题的分支
待发布分支
pre-release/*
用于封版的预发布分支
说明
临时分支, 确保合并到所有受影响的 常驻类分支 后, 可直接删除, 不重复使用
一般是个人使用, 或采用结对编程的方式共用同一个分支
若确实需要多人分工协作可参考 Bug 修复分支 的派生规则, 这里不再赘述
派生分支时, 务必确认线上版本, 不可携带其他不相干的 commit 到线上
若修复期间, 上级分支发生了变动, 允许将此分支临时视为 发布分支 并进行发布操作, 但务必要全员知会
说明
bugfix/* 和 hotfix/* 区别
bugfix/* 强调必须同需求一起走完整流程的普通 bug 修复
hotfix/* 强调必须要直接在线上热修复
分支的来源及终点
代码格式化
插件或hook 会检查提交的内容是否符合规范
切换分支
stash
changelist
提交阶段
使用本人工作邮箱进行 Commit 和 Push
应用 Patch 时, 务必保留原作者(含第三方), 保证 Commit 原作者的真实性
合并方向
bugfix/feat -> dev
bugfix/feat -> tst
tst -> release
release -> master
内容
格式
<类型>([可选的作用域]): <描述> [可选的 Issue ID]
[可选的正文]
[可选的脚注]
使用的插件
Idea使用插件 commit template
类型
主要类型
feat - A new feature
新功能
fix - A bug fix
错误修复
次要类型
docs - Documentation only changes
仅文档更改
style -Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
不影响代码含义的更改（空白、格式、缺少分号等）
refactor - A code change that neither fixes a bug nor adds a feature
既不修复bug也不添加功能的代码更改
perf - A code change that improves performance
提高性能的代码更改
test - Adding missing tests or correcting existing tests
添加缺失的测试或更正现有测试
chore - Other changes that don't modify src or test files
不修改src或测试文件的其他更改
build - Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
影响构建系统或外部依赖项的更改（示例范围：gulp、brocoli、npm）
特殊类型
ci - Changes to our Cl configuration files and scripts (example scopes:Travis, Circle, BrowserStack, SauceLabs)
对Cl配置文件和脚本的更改（示例范围：Travis、Circle、BrowserStack、SauceLabs）
revert - Reverts a previous commit
还原以前的提交
release：发布版本提交
其他
Issue ID要求
使用方括号包裹 如 [XFRAME-111]
必须是标准的 Issue ID, 保持大写
多个 Issue 时, 分别用方括号包裹，用空格分割，示例：eat: confluence create function, tools access function [DEVOPSAPI-590] [DEVOPSAPI-573]
Commit Message 规范的好处
结构化的提交历史，方便快速浏览, 跟踪工程历史, 快速查找信息, 降低对的项目做出贡献的难度
可读性好，基于提交的类型，自动决定语义化的版本变更
利于 Code Review, 向同事、公众与其他利益关系者传达变化的性质
自动化生成 CHANGELOG
如何描述提交的内容
- 以动词开头，第一人称现在时，比如 change，而不是 changed 或 changes
- 除特有名词, 首字母小写
- 遵循特有名词的拼写规则, 参考: 命名的礼仪
- 引用的代码或者文件名, 保持原有拼写规则
- 结尾不需要使用句号.
0 条评论
下一页
为你推荐
查看更多
