odoo-commit

ワークフロー

1. git diff --stat と git status --short を実行して変更内容を確認し、さらに git log -1 --oneline（リモート追跡ブランチが存在する場合は git log @{u}.. --oneline も）を実行して、最後のローカルコミットと、まだプッシュされていないかどうかを確認します。

2. 変更が未プッシュの HEAD コミットの直接的な続き、または修正である場合は、 新しいメッセージの作成を省略し、同じ論理的な変更について2つ目のコミットを作成するのではなく、既存のコミットにまとめます。

   git add <file>
   git commit --amend --no-edit   # or drop --no-edit to also revise the message
   

   それ以外の場合は、新しいコミットメッセージを作成します。

3. 関連ファイルを名前で指定してステージングします。git add -A や git add . は決して使用しないでください。

4. コミットメッセージを一時ファイルに書き込み、git commit -F でコミットします。

cat > /tmp/odoo-commit-message.txt <<'EOF'
[TAG] module: short description

Optional body line.
EOF
git commit -F /tmp/odoo-commit-message.txt

PowerShell の Set-Content や別のエディターを使うなど、同等の一時ファイルを使った方法であれば問題ありません。最終的なコミットを git commit -F <file> で作成してください。

5. プルリクエストを作成する前に、自分が作成した一連のコミットを、論理的な変更ごとに1つの整理されたコミットへまとめます（OCA ガイドラインを参照）： 世の中にとって、中間の「バグ1を修正」「バグ2を修正」といった履歴は不要です。必要なのは最終的な状態と明確な概要だけです。直近の修正コミットが1つだけなら、通常は（手順2の）git commit --amend で十分です。複数のコミットを1つにまとめる場合は、代わりに対話型リベースを使います。

   git rebase -i HEAD~N   # N = number of commits to fold
   

   1行目には実際の [TAG] module: description メッセージを付けて pick を残し、残りはメッセージを破棄する fixup、またはメッセージを統合する squash にします。

   pick 1949129 [IMP] module: Introduce feature A
   fixup d2cf643 Fix bug 1 of feature A
   fixup 42bd9e8 Fix bug 2 of feature A
   fixup 7f767d5 Fix bug 3 of feature A
   

   いずれの場合も、まだローカルにあり未プッシュのコミット、または自分だけが所有するブランチのコミットのみを書き換えてください。ユーザーに確認せず、共有履歴に対して amend やリベースを実行してはいけません。

6. 作成されたコミットのハッシュと件名を報告します。

pre-commit フックを回避してはいけません。フックが失敗した場合は、問題を修正して変更を再度ステージングし、コミットを作成し直してください。

形式

[TAG] module: short description

Optional body explaining WHY, not what. What is visible in the diff.
Focus on motivation, constraints, and decisions made.

task-XXXX, opw-XXXXXX

件名の規則

• [TAG] module: description — 角括弧内にタグを記載し、その後にモジュール名、コロン、スペース、説明を続けます
• 読みやすさのため、ヘッダー全体（[TAG] module: description）を約50文字に収めます。72文字は厳守すべき上限であり、目標ではありません
• 自己確認：ヘッダーは「if applied, this commit will <header>」に続けたとき、自然な文になる必要があります。例：[IMP] base: prevent to archive users linked to active partners → 「if applied, this commit will prevent to archive users linked to active partners」
• 説明に「bugfix」や「improvements」のような曖昧な単語だけを使ってはいけません。変更の理由がわかる、明確な説明にしてください
• 命令形を使います。「add」「fix」「remove」などとし、「added」「fixes」は使いません
• 末尾にピリオドを付けません
• モジュールには技術的なモジュール名を使います（例：hhc、plc、nhso_stddataset、imc）
• 1つのコミットで複数のモジュールを変更しないようにしてください。モジュールごとにコミットを分け、それぞれを個別に取り消せるようにします。本当に避けられない場合は、モジュールを列挙するか various を使います

タグ

• [FIX] — バグ修正。安定版で使用し、最近の開発版のバグにも使用できます
• [REF] — リファクタリング：機能を大幅に書き換える場合
• [ADD] — 新しいモジュールの追加
• [REM] — 使用されなくなったコード、ビュー、モジュールなどのリソースの削除
• [REV] — コミットの取り消し
• [MOV] — ファイルの移動（内容の変更なし。git mv を使用）
• [REL] — リリースコミット：安定版のメジャー／マイナーバージョン
• [IMP] — 改善：開発版における段階的な変更の多く
• [MERGE] — マージコミット／バグ修正のフォワードポート
• [CLA] — Odoo 個人コントリビューターライセンスへの署名
• [I18N] — 翻訳ファイルの変更
• [PERF] — パフォーマンス改善パッチ
• [CLN] — コードのクリーンアップ
• [LINT] — リンティングの実行

本文のルール

• 件名だけで内容が明らかな場合は、本文を省略します
• 次の場合は本文を記載します：自明でない理由、破壊的変更、移行に関する注意事項、タスクへの参照
• 何をしたかではなく、なぜそうしたかを説明します - 変更内容は差分を見れば分かります。技術的な選択やトレードオフがあった場合に限り、「何をしたか」を詳しく記載し、その選択をした理由を説明します
• 簡潔さだけを目的に、無理に文章を短くする必要はありません。Odoo の公式ガイドラインでは、理由を説明する価値がある場合は、ためらわず詳しく書くよう明示されています。それでも、各行には記載する価値が必要です。差分の言い換えや水増しは避けてください
• 1 行あたり 72 文字で折り返します
• タスク ID は末尾に記載します：task-XXXX、opw-XXXXXX、Fixes #123、Closes #123

絶対に含めないもの

• 「This commit does X」 - 変更内容は差分を見れば分かります
• 「I」、「we」、「now」、「currently」
• あらゆる種類の AI に関する帰属情報：Co-Authored-By: Claude ... のトレーラー、Generated with Claude Code の行、セッションへのリンク。ツールによって追加された場合は、コミット前に削除してください
• 件名ですでに示されている場合、ファイル名やモジュール名を繰り返すこと

プルリクエスト

• タイトル = コミットヘッダー（[TAG] module: description）。1 つの PR につき、論理的な変更は 1 つにします
• 本文では、なぜ変更したのかと、どのように検証したのか（テストコマンド、ビューのスクリーンショットなど）を説明します。何を変更したかは差分で分かります
• 本文には AI に関する帰属情報を一切含めないでください。「Generated with」のフッター、Co-Authored-By、セッションへのリンクは禁止です
• 作成者やレビュアーの行を追加・編集しないでください。作成者はすでに Git に記録されています

例

公式 Odoo Git ガイドラインの例：

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

「有効な文」の自己チェックを示す、ヘッダーのみの例：

[IMP] base: prevent to archive users linked to active partners