019-第三代软件开发-Git提交规范
第三代软件开发-Git提交规范
文章目录
- 第三代软件开发-Git提交规范
- 项目介绍
- Git提交规范
- 分支规范
- Commit Message Format
- Header
- Body
- Footer
- Revert
- 总结一下
关键字：
Qt、
Qml、
git、
Commit、
release
项目介绍
欢迎来到我们的 QML & C++ 项目！这个项目结合了 QML（Qt Meta-Object Language）和 C++ 的强大功能，旨在开发出色的用户界面和高性能的后端逻辑。
在项目中，我们利用 QML 的声明式语法和可视化设计能力创建出现代化的用户界面。通过直观的编码和可重用的组件，我们能够迅速开发出丰富多样的界面效果和动画效果。同时，我们利用 QML 强大的集成能力，轻松将 C++ 的底层逻辑和数据模型集成到前端界面中。
在后端方面，我们使用 C++ 编写高性能的算法、数据处理和计算逻辑。C++ 是一种强大的编程语言，能够提供卓越的性能和可扩展性。我们的团队致力于优化代码，减少资源消耗，以确保我们的项目在各种平台和设备上都能够高效运行。
无论您是对 QML 和 C++ 开发感兴趣，还是需要我们为您构建复杂的用户界面和后端逻辑，我们都随时准备为您提供支持。请随时联系我们，让我们一同打造现代化、高性能的 QML & C++ 项目！
重要说明☝
☀该专栏在第三代软开发更新完将涨价
Git提交规范
意外中的意外，在第三代软件开发过程中，博主不在一个人单打独斗，终于有了自己的小伙伴。之前自己孤生一人的时候，Git 的作用仅仅是备份，对于提交规范一直也没有注意。但是有了小伙伴，那就需要稍微规范一下，以方便后期维护和Bug定位。目前我们使用的是一个**Angular的commit message规范**这里咱们随便找两个文章朝下作业
抄作业链接：https://blog.csdn.net/Joseph_ZG/article/details/112818937
抄作业链接：https://www.jianshu.com/p/6433679cd10f
分支规范
| 分支类型 | 命名规范 | 创建自 | 合并到 | 说明 |
|---|---|---|---|---|
| master | master | - | - | 长期分支，部署到生产环境中的代码 |
| develop | develop | - | master | 长期分支，进行代码集成的分支 |
| feature | feature/* | develop | develop | 短期分支，新功能分支 |
| release | release/* | develop | develop和master | 短期分支，一次新版本的发布 |
| hotfix | hotfix/* | master | develop 和 master | 短期分支，生产环境中发现的紧急 bug 的修复，唯一可以直接从master分支fork出来的分支 |
三个短期分支类型一旦完成开发，它们就会被合并进develop或master，然后被删除。
分支的名称应该遵循一定的命名规范，以方便开发人员识别。
当需要开发一个新的功能时，基本的流程如下：
从 develop 分支创建一个新的 feature 分支，如 feature/my-xxx。
在该 feature 分支上进行开发，提交代码。
当代码提交完成之后，push feature分支到远端仓库。
在gitlab上创建合并请求
Commit Message Format
git commit 规范对于团队协作和版本控制非常重要。以下是一些 git commit 规范的重要性：
提高可读性和可维护性：使用规范化的提交消息格式可以增加代码库的可读性和可维护性。每个提交都应该清晰地描述所做的更改，以便其他开发人员能够理解和追踪代码的变化。
改进代码审查过程：规范的提交消息使代码审查过程更加高效和有意义。代码审查人员可以更轻松地查看代码变更的上下文，并提供更准确的反馈和建议。
方便问题追踪和版本控制：规范化的提交消息可以在问题追踪系统或版本控制工具中更好地关联代码变更和特定的任务或错误。这有助于有效地管理项目中的问题和版本。
促进团队合作：一致的提交消息格式有助于促进团队之间的良好合作。开发人员可以更容易地理解和解释彼此的代码变更，并更好地协同开发。
总之，git commit 规范的重要性在于提高代码库的可读性、可维护性和协作效率，使团队能够更好地管理和追踪代码的变化。
<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
每一个commit message都应该包含header，body和footer。其中footer可以省略，但是header和body都不能为空。
Header
Header分为三个部分type, scope, summary，其中type和summary为必填项，scope可以省略，格式如下:
<type>(<scope>): <summary>
Type:
用于说明git commit的类别，只允许使用下面的标识。
- feat: 新功能（feature）。
- fix: 修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。
- docs: 文档（documentation）。
- style: 格式（不影响代码运行的变动）。
- refactor: 重构（即不是新增功能，也不是修改bug的代码变动）。
- perf: 优化相关，比如提升性能、体验。
- test: 增加测试。
- chore: 构建过程或辅助工具的变动。
- revert: 回滚到上一个版本。
Scope
Scope用于说明 commit 影响的范围，比如Controller、DAO、View等等，视项目不同而不同。例如在Angular中可以是:
- animations
- bazel
- benchpress
- common
- compiler
- compiler-cli
- core
- elements
等等，如果其中包含了多个scope，可以用逗’*‘隔’。
Summary
Summary是对commit的一个简短的描述，一般Git Commit Head总共不超过50个字符，所以summary必须精简。对于英文的commit summary，第一，要使用第一人称，现在时，比如change，不是changed也不是changes，第二，首字母无需大写，第三，句尾不要标点符号。中文除了时态，其他也一样。
根据上述规范git commit message header可以如下:
fix(Controller): request url map typo
Body
和Header中的summary一样。同时需要解释提交的动机，为什么需要更改，可以和之前的行为进行比较，来说明改动的影响等等。
Footer
Footer适用于当提交的改动包含了不可兼容变化或者弃用的变化，Footer部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法，同时可以把相关Github issue，JIRA ticket或者其他文档链接填入其中
BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
Fixes #<issue number>
DEPRECATED: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>
<BLANK LINE>
<BLANK LINE>
Closes #<pr number>
Revert
还有一种特殊情况，如果当前commit用于撤销以前的commit，则必须以revert:开头，后面跟着被撤销commit的Header。
revert: fix(Controller): request url map typoThis reverts commit {commit hash id}
总结一下
把这都放在收费的文章里面，实在是可耻，请把可耻打在评论区，为了整个项目过程的连贯性，这里暂时还是吧这个放在这里，不过也会放到其他的免费转栏里面，不知道能否实现。
