git merge 应在目标分支（如main）上执行：先 checkout main，再 merge feature/login；误操作可用 git reset --hard 或 git revert 撤回；合并前需校验是否已合并，推荐用 git merge-base 判断。
git merge 命令怎么安全合并指定分支
直接 git merge feature/login 很容易出问题——如果当前分支不是 main 或 develop，或者目标分支没拉最新，合并结果就不可控。自动化脚本里必须显式校验起点和终点。
推荐做法是固定基线：先确保本地 main 是最新的，再从 main 拉出新分支做合并，避免污染工作区。脚本里应包含：
-
git checkout main && git pull origin main（强制同步主干） -
git checkout -b merge-$(date +%s) main（用时间戳建临时分支） -
git merge --no-ff --no-edit feature/login（禁用快进、跳过编辑提交信息）
如何检测并跳过已合并的分支
重复合并同一分支会生成无意义的 merge commit，还可能触发冲突。不能只靠分支名判断，得查提交图谱。
用 git merge-base 最可靠：git merge-base main feature/login 返回的 commit ID 如果和 feature/login 的 HEAD 一致，说明该分支已完全并入 main。
脚本中可这样写判断逻辑：
if [ "$(git merge-base main feature/login)" = "$(git rev-parse feature/login)" ]; then echo "branch feature/login already merged" exit 0 fi
自动解决 trivial 冲突但不掩盖真实问题
有些冲突其实只是行尾空格或换行符差异，git merge 默认不会自动处理，但脚本里可以加策略——前提是明确知道哪些冲突类型可信任。
仅对已知安全场景启用自动化解：
- 用
git merge -Xignore-space-change忽略空格变化（适用于团队统一了 .editorconfig） - 用
git merge -Xours强制保留当前分支版本（仅限文档、配置等只读分支） - 绝不要对
src/下的业务代码用-Xtheirs或-Xours，这等于绕过人工审查
真正该自动化的，是冲突发生后的响应动作：比如把 git status 输出存日志、发钉钉通知、退出非零状态码，而不是强行“搞定”它。
CI 环境下执行 merge 脚本的关键限制
GitHub Actions / GitLab CI 默认 checkout 的是 detached HEAD，直接 git merge 会失败，报错 fatal: refusing to merge unrelated histories 或 not a valid object name。
必须提前补全分支引用：
git fetch origin main:refs/remotes/origin/maingit fetch origin feature/login:refs/remotes/origin/feature/login- 再用
git checkout origin/main（不是main）切到远程跟踪分支
另外，CI token 权限要开足：至少需要 repo:public_repo（GitHub）或 write_repository（GitLab），否则 push 合并结果会 403。
临时分支名别用 merge- 开头——某些仓库设置了 branch protection rule，禁止 push 到 merge/* 这类通配模式，换成 auto-merge- 更稳妥。
