mcpField
M
merge-base-branch

merge-base-branch

github.com/morphet81开发083 次安装24 周前更新
代码仓库

关于 merge-base-branch

merge-base-branch 是一项将用户选择的基础分支合并到当前 Git 分支，并运行 lint、覆盖率测试和构建的技能。它还引导分支核验、冲突解决，并汇总流程中创建的提交。

主要功能

  1. 01识别并选择基础分支
  2. 02获取并合并所选分支
  3. 03引导解决合并冲突
  4. 04运行 lint、覆盖率测试和构建
  5. 05汇总结果与新建提交

适用场景

  1. 01将功能分支与基础分支同步
  2. 02按引导流程解决合并冲突
  3. 03合并后运行本地质量检查
  4. 04确认合并及检查结果

安装

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

$npx skills add https://github.com/morphet81/cheat-sheets --skill merge-base-branch

安装后在 Claude Code 中输入/merge-base-branch确认已加载。

详细介绍

将选定的基分支合并到当前分支，并确保最终通过 lint 检查、完整测试覆盖率和构建。适用于需要让分支与其父分支完全同步，并在本地通过 CI 质量检查的场景。

用法：

  • /merge-base-branch — 执行下方完整工作流

前置条件：

  • 仓库根目录必须是一个位于命名分支上的 git 检出（不能处于分离的 HEAD 状态）。
  • 如果项目使用 Node/npm，package.json 必须定义 lint、test:coverage 和 build 脚本。如果缺少 package.json 或其中缺少任一脚本，请报告缺失项并停止（不得在未执行规定检查的情况下合并或继续）。

说明：

  1. 当前分支：

    • 运行 git branch --show-current。如果处于分离的 HEAD 状态，请告知用户并停止。

  2. 确定基分支候选项，然后让用户选择：

    • 首先，如果仓库根目录存在 .agent，读取其中的 baseBranch=<value>。如果存在该值，它就是检测到的候选项。
    • 否则，根据 git 推断：运行 git merge-base --fork-point main HEAD、git merge-base --fork-point master HEAD 和 git merge-base --fork-point develop HEAD。任何能返回提交的分支名都算匹配项。如果恰好有一个匹配项，它就是检测到的候选项。如果有多个匹配项，按优先级选择：main、master、develop。如果没有匹配项，则不设置检测到的候选项。
    • 使用 AskUserQuestion 让用户选择要合并的基分支。始终将 main 作为选项。若检测到的候选项已设置且不是 main，则将其作为选项。若 master 和 develop 存在于 origin 上（或本地），则也将它们作为选项。为每个选项添加简短标签（例如“根据历史记录检测到：develop”）。等待用户回答；所选分支即为 <base-branch>。

  3. 验证基分支并获取更新：

    • 使用 git rev-parse --verify origin/<base-branch> 验证；若失败，则使用 git rev-parse --verify <base-branch> 验证。若两者都不存在，请告知用户并停止。
    • 运行 git fetch origin <base-branch>。若失败，显示错误并停止。

  4. 如果基分支已是最新状态，则停止：

    • 将 <merge-ref> 设为获取更新后存在的 origin/<base-branch>；否则设为仅存在于本地的 <base-branch>。
    • 运行 git rev-list --count HEAD..<merge-ref>（或等效命令：检查 git log --oneline HEAD..<merge-ref> 是否没有提交）。
    • 如果计数为 0，告知用户当前分支已包含来自 <merge-ref> 的所有内容，无需合并。如果工作区不干净，请说明仍有未提交的更改。停止（此工作流中不要提交 WIP、合并或运行 lint、测试和构建）。

  5. 在合并前提交所有未提交的工作：

    • 如果 git status 显示没有需要提交的未暂存、已暂存或未跟踪更改，则跳至第 6 步。
    • 否则暂存并提交工作区中的所有内容（不限于当前会话中修改的文件）。如果差异明显包含不同的逻辑块（例如按功能领域或目录划分），则拆分为多个提交；每个提交都应有清晰的提交信息。使用 git add 选择性暂存（或使用 git add -p）来创建有条理的提交；存在多个不同的逻辑块时，不要将无关工作压入同一个提交。

  6. 合并基分支：

    • 运行 git merge origin/<base-branch> --no-edit（只有在不存在 origin/<base-branch>、但本地分支存在时，才使用 git merge <base-branch> --no-edit）。
    • 如果合并成功，简要概述已合并的提交。

  7. 解决冲突并完成合并：

    • 如果存在冲突：使用 git diff --name-only --diff-filter=U 列出冲突文件，解决每个文件中的冲突（移除冲突标记，并根据意图进行合并或选择——上游修复优先保留基分支版本，功能代码保留当前分支版本），然后对每个已解决的文件运行 git add，并运行 git merge --continue --no-edit，直到合并完成。

  8. Lint：

    • 在仓库根目录运行 npm run lint。修复所有报告的问题；反复运行，直到通过。

  9. Lint 后提交（如有更改）：

    • 如果 Lint 修复（或格式化程序造成的变更）修改了文件，请使用恰当的提交信息进行提交（如果涉及多个独立改动，可创建一个或多个提交）。

  10. 运行带覆盖率的测试：

    • 运行 npm run test:coverage。如果失败，请查看覆盖率报告和所有失败输出；添加或调整测试，直到所有代码行的覆盖率都达到 100%（以项目和工具的要求为准）。反复运行并迭代，直到命令成功。

  11. 提交测试／覆盖率相关更改：

    • 提交步骤 10 中的任何测试或源代码更改，并使用清晰的提交信息。

  12. 构建：

    • 运行 npm run build。修复编译器／打包工具错误；反复运行，直到通过。

  13. 提交构建修复（如有）：

    • 如果步骤 12 产生了文件更改，请提交。

**用户摘要：**使用的基础分支、合并结果（或“已是最新”）、Lint／测试／构建结果，以及本次运行中创建的提交列表。

评论

支持 Markdown