ECC Git 工作流规则解析Conventional Commits 提交规范、Co-Authored-By 归因控制与 PR 实战流程【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本文以 ECCThe agent harness performance optimization system仓库中的 common-git-workflow.md 规则文件为核心完整解析其定义的 Conventional Commits 提交格式、8 种提交类型、Claude 提交归因Co-Authored-By的默认关闭机制以及五步 PR 工作流程。读完本文你可以直接照搬这套规范约束团队或 AI Agent 的 Git 操作并理解 ECC 安装器是如何在源码层面保证不覆盖用户显式选择的。规则文件的定位与生效机制该规则位于 ECC 的 Cursor 规则层.cursor/rules/目录其 YAML frontmatter 为--- description: Git workflow: conventional commits, PR process alwaysApply: true ---两个关键点决定了它的行为alwaysApply: true该规则不是按需触发的而是对 Cursor 会话中所有任务始终生效因此它适合作为提交信息格式和 PR 流程这类全局硬约束。通用common前缀文件名common-git-workflow.md表明它属于 ECC 规则的通用层。按照 rules/README.md 的分层设计rules/common/存放与语言无关的通用原则该规则的内容源文件即 rules/common/git-workflow.md而rules/typescript/、rules/golang/等语言目录可覆盖其中与语言习惯冲突的默认值冲突时特定优先于通用。.cursor/rules/下的common-git-workflow.md与rules/common/git-workflow.md内容基本一致只是尾部引用链接的相对路径不同前者指向 Cursor 规则体系内的 development workflow 规则后者指向 development-workflow.md。安装方式上ECC 官方文档给出的通用做法是保留目录结构整体拷贝切勿用cp -r rules/common/*打平同名文件会互相覆盖# 用户级 Claude 安装ECC 命名空间 mkdir -p ~/.claude/rules/ecc cp -r rules/common ~/.claude/rules/ecc/ # 项目级安装 mkdir -p .claude/rules/ecc cp -r rules/common .claude/rules/ecc/也可以直接使用安装脚本./install.sh typescript自动处理 common 层与语言层。Commit Message 格式类型、结构与校验边界规则给出的提交信息格式为type: description optional body允许的 8 种类型为feat, fix, refactor, docs, test, chore, perf, ci。这 8 种类型覆盖了日常开发的绝大多数场景feat表示新功能fix表示缺陷修复refactor表示不改变外部行为的结构调整docs/test/chore/perf/ci分别对应文档、测试、杂务、性能优化与 CI 变更。可选的 body 用于补充为什么改而不仅是改了什么。与仓库实际 commitlint 配置的对照该规则并非孤立存在——仓库自身用 commitlint.config.js 对提交信息做了机器校验值得对照阅读module.exports { extends: [commitlint/config-conventional], rules: { type-enum: [2, always, [ feat, fix, docs, style, refactor, perf, test, chore, ci, build, revert ]], subject-case: [2, never, [sentence-case, start-case, pascal-case, upper-case]], header-max-length: [2, always, 100] } };可以读出三个与规则文件互补的约束细节类型白名单更宽commitlint 的type-enum在规则的 8 种之外还允许style、build、revert三种severity 为 2 即 error 级别违反则 CI 失败。subject 大小写约束subject-case规则禁止 sentence-case、start-case、pascal-case、upper-case 四种写法即 subject 应以小写命令式开头如fix login redirect loop而非Fix login redirect loop。header 长度上限 100 字符首行type subject不得超过 100 字符超长内容应放入 body。如果你希望在自己的项目里复用这套校验ECC 的 git-workflow skill 还给出了配套的提交模板方案在仓库根目录创建.gitmessage文件并执行git config commit.template .gitmessage把类型列表和书写要求固化成编辑器里的提示注释。该 skill 同时给出了正反例对比# BAD: 含糊、无上下文 git commit -m fixed stuff # GOOD: 清晰、具体、解释原因 git commit -m fix(api): retry requests on 503 Service Unavailable The external API occasionally returns 503 errors during peak hours. Added exponential backoff retry logic with max 3 attempts. Closes #123Co-Authored-By 归因控制默认关闭且绝不覆盖用户选择规则中有一段专门说明 AI 提交归因的约定ECC-managed installs setincludeCoAuthoredBy: falsein~/.claude/settings.json, so commits carry noCo-Authored-Bytrailer by default. To keep Claude attribution, setincludeCoAuthoredBy: trueor configureattribution; ECC never overwrites an explicit choice.含义是在 ECC 托管的安装流程中ECC 会向~/.claude/settings.json写入includeCoAuthoredBy: false使 Claude Code 产生的提交默认不附带Co-Authored-By尾注。若你希望保留 Claude 归因可显式设置includeCoAuthoredBy: true或改用attribution配置ECC 承诺永远不会覆盖用户的显式选择。这段约定的实现逻辑在 scripts/lib/claude-commit-attribution.js 中源码注释把设计决策讲得非常清楚两个配置键的关系attribution: { commit, pr }是当前生效的配置且优先级更高includeCoAuthoredBy自 Claude Code 2.1.x 起已弃用但仍被兼容并且是旧版本唯一能识别的键。为什么写的是弃用键ECC 选择写入includeCoAuthoredBy而非attribution因为未知键会导致 settings 校验失败——如果对旧版 Claude Code 写入attribution会直接弄坏用户的设置文件。显式意图判定hasExplicitCommitAttributionPreference()检查两个键——只要includeCoAuthoredBy是布尔值或attribution对象中定义了commit/pr任一字段即视为用户的刻意选择。只填空、不覆盖withCommitAttributionDisabled()只在用户没有显式偏好时追加[COAUTHOR_SETTING_KEY]: false否则原样返回function withCommitAttributionDisabled(settings) { if (hasExplicitCommitAttributionPreference(settings)) { return settings; } return { ...settings, [COAUTHOR_SETTING_KEY]: false, }; }这一默认关闭 尊重显式选择的策略本质是避免工具链替用户做不可逆的决定归因信息一旦写进 git 历史就无法干净移除。相关行为在 tests/lib/claude-commit-attribution.test.js 中有测试覆盖。Pull Request 工作流程五步清单及其命令化实现规则对创建 PR 给出五步操作清单分析完整提交历史not just latest commit——PR 描述应基于整个分支相对 base 的全部变更而不是最后一次 commit用git diff [base-branch]...HEAD查看所有变更——注意这里是三点语法base...HEAD表示从两分支的共同祖先到 HEAD 的差异正是 PR 语义下本分支引入了什么的准确表达起草全面的 PR 摘要附上带 TODO 的测试计划——明确测试了什么、还欠哪些验证新分支首次推送使用-u标志——git push -u origin branch建立上游跟踪后续git push无需再带远端名。这五步在 ECC 的 commands/pr.md即/pr命令中被展开为一条六阶段流水线是规则在 Agent 场景下的完整落地Phase 1 VALIDATE用git branch --show-current、git status --short、git log origin/base..HEAD --oneline做前置检查不在 base 分支、工作区不干净、无领先提交、已存在 PR任一命中即中止并给出明确提示Phase 2 DISCOVER按.github/PULL_REQUEST_TEMPLATE/→.github/PULL_REQUEST_TEMPLATE.md→.github/pull_request_template.md→docs/pull_request_template.md的顺序探测 PR 模板用git log origin/base..HEAD --format%h %s --reverse分析提交序列决定 PR 标题多类型时取主导类型标题沿用 conventional commit 前缀用git diff origin/base..HEAD --stat和--name-only将变更文件归类为 source/tests/docs/config/migrationsPhase 3 PUSH执行git push -u origin HEAD若远端分叉则git fetch origin git rebase origin/base后重推rebase 冲突则停止并告知用户Phase 4 CREATE有模板则填充模板不删除任何小节不适用处写 N/A无模板则使用内置格式Summary / Changes / Files Changed / Testing / Related Issues 五节最终经gh pr create --title ... --base ... --body ...创建Phase 5 VERIFYgh pr view --json number,url,title,state,...与gh pr checks回读校验Phase 6 OUTPUT按固定格式回报 PR 编号、URL、分支方向、增删行数、CI 状态与后续操作。几个值得注意的工程细节强推只允许--force-with-lease/pr命令的 Edge Cases 明确写了rebase 后需要 force push 时使用git push --force-with-leasenever--force避免覆盖他人的新提交大 PR 预警变更超过 20 个文件时命令会主动建议拆分与 git-workflow skill 中PR 理想规模小于 500 行、聚焦单一功能的反模式清单一致环境依赖/pr依赖 GitHub CLI未安装或未gh auth login时会停止并给出提示。与 Development Workflow 规则的前置衔接规则文件尾部的引用块指向git 操作之前的完整开发流程For the full development process (planning, TDD, code review) before git operations, see the development workflow rule.对应的 common-development-workflow.md 将 git 提交定义为开发管线的最后一步完整管线为Plan First先用 planner agent 产出实现计划识别依赖与风险拆分为阶段TDD Approachtdd-guide agent 主导先写失败测试RED→ 实现至通过GREEN→ 重构IMPROVE并验证 80% 覆盖率Code Review写完代码立即用 code-reviewer agent 审查必须处理 CRITICAL/HIGH 问题尽量修复 MEDIUMCommit Push写详细的提交信息、遵循 conventional commits 格式详见 git workflow 规则——即本文所讲的这条规则。也就是说common-git-workflow管的是提交和 PR 应该长什么样common-development-workflow管的是提交之前应该发生什么两条alwaysApply: true的规则共同约束 Agent 的完整交付行为。实战速查表事项规则要求 / 命令提交格式type: description 可选 body允许类型feat, fix, refactor, docs, test, chore, perf, cicommitlint 另放行 style/build/revertsubject 写法小写命令式禁止 sentence/start/pascal/upper-case首行 ≤ 100 字符AI 归因默认无Co-Authored-By需要则设includeCoAuthoredBy: true或attribution查看 PR 全量变更git diff [base-branch]...HEAD首次推送新分支git push -u origin branch分叉后同步git fetch origin git rebase origin/base冲突则停下人工处理需要强推时只用git push --force-with-lease提交历史参考git log origin/base..HEAD --format%h %s --reverse适用前提说明归因相关的~/.claude/settings.json约定仅作用于 ECC 托管安装的 Claude Code 用户且includeCoAuthoredBy在 Claude Code 2.1.x 之后属于弃用但兼容的键commitlint 校验配置commitlint.config.js约束的是 ECC 仓库自身的提交而规则文件中 8 种类型是面向用户项目的建议集合。如果你要把这套规则移植到其他项目建议同时引入 commitlint 配置把建议升级为 CI 中的硬校验。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC Git 工作流规则解析：Conventional Commits 提交规范、Co-Authored-By 归因控制与 PR 实战流程
ECC Git 工作流规则解析Conventional Commits 提交规范、Co-Authored-By 归因控制与 PR 实战流程【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本文以 ECCThe agent harness performance optimization system仓库中的 common-git-workflow.md 规则文件为核心完整解析其定义的 Conventional Commits 提交格式、8 种提交类型、Claude 提交归因Co-Authored-By的默认关闭机制以及五步 PR 工作流程。读完本文你可以直接照搬这套规范约束团队或 AI Agent 的 Git 操作并理解 ECC 安装器是如何在源码层面保证不覆盖用户显式选择的。规则文件的定位与生效机制该规则位于 ECC 的 Cursor 规则层.cursor/rules/目录其 YAML frontmatter 为--- description: Git workflow: conventional commits, PR process alwaysApply: true ---两个关键点决定了它的行为alwaysApply: true该规则不是按需触发的而是对 Cursor 会话中所有任务始终生效因此它适合作为提交信息格式和 PR 流程这类全局硬约束。通用common前缀文件名common-git-workflow.md表明它属于 ECC 规则的通用层。按照 rules/README.md 的分层设计rules/common/存放与语言无关的通用原则该规则的内容源文件即 rules/common/git-workflow.md而rules/typescript/、rules/golang/等语言目录可覆盖其中与语言习惯冲突的默认值冲突时特定优先于通用。.cursor/rules/下的common-git-workflow.md与rules/common/git-workflow.md内容基本一致只是尾部引用链接的相对路径不同前者指向 Cursor 规则体系内的 development workflow 规则后者指向 development-workflow.md。安装方式上ECC 官方文档给出的通用做法是保留目录结构整体拷贝切勿用cp -r rules/common/*打平同名文件会互相覆盖# 用户级 Claude 安装ECC 命名空间 mkdir -p ~/.claude/rules/ecc cp -r rules/common ~/.claude/rules/ecc/ # 项目级安装 mkdir -p .claude/rules/ecc cp -r rules/common .claude/rules/ecc/也可以直接使用安装脚本./install.sh typescript自动处理 common 层与语言层。Commit Message 格式类型、结构与校验边界规则给出的提交信息格式为type: description optional body允许的 8 种类型为feat, fix, refactor, docs, test, chore, perf, ci。这 8 种类型覆盖了日常开发的绝大多数场景feat表示新功能fix表示缺陷修复refactor表示不改变外部行为的结构调整docs/test/chore/perf/ci分别对应文档、测试、杂务、性能优化与 CI 变更。可选的 body 用于补充为什么改而不仅是改了什么。与仓库实际 commitlint 配置的对照该规则并非孤立存在——仓库自身用 commitlint.config.js 对提交信息做了机器校验值得对照阅读module.exports { extends: [commitlint/config-conventional], rules: { type-enum: [2, always, [ feat, fix, docs, style, refactor, perf, test, chore, ci, build, revert ]], subject-case: [2, never, [sentence-case, start-case, pascal-case, upper-case]], header-max-length: [2, always, 100] } };可以读出三个与规则文件互补的约束细节类型白名单更宽commitlint 的type-enum在规则的 8 种之外还允许style、build、revert三种severity 为 2 即 error 级别违反则 CI 失败。subject 大小写约束subject-case规则禁止 sentence-case、start-case、pascal-case、upper-case 四种写法即 subject 应以小写命令式开头如fix login redirect loop而非Fix login redirect loop。header 长度上限 100 字符首行type subject不得超过 100 字符超长内容应放入 body。如果你希望在自己的项目里复用这套校验ECC 的 git-workflow skill 还给出了配套的提交模板方案在仓库根目录创建.gitmessage文件并执行git config commit.template .gitmessage把类型列表和书写要求固化成编辑器里的提示注释。该 skill 同时给出了正反例对比# BAD: 含糊、无上下文 git commit -m fixed stuff # GOOD: 清晰、具体、解释原因 git commit -m fix(api): retry requests on 503 Service Unavailable The external API occasionally returns 503 errors during peak hours. Added exponential backoff retry logic with max 3 attempts. Closes #123Co-Authored-By 归因控制默认关闭且绝不覆盖用户选择规则中有一段专门说明 AI 提交归因的约定ECC-managed installs setincludeCoAuthoredBy: falsein~/.claude/settings.json, so commits carry noCo-Authored-Bytrailer by default. To keep Claude attribution, setincludeCoAuthoredBy: trueor configureattribution; ECC never overwrites an explicit choice.含义是在 ECC 托管的安装流程中ECC 会向~/.claude/settings.json写入includeCoAuthoredBy: false使 Claude Code 产生的提交默认不附带Co-Authored-By尾注。若你希望保留 Claude 归因可显式设置includeCoAuthoredBy: true或改用attribution配置ECC 承诺永远不会覆盖用户的显式选择。这段约定的实现逻辑在 scripts/lib/claude-commit-attribution.js 中源码注释把设计决策讲得非常清楚两个配置键的关系attribution: { commit, pr }是当前生效的配置且优先级更高includeCoAuthoredBy自 Claude Code 2.1.x 起已弃用但仍被兼容并且是旧版本唯一能识别的键。为什么写的是弃用键ECC 选择写入includeCoAuthoredBy而非attribution因为未知键会导致 settings 校验失败——如果对旧版 Claude Code 写入attribution会直接弄坏用户的设置文件。显式意图判定hasExplicitCommitAttributionPreference()检查两个键——只要includeCoAuthoredBy是布尔值或attribution对象中定义了commit/pr任一字段即视为用户的刻意选择。只填空、不覆盖withCommitAttributionDisabled()只在用户没有显式偏好时追加[COAUTHOR_SETTING_KEY]: false否则原样返回function withCommitAttributionDisabled(settings) { if (hasExplicitCommitAttributionPreference(settings)) { return settings; } return { ...settings, [COAUTHOR_SETTING_KEY]: false, }; }这一默认关闭 尊重显式选择的策略本质是避免工具链替用户做不可逆的决定归因信息一旦写进 git 历史就无法干净移除。相关行为在 tests/lib/claude-commit-attribution.test.js 中有测试覆盖。Pull Request 工作流程五步清单及其命令化实现规则对创建 PR 给出五步操作清单分析完整提交历史not just latest commit——PR 描述应基于整个分支相对 base 的全部变更而不是最后一次 commit用git diff [base-branch]...HEAD查看所有变更——注意这里是三点语法base...HEAD表示从两分支的共同祖先到 HEAD 的差异正是 PR 语义下本分支引入了什么的准确表达起草全面的 PR 摘要附上带 TODO 的测试计划——明确测试了什么、还欠哪些验证新分支首次推送使用-u标志——git push -u origin branch建立上游跟踪后续git push无需再带远端名。这五步在 ECC 的 commands/pr.md即/pr命令中被展开为一条六阶段流水线是规则在 Agent 场景下的完整落地Phase 1 VALIDATE用git branch --show-current、git status --short、git log origin/base..HEAD --oneline做前置检查不在 base 分支、工作区不干净、无领先提交、已存在 PR任一命中即中止并给出明确提示Phase 2 DISCOVER按.github/PULL_REQUEST_TEMPLATE/→.github/PULL_REQUEST_TEMPLATE.md→.github/pull_request_template.md→docs/pull_request_template.md的顺序探测 PR 模板用git log origin/base..HEAD --format%h %s --reverse分析提交序列决定 PR 标题多类型时取主导类型标题沿用 conventional commit 前缀用git diff origin/base..HEAD --stat和--name-only将变更文件归类为 source/tests/docs/config/migrationsPhase 3 PUSH执行git push -u origin HEAD若远端分叉则git fetch origin git rebase origin/base后重推rebase 冲突则停止并告知用户Phase 4 CREATE有模板则填充模板不删除任何小节不适用处写 N/A无模板则使用内置格式Summary / Changes / Files Changed / Testing / Related Issues 五节最终经gh pr create --title ... --base ... --body ...创建Phase 5 VERIFYgh pr view --json number,url,title,state,...与gh pr checks回读校验Phase 6 OUTPUT按固定格式回报 PR 编号、URL、分支方向、增删行数、CI 状态与后续操作。几个值得注意的工程细节强推只允许--force-with-lease/pr命令的 Edge Cases 明确写了rebase 后需要 force push 时使用git push --force-with-leasenever--force避免覆盖他人的新提交大 PR 预警变更超过 20 个文件时命令会主动建议拆分与 git-workflow skill 中PR 理想规模小于 500 行、聚焦单一功能的反模式清单一致环境依赖/pr依赖 GitHub CLI未安装或未gh auth login时会停止并给出提示。与 Development Workflow 规则的前置衔接规则文件尾部的引用块指向git 操作之前的完整开发流程For the full development process (planning, TDD, code review) before git operations, see the development workflow rule.对应的 common-development-workflow.md 将 git 提交定义为开发管线的最后一步完整管线为Plan First先用 planner agent 产出实现计划识别依赖与风险拆分为阶段TDD Approachtdd-guide agent 主导先写失败测试RED→ 实现至通过GREEN→ 重构IMPROVE并验证 80% 覆盖率Code Review写完代码立即用 code-reviewer agent 审查必须处理 CRITICAL/HIGH 问题尽量修复 MEDIUMCommit Push写详细的提交信息、遵循 conventional commits 格式详见 git workflow 规则——即本文所讲的这条规则。也就是说common-git-workflow管的是提交和 PR 应该长什么样common-development-workflow管的是提交之前应该发生什么两条alwaysApply: true的规则共同约束 Agent 的完整交付行为。实战速查表事项规则要求 / 命令提交格式type: description 可选 body允许类型feat, fix, refactor, docs, test, chore, perf, cicommitlint 另放行 style/build/revertsubject 写法小写命令式禁止 sentence/start/pascal/upper-case首行 ≤ 100 字符AI 归因默认无Co-Authored-By需要则设includeCoAuthoredBy: true或attribution查看 PR 全量变更git diff [base-branch]...HEAD首次推送新分支git push -u origin branch分叉后同步git fetch origin git rebase origin/base冲突则停下人工处理需要强推时只用git push --force-with-lease提交历史参考git log origin/base..HEAD --format%h %s --reverse适用前提说明归因相关的~/.claude/settings.json约定仅作用于 ECC 托管安装的 Claude Code 用户且includeCoAuthoredBy在 Claude Code 2.1.x 之后属于弃用但兼容的键commitlint 校验配置commitlint.config.js约束的是 ECC 仓库自身的提交而规则文件中 8 种类型是面向用户项目的建议集合。如果你要把这套规则移植到其他项目建议同时引入 commitlint 配置把建议升级为 CI 中的硬校验。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考