git merge main 必须在目标分支（即要更新的分支）上执行，例如在 feature/user-login 分支同步主干时，需先 git checkout feature/user-login 再 git merge main；若误在 main 分支执行，则错误地将功能分支合入主干。
主干代码同步到分支，本质是把 main（或 master）的最新变更合并进你正在开发的分支，不是“把分支推给主干”。操作前必须确认当前在目标分支上，否则会白忙活甚至污染主干。
git merge main 在哪个分支执行？
必须在你要更新的那个分支上执行。比如你在 feature/user-login 分支开发，想同步主干最新修复，就得先 git checkout feature/user-login，再 git merge main。
常见错误：切在 main 上执行 git merge feature/user-login —— 这是往主干合功能，不是同步主干；或者切错成其他分支，导致合并了不该合的代码。
- 执行前务必用
git branch或git rev-parse --abbrev-ref HEAD确认当前分支名 - 如果远程主干有新提交但本地没拉，
git merge main实际合并的是你本地旧的main，结果可能漏掉关键修复 - 推荐组合：先
git fetch origin main拉取远端最新，再git merge origin/main，避免依赖本地main的陈旧状态
用 git pull origin main 还是 git merge origin/main？
git pull origin main 是 git fetch origin main + git merge origin/main 的快捷封装，但它会自动触发合并，容易掩盖问题。
更可控的做法是分两步：
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 先
git fetch origin main，然后用git log HEAD..origin/main看主干新增了哪些提交，心里有数 - 再
git merge origin/main，冲突时能明确知道是哪几处改动引起的 - 如果只是想快速同步且确定无冲突，
git pull origin main也行；但 CI/CD 流水线或多人协作中，建议显式拆开，便于审计和回退
--squash 合并主干适合什么场景？
git merge --squash main 不会创建合并提交，而是把 main 的所有变更暂存为工作区修改，由你手动 git commit。它不保留 main 的提交历史，只留一个干净的“同步快照”。
适用情况：
- 分支长期未同步主干，
main已累积大量小修小补，你只想一次性吸收变更，不关心每条提交细节 - 团队规范要求分支提交历史必须线性、简洁，禁止出现合并提交（
merge commit） - 你准备后续 rebase 到主干，提前用
--squash避免嵌套合并
注意：--squash 后必须手动 git commit，否则变更不会真正进入分支历史；且之后不能用 git revert -m 1 <merge-commit></merge-commit> 回退，因为根本没有合并提交。
同步后编译失败或测试不通过怎么办？
主干引入的新接口、配置或行为变更，可能让分支原有逻辑失效。这不是 Git 操作错误，而是代码兼容性问题。
- 别急着
git reset --hard回退 —— 先git status确认哪些文件被改了，重点看package.json、tsconfig.json、API 调用点、配置文件路径等 - 检查
origin/main的最近几次提交日志：git log --oneline origin/main -n 5，看是否有 breaking change 提示 - 如果只是临时绕过，可用
git cherry-pick -n <commit-hash></commit-hash>挑选性应用主干某些提交，跳过引发问题的部分
最常被忽略的一点：同步主干不是终点，而是验证起点。合并完立刻跑单元测试、启动本地服务、走通核心链路，比写一行 git push 重要得多。
