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)

标签和模块名称

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

  • [FIX] 用于错误修复：主要用于稳定版本，但如果您正在修复开发版本中的最近错误，也有效；

  • [REF] 用于重构：当某个功能被大量重写时；

  • [ADD] 用于添加新模块；

  • [REM] 用于删除资源：删除死代码、删除视图、删除模块……；

  • [REV] 用于恢复提交：如果提交导致问题或不希望恢复，则使用此标签完成；

  • [MOV] 用于移动文件：使用 git move 并且不要更改移动文件的内容，否则 Git 可能会丢失文件的跟踪和历史记录；也用于将代码从一个文件移动到另一个文件时；

  • [REL] 用于发布提交：新的主要或次要稳定版本；

  • [IMP] 用于改进：开发版本中所做的大部分更改都是与其他标签无关的增量改进；

  • [MERGE] 用于合并提交：用于错误修复的转发端口，但也作为涉及多个单独提交的功能的主要提交；

  • [CLA] 用于签署 Odoo 个人贡献者许可证；

  • [I18N] 用于翻译文件的更改；

  • [PERF] 用于性能补丁；

  • [CLN] 用于代码清理；

  • [LINT] 用于 linting 通道；

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

提交消息头

标签和模块名称之后是一个有意义的提交消息标头。它应该是不言自明的，并包括更改背后的原因。不要使用“错误修复”或“改进”等单个词。为了可读性，尝试将标头长度限制在 50 个字符左右。

提交消息头一旦与 if applied, this commit will <header>. For example [IMP] base: prevent to archive users linked to active partners is correct as it makes a valid sentence if applied, this commit will prevent users to archive... 连接起来就应该形成一个有效的句子。

提交消息完整描述

在消息描述中指定受更改影响的代码部分（模块名称、库、横向对象…）以及更改的描述。

首先解释一下为什么要修改代码。如果有人在大约 4 年（或 3 天）后回到你的承诺，那么重要的是你这样做的原因。这就是变革的目的。

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

请避免同时影响多个模块的提交。尝试分成不同的提交，其中受影响的模块不同。如果我们需要单独恢复给定模块中的更改，这将很有帮助。

不要犹豫，说得有点冗长。大多数人只会看到你的提交信息，并仅根据这几句话来判断你一生中所做的一切。完全没有压力。

您花费几个小时、几天或几周的时间来开发有意义的功能。花一些时间冷静下来，写出清晰易懂的提交消息。

如果您是 Odoo 研发开发人员，那么“为什么”应该是您正在执行的任务的目的。完整的规范构成了提交消息的核心。 如果您正在执行的任务缺乏目的和规范，请考虑在继续之前将其明确。

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

[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.

注解

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