Git Commit 日志风格指南
每条 commit 日志的第一行，包含类型、范畴、描述三部分。以下为可用的 commit 类型及意义。类型说明featfeature - 所有实现新功能、新行为的 commit 都属这个类型fix修正缺陷的 commitchore日常维护性的改动，例如 linter 的配置等test与测试有关的改动refactor不改变行为的对代码结构的改...
·
原则
遵循少量多次的提交原则，每天下班前必须提交当天代码。
commit规范
每条 commit 日志应包含类型+简要描述两个部分。
如：
feat：大厅功能 //新开发的大厅功能
fix：子游戏跳转失败 //修复的子游戏跳转的bug
perfect：每日签到 //优化每日签到功能
以下为可用的 commit 类型及意义。
| 类型 | 说明 |
|---|---|
| feat | feature - 所有实现新功能、新行为的 commit 都属这个类型 |
| fix | 修正缺陷的 commit |
| perfect | 优化代码的commit |
| test | 与测试有关的改动 |
| docs | 对文档的改进，包括对外文档和代码注释 |
| build | 和构建流程、持续集成等有关的改动 |
| chore | 日常维护性的改动，例如 linter 的配置等 |
| refactor | 不改变行为的对代码结构的改进 |
| style | 对代码风格的修正（仅限缩进、空行一类的简单改动，对结构有影响的用 refactor） |
| cosm | cosmetic - 不改变行为的对界面的纯视觉上的改动 |
其他
- 编辑器设置，编译文件等应该添加到.gitignore
- 理论上禁用
force push，应该先revert再重新提交
参考
开放原子开发者工作坊旨在鼓励更多人参与开源活动，与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动，如meetup、训练营等，主打技术交流，干货满满，真诚地邀请各位开发者共同参与！
更多推荐
1
0- 0
已为社区贡献2条内容
所有评论(0)