不能直接跳过；必须通过外部机制干预：pre-merge-commit钩子仅在非fast-forward合并提交阶段触发且无法撤销已发生的文件变更，真正可靠的是服务端pre-receive钩子拦截推送，或CI分支保护规则强制测试通过后才允许合并。
git merge 时怎么跳过没通过测试的分支？
不能直接跳过。Git 本身不检查测试结果，git merge 只做内容合并，不运行任何命令。所谓“根据测试结果决定是否合并”，必须靠外部机制介入——要么在 git merge 前手动验证，要么用钩子（hook）或 CI 工具拦截。
pre-merge hook 能否阻止合并？
Git 没有原生的 pre-merge hook。最接近的是 pre-commit（只对本地提交生效）和 pre-push（能拦 push，但拦不住本地 merge）。真正能干预 merge 行为的，只有 pre-merge-commit 钩子——但它只在 fast-forward 合并失败、进入合并提交阶段时触发，且**仅作用于当前工作区已产生的合并结果**，无法回退已发生的文件变更。
-
pre-merge-commit运行时，冲突已解决、暂存区已更新，它只能 abort 当前提交，不能撤销 merge 操作本身 - 如果你在
feature分支上执行git merge main，且无冲突，Git 直接 fast-forward，这个钩子根本不会运行 - 想统一拦截所有 merge 动作，得靠 wrapper 脚本替代原生命令，比如 alias
git safe-merge = "!f() { npm test && git merge \"$1\"; }; f"
CI 工具里跑测试再合并，靠谱吗？
靠谱，但要注意“谁在哪个环境执行”。GitHub/GitLab 的 PR/MR 流程中，测试是在 CI 环境（如 GitHub Actions）里跑的，结果只影响是否允许点击「Merge」按钮，不影响本地 git merge 命令的行为。
Git Changelog Generator
下载
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
- 本地执行
git merge feature/login仍会立刻完成，无论 CI 是否通过 - CI 通过只是给 PR 加个绿色勾，服务端不会自动执行
git merge——除非你额外配置了 auto-merge 或 merge queue - 若团队要求“仅 CI 通过后才可合并”，必须配合分支保护规则（如 GitHub 的
Require status checks to pass before merging），否则开发者仍可绕过
为什么不用 git worktree + 本地测试脚本组合？
这个组合其实很实用，但容易被忽略关键约束：worktree 之间共享同一个 .git，所以 git status、git log 是全局的，而测试脚本必须明确指定工作目录上下文。
- 例如，在
../myproject-test工作树中运行npm test，必须确保package.json和依赖路径正确，不能误用主工作树的 node_modules - 常见错误是脚本里写死
cd ..或漏掉--prefix参数，导致测试实际跑在错误分支上 - 推荐做法：用
git -C /path/to/worktree test-command显式指定路径，避免 cd 带来的副作用
真正的难点不在工具链拼接，而在于“测试通过”的定义是否稳定——比如单元测试通过但集成测试超时，或者测试依赖的 mock 数据版本不一致。这些边界情况不会被任何钩子自动识别，得靠人盯日志或加断言校验。
