上线前必须先执行 git fetch --all 获取远程最新状态，再用 git branch -vv 确认本地分支是否跟踪正确远程分支，若显示 [ahead] 或 [behind] 需分别 push 或 pull --rebase，最后验证 HEAD 指向预期 commit 并检查构建文件与保护规则。
上线前必须确认远程分支已同步
本地开发完、合并到 master 或 release-* 后，不代表远端已有最新代码。很多人直接 git push 就以为完事，结果 CI/CD 流水线拉的还是旧 commit。
- 先执行
git fetch --all，确保本地知道所有远程分支的最新状态 - 再用
git branch -vv查看当前分支是否跟踪远程对应分支（输出里应有[origin/master]这类标记） - 如果显示
[ahead 2]或[behind 1]，说明本地和远程不一致，必须处理：ahead 就 push，behind 就git pull --rebase
合并后要验证 HEAD 是否指向预期 commit
误操作（比如 merge 冲突没解决干净、rebase 漏掉提交、或切错分支 commit）会导致 master 分支 HEAD 指向错误的 commit，上线后功能缺失或回退。
- 用
git log -n 5 --oneline快速确认最后几条提交内容是否包含你刚合并的 feature 提交 - 比对 commit hash：在你的 feature 分支上执行
git log -n 1 --oneline，然后在master上执行同样命令，确认 hash 一致 - 如果用了
git merge --no-ff，merge 提交本身应带清晰 message，如Merge branch 'feature-login'；若看到 fast-forward 合并且没有 merge 提交，说明没加--no-ff，历史可读性差，但不致命
检查是否有未提交或忽略的本地改动
git status 显示 “clean” 不等于真正干净——.gitignore 里漏配的临时文件、IDE 生成的配置、未 track 的敏感文件（如 .env）可能还在工作区，一不小心就被 git add . 带进去了。
- 运行
git status --ignored，看有没有被忽略但实际存在的文件（尤其是配置类、密钥类） - 用
git clean -dn预览将被删除的未 tracked 文件（-n是 dry-run），确认无误再-f - 重点检查
package.json、requirements.txt、Dockerfile等构建依赖文件是否已 commit，这类文件漏提交会导致构建失败
上线分支需满足基础保护规则
很多团队在远端（如 GitHub/GitLab）设置了分支保护规则，但本地 push 失败时只报 generic error，容易忽略根本原因。
- 确认目标分支（如
master或release-*）是否要求 PR/MR + 至少 1 人 approve —— 直接git push origin master会被拒绝 - 检查是否启用了 “require status checks to pass before merging”，CI 流水线（如 test、build、lint）必须全部 green 才能合入
- 部分平台还限制 push 权限（例如只允许 maintainers 推送），普通开发者需通过 MR 合并，不能直推
真正卡住上线的，往往不是代码逻辑，而是这些看似琐碎的检查项漏了一项。尤其当多人并行合入时，git pull --rebase 和 git push --force-with-lease 这类操作极易触发保护机制，得提前看清楚策略再动手。
