合并前必须自动校验分支状态：先用git status --porcelain确认工作区和暂存区为空，再用git rev-parse head与远程hash比对同步性，最后用git merge-base --is-ancestor避免无意义快进。
合并前如何自动校验分支状态
不检查就合并，大概率会把 main 搞崩。脚本第一件事必须确认当前分支、目标分支是否干净，以及是否有未推送的提交。
- 用
git status --porcelain判断工作区和暂存区是否为空，非空直接退出并提示 - 用
git rev-parse HEAD和git rev-parse @{u}对比本地 HEAD 与远程跟踪分支，确认origin/main是否已同步 - 运行
git merge-base --is-ancestor检查源分支是否已包含在目标分支中（避免无意义快进） - 注意：Windows 下
git rev-parse @{u}可能报错，应改用git ls-remote origin main | cut -d$'\t' -f1获取远程最新 commit hash
怎样安全执行 rebase + merge 而不丢 commit
直接 git merge --no-ff 容易产生“合并炸弹”，尤其多人协作时。更稳妥的是先 rebase 到目标分支再合入，但必须防止强制推送污染他人历史。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 只对本地功能分支做
git rebase main，禁止对已推送到远程的分支执行git push --force-with-lease - rebase 后用
git diff main...HEAD确认变更集与原始 PR 内容一致（避免交互式 rebase 误删 commit） - 最终合并用
git checkout main && git merge --no-ff --no-edit feature/login，保留分支边界 - 如果 rebase 过程出现冲突，脚本应立即中止，而非自动
git add . && git rebase --continue—— 人工介入才是安全边界
CI 中触发合并脚本的关键拦截点
自动化合并不能只靠本地脚本，必须嵌入 CI 流程，否则容易绕过测试和权限控制。
- GitHub Actions 中需检查
GITHUB_EVENT_NAME == 'pull_request'且github.event.action == 'closed'并确认github.event.pull_request.merged == true - GitLab CI 需依赖
CI_PIPELINE_SOURCE == 'merge_request_event'和CI_MERGE_REQUEST_EVENT_TYPE == 'merged' - 必须验证 PR 的
status check结果（如ci/ci-passedlabel 或 GitHub Checks API 返回status == 'success'），不能只看 CI job exit code - 合并账号需使用专用 bot token，并限制其仅对
main和release/*分支有 push 权限，避免误操作其他分支
为什么 merge --squash 不适合自动化上线流程
git merge --squash 看似简洁，但在自动化场景下会切断 commit lineage，导致后续 git bisect、changelog 生成、依赖追踪全部失效。
- CI 自动生成 CHANGELOG 依赖
git log --merges或 conventional commits，--squash后只剩单个 commit，无法提取 feat/fix 类型 - 发布后若需回滚，
git revert -m 1失效，只能靠git revert单 commit，但该 commit 的 diff 已丢失原始上下文 - 团队协作中，
--squash会让git blame指向合并者而非真实作者，破坏责任追溯 - 真正需要“干净历史”的场景（如发布 tag），应改用
git reset --soft+git commit手动聚合，而非交给脚本无脑 squash
git fetch 但没指定 refspec，导致 origin/main 滞后数分钟；还有就是误把 git push origin main 写成 git push origin HEAD:main，后者在 detached HEAD 下会意外创建新分支。这些细节不处理，自动化就只是加速出错。
