Git ガイドライン¶

git の設定¶

先祖伝来の経験と伝統に基づいて、以下のことはあなたのコミットをより便利にするために長い道のりを行きます:

ローカルの git 設定で user.email と user.name の両方を必ず定義してください
```
git config --global <var> <value>
```
こちらのGithubプロフィールにフルネームを追加してください。ファンシーに感じて、あなたのチーム、アバター、あなたのお気に入りの見積もり、何;-を追加してください。

コミットメッセージ構造¶

コミットメッセージには4つの部分があります: タグ、モジュール、短い説明、および完全な説明。コミットメッセージの優先構造に従ってください。

[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] for release commits: new major or minor stable version
[IMP] 改善のため: 開発バージョンで行われたほとんどの変更は、他のタグとは関係のないインクリメンタルな改善です。
[MERGE] merge commits: with forward port of bug fixes, but also as the main commit for feature commit.
[CLA] Odoo 個人貢献者ライセンスに署名するための;
[I18N] 翻訳ファイルの変更;
[PERF] パフォーマンスパッチ;

タグに変更されたモジュール名が表示されます。技術名を関数名として使用すると、時間とともに変更されることがあります。複数のモジュールが変更された場合は、それらをリストしたり、さまざまなものを使用して相互モジュールであることを伝えます。同じコミットで複数のモジュール間でコードを変更するのを避ける必要があるか、あるいは簡単でない限り、モジュールの履歴を理解することは困難になるかもしれません。

コミットメッセージヘッダー¶

タグとモジュール名には意味のあるコミットメッセージヘッダーが表示されます。変更の背後にある理由を説明する必要があります。「バグフィックス」や「改善」のような単語は使用しないでください。読みやすさのために、ヘッダの長さを約50文字に制限してください。

コミットメッセージの書き出し（header）は、 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... という正しい文になるため、適切です。

コミットメッセージの詳細説明¶

メッセージの説明では、変更によって影響を受けるコードの部分(モジュール名、lib、transversal オブジェクト)を指定します。 ) と変更の説明。

最初にコードを変更する理由を説明します。誰かが約4十年(または3日)にコミットに戻る場合、重要なことは、あなたがそれをした理由です。それは変化の目的です。

あなたがしたことはコミット自体に見つけることができます。いくつかの技術的な選択肢があった場合は、その理由の後にコミットメッセージにも説明することをお勧めします。 Odoo R&D開発者にとって、「POチームに頼まれた」というのは、なんと言っても有効な理由ではありません。

複数のモジュールに同時に影響を与えるコミットは避けてください。影響を受けたモジュールが異なる別のコミットに分割してみてください。特定のモジュールの変更を個別に元に戻す必要がある場合に便利です。

少し冗長になることを躊躇しないでください。ほとんどの人々はちょうどそれらの少数の文に基づいてあなたの生命の中でしたすべてのあなたのコミットメッセージを見、判断する。全く圧力がありません。

あなたは数時間、数日または数週間、意味のある機能に取り組んでいます。落ち着いて明確でわかりやすいコミットメッセージを書くのに時間がかかります。

あなたがOdoo R&D開発者であるなら、なぜあなたが取り組んでいるタスクの目的であるべきか。完全な仕様はcommitメッセージの核心を作る。 目的や仕様がないタスクに取り組んでいる場合は、継続する前にそれらを明確にすることを検討してください。

最後に、正しいコミットメッセージの例をいくつか紹介します。

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

注釈

長い説明を使用して、what*ではなく*what、*what*が差分に表示されることを説明します。