不能用 git merge release 直接更新 master，因为会引入未完成代码、缺失版本标签、增加回滚复杂度；正确做法是 release→master 快进或 --no-ff 合并并打 tag。
生产分支（master）和测试分支（release或test）不能直接双向同步，必须按单向、受控、可追溯的顺序推进 —— 否则极易引入未经验证的代码到生产环境。
为什么不能用 git merge release 直接更新 master？
看似省事，但实际埋下三类风险：
- 测试分支可能混有未完成的修复或临时调试代码，
merge会一并带入生产 - 缺少显式版本标签（
git tag -a v1.2.3 -m "prod release"），导致线上问题无法快速定位对应 commit - 若后续需回滚，
master上的 merge 提交本身可能含冲突解决逻辑，增加回溯复杂度
正确做法是：仅允许从 release → master 的**快进合并（fast-forward）或带签名的 --no-ff 合并**，且必须在打 tag 后执行。
同步前必须确认的 4 个状态
执行任何同步操作前，先运行以下命令验证环境一致性：
-
git fetch origin：确保本地知道远程release和master的最新提交 -
git log --oneline origin/release ^origin/master：列出release有但master没有的提交（即待上线内容） -
git diff origin/master...origin/release：检查差异是否仅含预期变更（排除误提交的 .env 或日志文件） -
git branch -vv | grep -E "(master|release)"：确认本地master跟踪origin/master，而非其他分支
安全同步的两步命令流（推荐）
跳过 git pull 这类隐式操作，全程手动控制 fetch + merge，避免意外自动合并：
- 切换到本地
master并确保干净：git checkout master && git reset --hard origin/master - 拉取
release最新状态：git fetch origin release:refs/remotes/origin/release（只拉指定分支，不污染本地其他远端引用） - 执行受控合并：
git merge --no-ff --log -m "release/v1.2.3 → prod" origin/release（强制生成 merge commit，保留上线上下文） - 立即打标签并推送：
git tag -a v1.2.3 -m "Production release for sprint-2026-Q3" && git push origin master v1.2.3
注意：如果 origin/release 比 origin/master 旧（比如测试分支被重置过），git merge 会提示“Already up to date” —— 此时绝不可强行 push，应先查清 release 分支为何滞后。
测试分支如何反向同步生产 hotfix？
当线上发现紧急 bug，hotfix 直接提交到 master 后，必须将修复同步回 release（否则下次发布仍含该 bug）：
- 切到本地
release：git checkout release - 同步最新
master：git fetch origin master:refs/remotes/origin/master - 用
rebase而非merge应用 hotfix：git rebase origin/master（保持release历史线性，避免重复 merge 提交） - 推送时加
--force-with-lease：git push --force-with-lease origin release（防止覆盖他人新提交）
关键点：rebase 后的 release 分支 SHA-1 会变，所有协作者必须重新 git fetch && git reset --hard origin/release，这点常被忽略，导致本地残留旧提交。
