Git指南¶

配置你的 Git¶

基于祖先的经验和口头传统，以下几点可以帮助您更好地提交代码：

请确保在您的本地git配置中定义了user.email和user.name
```
git config --global <var> <value>
```
请确保在您的 Github 个人资料中添加您的全名。请随意添加您的团队、头像、最喜欢的引用等等 ;-)

提交信息结构¶

提交信息包括四个部分：标签、模块、简短描述和完整描述。请尽量遵循您的提交信息的首选结构。

[TAG] module: describe your change in a short sentence (ideally < 50 chars)

Long version of the change description, including the rationale for the change,
or a summary of the feature being introduced.

Please spend a lot more time describing WHY the change is being done rather
than WHAT is being changed. This is usually easy to grasp by actually reading
the diff. WHAT should be explained only if there are technical choices
or decision involved. In that case explain WHY this decision was taken.

End the message with references, such as task or bug numbers, PR numbers, and
OPW tickets, following the suggested format:
task-123 (related to task)
Fixes #123  (close related issue on Github)
Closes #123  (close related PR on Github)
opw-123 (related to ticket)

标签和模块名称¶

标签用于给您的提交添加前缀。它们应该是以下之一

[修复] 用于修复错误：主要用于稳定版本，但如果您正在修复最近的开发版本中的错误，也是有效的；
[REF] 用于重构：当一个功能被大量重写时；
[ADD] 用于添加新模块；
[REM] 用于删除资源：删除无用代码，删除视图，删除模块，…;
[REV] 用于撤销提交：如果某个提交引起问题或者不需要，可以使用此标记进行撤销；
[MOV] 用于移动文件：使用 git move，不要更改移动文件的内容，否则 Git 可能会丢失文件的跟踪和历史记录；还用于将代码从一个文件移动到另一个文件；
[REL] 用于发布提交：新的主要或次要稳定版本；
[IMP] 用于改进：大多数在开发版本中进行的更改都是增量改进，与另一个标签无关；
[合并] 用于合并提交：用于向前移植错误修复，也用作涉及多个分离提交的功能的主要提交；
[CLA] 用于签署Odoo个人贡献者许可证；
[I18N] 用于翻译文件的更改；
[PERF] for performance patches;

标签后面是修改的模块名称。使用技术名称，因为功能名称可能会随时间改变。如果修改了多个模块，请列出它们或使用“各种”来说明它是跨模块的。除非真的需要或更容易，否则避免在同一提交中跨多个模块修改代码。理解模块历史可能会变得困难。

提交信息标题¶

在标签和模块名称之后，应该有一个有意义的提交信息标题。它应该是自解释的，并包括更改背后的原因。不要使用像“bugfix”或“improvements”这样的单词。尝试将标题长度限制在大约50个字符以提高可读性。

提交信息的标题应该与 if applied, this commit will <header> 连接后形成一个有效的句子。例如 [IMP] base: prevent to archive users linked to active partners 是正确的，因为它形成了一个有效的句子 if applied, this commit will prevent users to archive... 。

提交信息的完整描述¶

在提交信息中，请指定您的更改所影响的代码部分（模块名称、库、横向对象等）以及更改的描述。

首先解释为什么要修改代码。如果有人在大约4十年（或3天）后回到您的提交，重要的是您为什么这样做。这是更改的目的。

你所做的可以在提交中找到。如果涉及到一些技术选择，最好在为什么之后的提交消息中也进行解释。顺便说一句，对于Odoo R&D开发人员，“PO团队要求我这样做”不是一个有效的原因。

请避免同时影响多个模块的提交。尝试将其拆分为不同的提交，其中受影响的模块不同。如果我们需要单独撤销给定模块中的更改，则这将非常有帮助。

不要犹豫，多写一点。大多数人只会看到您的提交消息，并根据这些简短的句子来评判您的全部工作。完全没有压力。

你花了几个小时、几天或几周的时间来开发有意义的功能。花点时间冷静下来，写出清晰易懂的提交信息。

如果你是Odoo的研发开发人员，那么为什么（WHY）应该是你正在处理的任务的目的。完整的规范是提交消息的核心。 如果你正在处理一个缺乏目的和规范的任务，请在继续之前明确它们。

最后，这里有一些正确的提交消息示例：

[REF] models: use `parent_path` to implement parent_store

 This replaces the former modified preorder tree traversal (MPTT) with the
 fields `parent_left`/`parent_right`[...]

[FIX] account: remove frenglish

 [...]

 Closes #22793
 Fixes #22769

[FIX] website: remove unused alert div, fixes look of input-group-btn

 Bootstrap's CSS depends on the input-group-btn
 element being the first/last child of its parent.
 This was not the case because of the invisible
 and useless alert.

注解

使用长描述来解释 为什么 而不是什么，什么可以在差异中看到

Edit on GitHub