Git Operations for adk-python
Commit Message Format
Use Conventional Commits:
<type>(<scope>): <description>
Types
feat: New featurefix: Bug fixdocs: Documentation onlystyle: Formatting, no code changerefactor: Code restructure without behavior changeperf: Performance improvementtest: Adding/updating testschore: Build, config, dependenciesci: CI/CD changes
Description Phrasing
CRITICAL: The subject line must answer why, not just what. A reviewer reading only the subject should understand the motivation.
- State the outcome, not the mechanics:
- Good:
Fix race condition when two agents write to same session - Bad:
Update session.py to add lock
- Good:
- Name the capability added, not the implementation:
- Good:
Support parallel tool execution in workflows - Bad:
Add asyncio.gather call in execute_tools_node
- Good:
- For refactors, state the reason, not just the action:
- Good:
Make graph public for dev UI serialization - Bad:
Make graph a public field on new Workflow
- Good:
- For bug fixes, state what was broken:
- Good:
Prevent duplicate events when resuming HITL - Bad:
Check interrupt_id before appending
- Good:
Detailed Commit Messages
Promote detailed commit messages by including a short, concrete explanation in the body:
- For features: Give a sample usage or explain the new capability.
- For fixes: Explain what caused the error and how the fix addresses it.
Example (Feature):
feat(workflow): Support JSON string parsing in schema validation
Automatically parse JSON strings into dicts or Pydantic models when input_schema or output_schema is defined on a node.
Example (Fix):
fix(sessions): Prevent duplicate events when resuming HITL
The interrupt_id was not checked before appending, causing duplicates if the user resumed multiple times. Added a check to ignore already processed interrupts.
Self-check before committing: read your subject line and ask "does this tell me why someone made this change?" If it only describes what changed, rewrite it.
Rules
- Imperative mood - "Add feature" not "Added feature".
- Capitalize first letter of description (for release-please changelog).
- No period at end of subject line.
- 50 char limit on subject line when possible, max 72.
- Use body for context - Add a blank line then explain why, not how, when the subject alone isn't enough.
- Reference GitHub issues - If the commit fixes a GitHub issue, include "Fixes #
" or "Closes # " (or the full issue URL if cross-repository) in the commit message body.
Examples
feat(agents): Support App pattern with lifecycle plugins
fix(sessions): Prevent memory leak on concurrent session cleanup
refactor(tools): Unify env var checks across tool implementations
docs: Add contributing guide for first-time contributors
Pre-commit Hooks
[!IMPORTANT] Before performing any commit, check if
pre-commitis installed and configured with the expected hooks (isort,pyink,addlicense,mdformat). If not, remind the user to set up pre-commit hooks using theadk-setupskill.