adk-git

コミットとプルリクエストの規約

コミットメッセージの形式

Conventional Commits：

<type>(<scope>): <description>

タイプによって、コミットが CHANGELOG.md のどこに記載されるかが決まります。release-please はマージ済みコミットの件名から変更履歴を生成するため、誤ったタイプを指定すると、変更が誤った見出しの下に記載されたり、リリースノートから完全に除外されたりします。

タイプ	変更履歴のセクション
feat	機能
fix	バグ修正
perf	パフォーマンスの改善
docs	ドキュメント
refactor、test、build、ci、style、chore	非表示、記載なし

この対応関係は .github/release-please-config.json に記載されています。ここに記載されていないタイプでは、変更履歴に何も記載されません。

スコープは省略可能です。アンダースコアを含まない短いモジュール名を使うか（fix(cli):、feat(a2a):、fix(sessions):）、省略してください。

件名

変更した行ではなく、変更の理由を書きます。件名だけを読んだレビュアーにも、変更の動機が伝わるようにしてください。

書き方	避ける書き方
fix(sessions): prevent duplicate events when resuming HITL	fix(sessions): check interrupt_id before appending
feat(workflow): support parallel tool execution	feat(workflow): add asyncio.gather call in execute_tools_node
refactor: make graph public for dev UI serialization	refactor: make graph a public field on Workflow

ルール：

1. 命令形にします。added ではなく add を使います。
2. コロンの後の最初の単語は小文字にします。release-please は件名をそのまま CHANGELOG.md にコピーします。マージ済みコミットの大半は小文字で始まるため、大文字にすると一行だけ目立ってしまいます。
3. 末尾にピリオドを付けません。
4. 件名はおよそ72文字以内にします。強制されるわけではありませんが、各コミットは変更履歴の一行として表示されます。
5. イシューへの参照は件名ではなく本文に記載します。Fixes #1234 または Closes #1234 を使うか、別のリポジトリにあるイシューの場合はイシューの完全なURLを記載します。

セルフチェック：件名を読み返し、変更の理由が書かれているか確認してください。編集内容だけを示している場合は、書き直してください。

コミット本文

空行を挿入してから、具体的な説明を簡潔に記載します。機能追加の場合は、新しい機能または使用例を示します。修正の場合は、障害の原因と、その変更でどのように対処するかを説明します。

feat(workflow): support JSON string parsing in schema validation

Parse JSON strings into dicts or Pydantic models when input_schema or
output_schema is defined on a node.

fix(sessions): prevent duplicate events when resuming HITL

interrupt_id was not checked before appending, so resuming twice appended the
same event twice. Ignore interrupts that were already processed.

Fixes #1234

コミット前

pre-commit はステージ済みファイルを整形してチェックします。同じフックがすべてのプルリクエストで CI でも実行されるため、フックをスキップして作成したコミットは CI で失敗します。

pre-commit install                  # once per clone
pre-commit run --files {paths}      # check only what changed

フックには isort、pyink、addlicense、mdformat、ruff、codespell、およびリポジトリ固有のコンプライアンスチェックが含まれます。.pre-commit-config.yaml を参照してください。pre-commit がインストールされていない場合は、整形されていないコードをコミットするのではなく、ユーザーに adk-setup スキルを案内してください。

プルリクエスト

• ドキュメントの軽微な修正や誤字修正を除き、すべての PR に関連する Issue が必要です。 PR の説明に Closes: #{issue_number} を記載するか、Issue テンプレートに沿って問題と解決策をインラインで説明してください。
• .github/pull_request_template.md のテスト計画セクションに、pytest の合格結果の概要を含めて記入してください。
• GitHub でマージしないでください。Do Not Merge on GitHub チェックは、設計上 main へのすべての PR で失敗します。メンテナーが変更を取り込み、リポジトリに同期します。その後、GitHub では PR がマージ済みではなく、merged ラベル付きのクローズ済みとして表示され、取り込まれたコミットには元の作成者情報が保持されます。このチェックが赤くなるのは想定どおりであり、修正する必要はありません。