Tools

go 的代码风格 git commit 规范 git 教程 The Uber Go Style Guide

说明 文档中使用的关键字「MUST」,「MUST NOT」,「REQUIRED」,「SHALL」,「SHALL NOT」,「SHOULD」,「SHOULD NOT」,「RECOMMENDED」,「MAY」和「OPTIONAL」在 RFC2119 中有说明。 还未定稿，对规范中提及的点有不赞同的欢迎提出 issues（请添加 markdown 标签）讨论。 规则 后缀必须「MUST」使用 .md。 文件名必须「MUST」使用小写，多个单词之间使用-分隔。 文件编码必须「MUST」用 UTF-8。 文档标题应该「SHOULD」这样写。 Markdown 编写规范 ========================== 章节标题必须「MUST」以 ## 开始，而不是 #。 章节标题必须「MUST」在 # 后加一个空格，且后面没有 #。 // bad ##章节1 // bad ## 章节1 ## // good ## 章节1 章节标题和内容间必须「MUST」有一个空行。 // bad ## 章节1 内容 ## 章节2 // good ## 章节1 内容 ## 章节2 代码段的必须「MUST」使用 Fenced code blocks 风格，如下所示： ``` console.log(""); ``` 表格的写法应该「SHOULD」参考 GFM，如下所示： First Header | Second Header ------------- | ------------- Content Cell | Content Cell Content Cell | Content Cell | Left-Aligned | Center Aligned | Right Aligned | | :------------ |:---------------:| -----:| | col 3 is | some wordy text | $1600 | | col 2 is | centered | $12 | | zebra stripes | are neat | $1 | 中英文混排应该「SHOULD」采用如下规则：...

文档连接 语义化版本： 用于发版相关的规范 约定式提交（Conventional Commits）是一种用于写作提交消息的规范，它规定了一套标准化的提交消息格式，以使得项目的版本控制更加清晰和一致。采用这种规范的好处是能够帮助开发团队更好地理解代码的变更历史、生成变更日志（changelog），以及进行版本控制。 约定式提交的基本格式 <类型>(<范围>): <描述> <主体> <footer> 各部分说明 1. 类型（type）：用于说明提交的类型，例如是修复bug还是添加新功能。常见的类型包括： feat：新功能（feature） fix：修补bug docs：文档（documentation）变更 style：代码格式（不影响代码运行的变动） - refactor：重构（即不是新增功能，也不是修改bug的代码变动） - test：增加测试 - chore：构建过程或辅助工具的变动 2. 范围（scope）：可选项，用于说明提交影响的范围（例如模块、文件等）。 3. 描述（subject）：简要说明提交的内容。 4. 主体（body）：可选项，用于详细说明提交的内容，可以分成多行。 5. 脚注（footer）：可选项，用于说明重大变更，或者关联的issue。例如： - BREAKING CHANGE：说明重大变更 - Closes #123：关闭issue 示例 feat(auth): add login functionality Added login functionality with OAuth2 integration. Users can now log in using their Google account. Closes #45