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. 使用祈使语气：用 add，不要用 added。
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 中的 Testing Plan 部分， 包括通过的 pytest 结果摘要。
• 不要在 GitHub 上合并。按照设计，所有针对 main 的 PR 上的 Do Not Merge on GitHub 检查都会失败；维护者会落地这项更改，然后将其同步回仓库。之后，GitHub 会将 PR 显示为已关闭并带有 merged 标签，而不是显示为已合并；落地的提交会保留原始作者信息。这个红色检查是预期现象，无需修复。