admin管理员组文章数量:1657294
常规提交Conventional Commits
为提交消息添加人类和机器可读含义的规范
快速摘要完整规格贡献常规提交 1.0.0
概括
常规提交规范是提交消息之上的轻量级约定。它提供了一组简单的规则来创建显式提交历史记录；这使得在其之上编写自动化工具变得更加容易。此约定与SemVer相吻合，通过描述提交消息中所做的功能、修复和重大更改。
提交信息的结构应如下：
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
提交包含以下结构元素，用于向您的库的消费者传达意图：
- 修复：提交该类型
fix的补丁来修复代码库中的错误（这与PATCH语义版本控制相关）。 - feat：该类型 的提交
feat为代码库引入了一个新功能（这与MINOR语义版本控制相关）。 - 重大变更：具有页脚的提交，或在类型/范围后
BREAKING CHANGE:附加，引入了重大 API 变更（与语义版本控制相关）。重大变更可以是任何类型的提交的一部分。!MAJOR fix:允许使用和之外的其他类型 ，feat:例如@ commitlint / config-conventional（基于Angular 约定）推荐build:、、、、、、、、、等。chore:ci:docs:style:refactor:perf:test:- 可以提供除 之外的其他页脚，并遵循与git 尾部格式
BREAKING CHANGE: <description>类似的约定 。
常规提交规范不强制要求其他类型，并且在语义版本控制中没有隐式效果（除非它们包含重大更改）。 可以为提交的类型提供范围，以提供额外的上下文信息，并包含在括号中，例如feat(parser): add ability to parse arrays。
例子
提交带有描述和重大变更页脚的消息
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
提交消息以!引起对重大变化的注意
feat!: send an email to the customer when a product is shipped
提交具有范围的消息并!引起对重大变化的注意
feat(api)!: send an email to the customer when a product is shipped
提交带有!BREAKING CHANGE 页脚的消息
chore!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
提交无正文的消息
docs: correct spelling of CHANGELOG
提交消息及范围
feat(lang): add Polish language
提交具有多段正文和多个页脚的消息
fix: prevent racing of requests
Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.
Remove timeouts which were used to mitigate the racing issue but are
obsolete now.
Reviewed-by: Z
Refs: #123
规格
本文档中的关键词“必须”、“不得”、“要求”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”应按照RFC 2119中的规定进行解释。
- 提交必须以类型为前缀，由名词、、等组成
feat，fix后跟 OPTIONAL 范围、OPTIONAL!和 REQUIRED 终止冒号和空格。 feat当提交向您的应用程序或库添加新功能时，必须使用该类型。fix当提交代表应用程序的错误修复时，必须使用该类型。- 可以在类型之后提供范围。范围必须由描述代码库一部分的名词组成，并用括号括起来，例如，
fix(parser): - 描述必须紧跟在类型/范围前缀后的冒号和空格之后。描述是代码更改的简短摘要，例如，修复：当字符串中包含多个空格时出现的数组解析问题。
- 简短描述后可以添加较长的提交正文，以提供有关代码更改的其他上下文信息。正文必须在描述后一个空白行开始。
- 提交主体是自由格式的，可以由任意数量的换行符分隔的段落组成。
- 可以在正文后一个空行处提供一个或多个页脚。每个页脚必须由一个单词标记、后跟一个
:<space>或<space>#分隔符以及一个字符串值组成（这是受 git 尾部约定启发的）。 - 页脚标记必须用来
-代替空格字符，例如Acked-by（这有助于区分页脚部分和多段落正文）。例外情况是BREAKING CHANGE，它也可以用作标记。 - 页脚的值可以包含空格和换行符，并且当观察到下一个有效的页脚标记/分隔符对时，解析必须终止。
- 必须在提交的类型/范围前缀中或作为页脚中的条目指明重大变更。
- 如果作为页脚包含在内，重大变更必须由大写文本 BREAKING CHANGE，后跟冒号、空格和描述组成，例如， BREAKING CHANGE：环境变量现在优先于配置文件。
!如果包含在类型/范围前缀中，重大变更必须在 之前立即用 表示:。如果!使用 ，BREAKING CHANGE:可以从页脚部分省略，并且应使用提交描述来描述重大变更。- 您的提交信息中还可以使用除
feat和之外的其他类型，例如， docs：update ref docs。fix - 实施者绝不能将构成常规提交的信息单元视为区分大小写，但 BREAKING CHANGE 除外，该信息单元必须大写。
- 当在页脚中用作标记时，BREAKING-CHANGE 必须与 BREAKING CHANGE 同义词。
为什么要使用常规提交
- 自动生成 CHANGELOG。
- 自动确定语义版本提升（基于提交的类型）。
- 向队友、公众和其他利益相关者传达变化的性质。
- 触发构建和发布过程。
- 通过允许人们探索更结构化的提交历史，使他们能够更轻松地为您的项目做出贡献。
常问问题
在开发初期该如何处理提交信息？
我们建议您像已经发布产品一样继续操作。通常有人（即使是您的软件开发人员同事）正在使用您的软件。他们会想知道修复了哪些问题、哪些问题出现了等等。
提交标题中的类型是大写还是小写？
可以使用任意大小写，但最好保持一致。
如果提交符合多种提交类型，我该怎么办？
尽可能返回并进行多次提交。常规提交的好处之一是它能够促使我们进行更有组织的提交和 PR。
这难道不会阻碍快速开发和快速迭代吗？
它不鼓励以无组织的方式快速行动。它可以帮助您在多个项目中与不同的贡献者长期快速行动。
常规提交是否会导致开发人员限制他们所做的提交类型，因为他们会考虑所提供的类型？
常规提交鼓励我们更多地进行某些类型的提交，例如修复。除此之外，常规提交的灵活性还允许您的团队提出自己的类型并随时间更改这些类型。
这与 SemVer 有何关系？
fix类型提交应转换为PATCH发布。feat类型提交应转换为发布。提交中MINOR包含的提交，无论类型如何，都应转换为发布。BREAKING CHANGEMAJOR
我应该如何对我的扩展进行版本控制以满足常规提交规范，例如@jameswomack/conventional-commit-spec？
我们建议使用 SemVer 发布您自己对此规范的扩展（并鼓励您进行这些扩展！）
如果我意外使用了错误的提交类型该怎么办？
当你使用符合规范但类型不正确的类型时，fix例如feat
在合并或发布错误之前，我们建议使用git rebase -i编辑提交历史记录。发布后，清理工作将根据您使用的工具和流程而有所不同。
当你使用不符合规范的类型时，feet例如feat
在最坏的情况下，如果提交不符合常规提交规范，那也不算世界末日。这仅仅意味着基于规范的工具将错过该提交。
我的所有贡献者都需要使用常规提交规范吗？
不会！如果您在 Git 上使用基于压缩的工作流程，则首席维护者可以在合并提交消息时清理提交消息 — 不会给临时提交者增加任何工作量。一种常见的工作流程是让您的 git 系统自动压缩来自拉取请求的提交，并为首席维护者提供一个表单，以便输入正确的 git 提交消息进行合并。
常规提交如何处理恢复提交？
恢复代码可能很复杂：您是否要恢复多个提交？如果您恢复某个功能，下一个版本是否应该是补丁？
传统提交不会明确定义恢复行为。相反，我们让工具作者利用类型和页脚的灵活性来开发处理恢复的逻辑。
一个建议是使用revert类型和引用正在恢复的提交 SHA 的页脚：
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868本文标签： 常规GitHubCommitsconventional
版权声明：本文标题：github常规提交Conventional Commits 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://www.elefans.com/dongtai/1729781170a1212612.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论