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] 重構:當一個功能被大量重寫時;

  • [添加] 用于添加新模塊;

  • [REM] 用于移除資源:移除死代碼、移除視圖、移除模塊等;

  • [REV] 用于撤銷提交:如果某個提交引起了問題或者不需要,可以使用此標簽進行撤銷;

  • [MOV] 用于移動文件:使用 git move 命令,不要更改移動文件的內容,否則 Git 可能會丟失文件的跟蹤和歷史記錄;還用于從一個文件中移動代碼到另一個文件中;

  • [REL] 用于發布提交:新的主要或次要穩定版本;

  • [IMP] 對于改進:大多數在開發版本中進行的更改都是增量改進,與另一個標簽無關;

  • [MERGE] 用于合并提交:用于向前移植錯誤修復,也可用作涉及多個分離提交的功能的主要提交;

  • [CLA] 用于簽署Odoo個人貢獻者許可證;

  • [I18N] 用于翻譯文件的更改;

標簽后面是修改的模塊名稱。使用技術名稱,因為功能名稱可能會隨時間改變。如果修改了多個模塊,請列出它們或使用“各種”來說明它是跨模塊的。除非真的需要或更容易,否則避免在同一提交中跨多個模塊修改代碼。理解模塊歷史可能會變得困難。

提交信息標題?

在標簽和模塊名稱之后,應該有一個有意義的提交信息標題。它應該是自解釋的,并包括更改背后的原因。不要使用像“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團隊要求我這樣做”不是一個有效的原因。

請避免同時影響多個模塊的提交。嘗試將其拆分為不同的提交,其中受影響的模塊不同。如果我們需要單獨撤銷給定模塊中的更改,則這將非常有幫助。

不要猶豫,多寫一點。大多數人只會看到您的提交消息,并根據這些簡短的句子來評判您的全部工作。完全沒有壓力。

你花費了數小時、數天或數周的時間來開發有意義的功能?;ㄐr間冷靜下來,編寫清晰易懂的提交信息。

如果你是Odoo R&D開發人員,那么“為什么”應該是你正在處理的任務的目的。完整的規范是提交消息的核心。 如果你正在處理缺乏目的和規范的任務,請考慮在繼續之前澄清它們。

最后,這里有一些正確的提交消息示例:

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

注解

使用長描述來解釋 為什么 而不是 什么 , 什么 可以在差異中看到