mcpField
G
git-workflow

git-workflow

github.com/wyattowalsh开发550 次安装10 周前更新
代码仓库

关于 git-workflow

git-workflow 是面向 Git 日常操作的技能，帮助开发者处理提交、PR、分支策略、冲突、历史分析和回归定位。它按模式提供指导，并要求提交操作先经用户批准。

主要功能

  1. 01生成 Conventional Commit 消息
  2. 02根据分支差异撰写 PR 描述
  3. 03分析并推荐分支策略
  4. 04指导合并冲突处理
  5. 05检索 Git 历史与定位回归

适用场景

  1. 01为暂存差异拟定提交消息
  2. 02整理分支变更并编写 PR 描述
  3. 03分析代码演变及其原始意图
  4. 04通过 bisect 查找引入缺陷的提交

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/wyattowalsh/agents --skill git-workflow

安装后在 Claude Code 中输入/git-workflow确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

data/
branch-strategies.json
conventional-commits.json
evals/
archaeology-implicit.json
bisect-assist.json
branch-strategy.json
commit-message.json
evals.json
negative-control.json
pr-description.json
references/
branch-strategies.md
commit-and-pr-guide.md
history-and-debugging.md
scripts/
check.py
commit-parser.py
diff-summarizer.py
scripts/asset_toolkit/
__init__.py
_shared.py
common.py
package.py
validate_evals.py
validate_hooks.py
validate_skill.py

详细介绍

Git 工作流

Git 操作助手。轻量级、高频使用的工具，适用于提交消息、PR 描述、分支策略、冲突解决、代码考古和二分调试。

范围： 仅限 Git 工作流操作。不适用于代码审查（review）、CI/CD 流水线（devops-engineer）、变更日志或发行说明（changelog-writer），也不用于编写应用代码。

分发

$ARGUMENTS模式
commit根据暂存的差异生成规范提交消息
pr根据分支差异生成 PR 描述
strategy为项目推荐分支策略
conflict指导解决合并冲突
archaeology <file or function>分析 Git 历史以理解代码
bisect协助使用 git bisect 查找引入回归的提交
Empty显示模式菜单及示例

标准术语

在所有模式中始终准确使用以下术语：

术语定义
规范提交结构化提交格式：遵循 Conventional Commits 1.0 的 type(scope): subject
提交类型以下类型之一：feat、fix、docs、style、refactor、perf、test、build、ci、chore、revert
破坏性变更以 ! 结尾或带有 BREAKING CHANGE: 页脚、需要提升主版本号的提交
范围类型后括号中的可选组件名称：feat(auth): ...
主干开发所有开发者向 main/trunk 提交，并使用生命周期较短的功能分支的策略
git-flow使用 develop、feature、release 和 hotfix 分支的策略
github-flow简化策略：main + 功能分支，并通过 PR 合并
冲突标记Git 插入冲突文件中的 <<<<<<<、=======、>>>>>>> 分隔符
归因git blame 注解，显示每行最后一次修改者
代码考古使用 Git 历史命令理解代码存在的原因
二分查找在提交中进行二分搜索，找出引入 bug 的提交
良好/不良提交二分查找术语：良好 = bug 出现之前，不良 = bug 出现之后

模式 1：提交

根据当前暂存的差异生成规范提交消息。

提交步骤
  1. 运行 git diff --cached 获取暂存的变更
  2. 如果没有暂存内容，运行 git diff 并报告：“没有暂存的变更。请先使用 git add 暂存文件。”
  3. 对差异输出运行 uv run python scripts/diff-summarizer.py
  4. 分析差异以确定：
    • 类型：feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert
    • 范围：受影响的组件（根据文件路径、模块名称确定）
    • 主题：祈使语气、小写、不加句号，最多 72 个字符
    • 正文：说明变更内容及原因（每行不超过 72 个字符）
    • 破坏性变更：是否需要 BREAKING CHANGE: 页脚
  5. 参考 data/conventional-commits.json 中的类型选择规则
  6. 展示提交消息并询问：“使用此消息提交吗？[yes / edit / cancel]”
  7. 如果获准，运行 git commit -m "$(cat <<'EOF'\n<message>\nEOF\n)"

模式 2：PR

根据当前分支与基分支之间的差异生成 PR 描述。

PR 步骤
  1. 检测基分支：git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@refs/remotes/origin/@@'（备用值：main）
  2. 运行 git log --oneline <base>..HEAD 列出提交
  3. 对 Git 日志输出运行 uv run python scripts/commit-parser.py
  4. 运行 git diff <base>...HEAD --stat 获取变更统计
  5. 对差异统计运行 uv run python scripts/diff-summarizer.py
  6. 生成 PR 描述，包含：
    • 标题：简短概述，不超过 70 个字符
    • 摘要：用 1-3 个项目符号说明变更内容
    • 变更内容：按解析出的提交类型分组
    • 测试计划：验证步骤检查清单
    • 破坏性变更：如有提交包含破坏性变更，则列出
  7. 展示描述并询问：“使用此内容创建 PR 吗？[yes / edit / skip]”

模式 3：策略

为项目推荐分支策略。

策略步骤
  1. 分析代码仓库：
    • 团队规模：检查 git shortlog -sn --all | wc -l
    • 发布频率：检查标签 git tag -l --sort=-creatordate | head -20
    • 分支数量：git branch -r | wc -l
    • CI/CD 情况：检查是否存在 .github/workflows/、Jenkinsfile、.gitlab-ci.yml
  2. 参考 data/branch-strategies.json 比较策略
  3. 根据项目概况为每种策略评分
  4. 提出建议，包括：
    • 推荐的策略及原因
    • 展示权衡取舍的比较表
    • 如果要从当前方案切换，列出迁移步骤
    • 与团队规模和发布频率的契合度

模式 4：冲突

指导解决合并冲突。

冲突步骤
  1. 运行 git diff --name-only --diff-filter=U 列出存在冲突的文件
  2. 如果没有冲突："未检测到合并冲突。"
  3. 对每个存在冲突的文件：
    • 阅读文件以识别冲突标记
    • 分析双方内容（ours 与 theirs）
    • 检查 git log --merge -p -- <file>，了解产生分歧的变更背景
    • 判断双方各自的意图
  4. 针对每个文件提供解决指导：
    • 双方分别改了什么以及原因
    • 建议的解决方式（保留 ours / 保留 theirs / 合并双方内容 / 重写）
    • 解决冲突后的内容
  5. 询问："应用此解决方案？[yes / edit / skip per file]"
  6. 解决后：提醒运行 git add <files>，然后继续合并或变基

模式 5：考古分析

分析 Git 历史，了解代码存在的原因及其演变过程。

考古分析步骤
  1. 将 $ARGUMENTS[1] 解析为文件路径或函数名
  2. 对于文件路径：
    • 使用 git log --follow --oneline -- <file> 查看完整历史
    • 使用 git log --follow --diff-filter=A -- <file> 查看创建提交
    • 使用 git blame <file> 逐行查看代码归属
  3. 对于函数名：
    • 使用 git log -p --all -S '<function>' -- '*.py' '*.js' '*.ts'（pickaxe 搜索）
    • 如果已知文件，则使用 git log -L :<function>:<file>（函数级日志）
  4. 分析历史记录并回答：
    • 这段代码何时引入，由谁引入？
    • 最初的意图是什么？（从提交消息中判断）
    • 代码如何演变？（关键修改提交）
    • 其他文件中是否有相关变更？
  5. 按时间顺序叙述关键提交及其背景

模式 6：二分查找

协助使用 git bisect 找出引入回归问题的提交。

二分查找步骤
  1. 如果未提供，则询问：
    • 坏提交：存在 Bug 的位置（默认为 HEAD）
    • 好提交：不存在 Bug 的位置
    • 测试命令：如何验证（可选，用于 git bisect run）
  2. 开始二分查找：git bisect start <bad> <good>
  3. 如果提供了测试命令：
    • 运行 git bisect run <command>
    • 从输出中解析出第一个坏提交
  4. 如果采用手动方式：
    • 每一步都说明当前提交的背景
    • 询问："这个提交是好还是坏？"
    • 运行 git bisect good 或 git bisect bad
  5. 二分查找确定提交后：
    • 使用 git show <hash> 显示完整提交
    • 说明该提交改了什么
    • 建议需要调查的方向
  6. 清理：git bisect reset

参考文件

每次只加载一个参考文件。不要将所有参考文件预先加载到上下文中。

文件内容加载时机
references/commit-and-pr-guide.mdConventional commit 格式、PR 模板、差异分析commit 或 pr 模式
references/branch-strategies.md策略比较、迁移路径、团队规模strategy 模式
references/history-and-debugging.md冲突解决、历史考证技巧、二分查找模式conflict、archaeology 或 bisect 模式
数据文件内容加载时机
data/conventional-commits.json包含类型定义的完整规范（结构化数据）commit 模式（脚本输入）
data/branch-strategies.json包含优缺点和团队规模的策略比较strategy 模式（脚本输入）
脚本运行时机
scripts/commit-parser.pypr 模式——将 git 日志解析为结构化 JSON
scripts/diff-summarizer.pycommit 或 pr 模式——汇总差异统计信息

关键规则

  1. 未经用户批准，绝不提交——始终先展示提交信息
  2. 绝不强制推送、执行 reset --hard 或运行破坏性 git 命令
  3. 始终遵循 data/conventional-commits.json 中的规范使用 Conventional Commit 格式
  4. 提交主题必须使用祈使语气、小写、不带句号，且不超过 72 个字符
  5. PR 描述必须将变更与差异中的证据关联起来
  6. bisect 会话结束后，绝不跳过 git bisect reset
  7. archaeology 模式为只读——绝不修改代码或历史记录
  8. 冲突解决时，必须先说明双方的情况，再提出建议
  9. 分支策略必须考虑实际团队规模和发布节奏，而非理想情况
  10. 脚本将 JSON 输出到 stdout——以编程方式解析，绝不使用正则表达式
  11. 提交前先暂存：如果 diff --cached 为空，不要捏造提交信息
  12. 不要生成变更日志或发行说明——转交给 changelog-writer

评论

支持 Markdown