本文档描述了应用于所有 gojvm 仓库的 commit message 和 Pull Request 方式。当你提交时，一定要按照样式写一个好的 commit message 以及好的 Pull Request 标题和描述。
-为了加快审核过程 -帮助审阅者更好地理解 PR -允许忽略不重要的提交 -帮助我们编写好的发行说明 -帮助未来的维护人员建立上下文 -浏览历史记录时提供更好的信息
好的 commit message 要素：
-
你的改变是什么？（必填）
它可以修复特定的错误，添加功能，提高性能，可靠性和稳定性，或只是为了正确而进行更改。
-
为什么要做出这种改变？（必填）
对于简短而明显的补丁，这部分可以省略，但应该清楚地描述这种方法。
-
提交有什么影响？ （可选）
除了明显的影响，还可能包括基准，副作用等。对于短而明显的补丁，这部分则可以省略。
为了写个好的 commit message，我们建议遵循良好的格式，培养良好的习惯，并使用良好的语言。
请按照以下方式 所有提交：
<subsystem>: <what changed>
<BLANK LINE>
<why this change was made>
<BLANK LINE>
<footer>(optional)
- 对于第一个主题行，使用不超过70个字符。
- 对于第二行，将其保持留空。
- 对于其他行，使用不超过80个字符。
- 如果更改影响两个子系统，你可以使用逗号（和空格）将它们分开，如
util / codec，util / types：。 - 如果更改影响三个或更多子系统，你可以使用
*instead, like*:。 - 对于原因部分，如果没有具体的变更原因，你可以使用“提高性能”，“提高测试覆盖率”等一般原因。
- 总结变更
- 清楚地描述一个逻辑更改并避免延迟的消息为“misc fixes”
- 描述当前代码的任何限制
- 不要以句号“。”结束主题
- 不要认为代码是显而易见的
- 不要假定审查者理解最初的问题
- 在第一行主语中使用祈使语气
- 使用简单的动词时态（例如，使用“add”而非“added”）
- 使用正确和标准的语法
- 一致地使用单词和表达式
- 使用相对较短的句子
- 不要使用冗长的复合词
- 不要缩写，除非它是绝对必要的
当提交Pull请求时，请提供有关标题中所有更改的详细信息，但需保持简洁。
** Pull Request 标题格式：**<subsystem>: <what changed>
好的 Pull Request 标题的格式与[good commit message的主题行]（#formast-of-good-commit-message）相同。
- 如果第一个提交消息中涉及所有主要更改，则可以使用第一个提交消息作为PR标题。
- 如果一个PR中包含多个提交，并且第一个提交消息无法涵盖所有更改，则编写一个新的PR标题，该标题可以涵盖此PR中涉及的所有主要更改。
对于“对话”框中的“拉取请求”描述，请参阅以下“拉取请求”描述模板并包括必要的信息：
## 你改变了什么？（必填）
请详细说明**详细信息**此PR中的更改及其原因：
- 总结更改（必填）
- PR怎么样？ 需要简要介绍已更改的逻辑（可选）
- 清楚地描述一个逻辑变化并避免延迟消息（可选）
- 描述当前代码的任何限制（可选）
请注意：
- 不要认为代码是显而易见的
- 不要假定审查者了解最初的问题
## 变化的类型是什么？（必填）
下面列出了当前定义的类型，请通过删除其他类型来选择此PR的一种类型：
- 新功能（增加功能的非破坏性更改）
- 改进（不断变化，这是对现有功能的改进）
- 错误修复（修复问题的非破坏性修改）
- 打破更改（修复可能导致现有功能无法按预期工作的功能）
## 如何测试 PR？（必填）
请描述你运行的测试以验证更改，是否完成了单元测试，集成测试或手动测试？
## PR 会影响文档（docs / docs-cn）更新吗？（必填）
如果有文件变更，请在（[docs]（https://github.com/gojvm/docs）和[docs-cn]（https://github.com/gojvm/docs-cn））中提交PR。 并在此处添加PR编号。
## 请参阅相关的PR或问题链接（可选）
## 必要的基准测试结果（可选）
## 添加一些正/负示例（可选）
对于简短而明显的 Pull Request，可以省略上述一些信息。
谢谢你的贡献！