主分支向测试分支的自动化同步必须通过外部调度（如cron或GitHub Actions）+ shell脚本实现，核心是显式fetch、--ff-only合并、绝对路径切换、错误退出与日志记录，禁用git pull和rebase，确保安全可控。
主分支（如 main 或 master）定期向测试分支（如 test 或 staging）同步，不能靠人肉 git merge，必须自动化；但 Git 本身不提供“定时同步”能力，得靠外部调度 + 脚本组合实现，且关键在于避免覆盖、跳过冲突、防止误操作。
用 cron + shell 脚本定时拉取并合并
这是最轻量、最可控的方式，适合私有服务器或 CI 机器上运行。核心逻辑是：切到测试分支 → fetch 主分支最新 → 合并（带策略）→ 推送。不要用 git pull，它隐式 merge 可能掩盖问题。
- 脚本中必须显式指定远程名（通常是
origin），避免因 remote 名不同导致失败 - 合并前加
git merge --ff-only origin/main，强制只允许快进，拒绝有冲突或分叉的合并 —— 这能防止意外引入非主干提交 - 若需自动解决“纯新增文件”类冲突，可用
git merge -X ours origin/main（慎用，仅适用于测试分支完全不改主干代码的场景） - 脚本开头加
cd /path/to/your/repo，绝对路径，避免 cron 执行时工作目录错乱 - 每次操作后检查
$?，失败立即退出并记录日志，别让一次失败静默污染后续同步
CI 环境中用 GitHub Actions 自动触发
如果代码托管在 GitHub，直接用 schedule 触发器比本地 cron 更可靠，也免运维。关键是权限和分支保护设置要匹配。
- 使用
actions/checkout@v4时必须加fetch-depth: 0，否则git merge会找不到历史提交 - 默认 runner 没有写权限，推送前要配置
GITHUB_TOKEN（它自带write权限，但仅限当前仓库） - 触发时间写成
cron: '0 2 * * 1'表示每周一凌晨 2 点，别用* * * * *—— 频繁合并可能堆积未处理冲突 - 务必在 job 开头加
if: github.repository == 'your-org/your-repo'，防止 fork PR 误触发 - 合并命令推荐：
git merge --no-edit --ff-only origin/main，省去交互，失败即停
为什么不用 git rebase 同步主分支到测试分支
git rebase 会重写测试分支的提交哈希，一旦该分支已被他人基于它开发或部署，就会引发历史不一致、重复提交、CI 重跑等问题。
- 测试分支通常被 QA、自动化测试、预发环境引用，它的 commit ID 是稳定锚点，不能变
-
rebase后若强制推送（git push --force-with-lease），会破坏协作信任 —— 别人git pull会报错，必须手动git reset - 只有当测试分支是个人临时分支、且明确无共享时，才可考虑
rebase；生产级同步一律用merge - 如果真想线性历史，应在主分支上用
--ff-only合并特性分支，而不是在测试分支上 rebasing 主分支
同步失败时最常被忽略的三个检查点
自动化脚本跑着跑着突然不动了，90% 情况下不是逻辑错，而是环境或权限卡住。
-
git status显示 “Your branch is ahead of ‘origin/test’ by X commits” —— 说明上次推送失败，但脚本没判错继续跑，下次合并前必须先git push origin test清掉本地 ahead 状态 - 远程分支保护规则（如 require PR, require status checks）阻止了自动推送，GitHub/GitLab 的 Settings → Branches 里要为
test分支关闭这些限制，或给 token 加对应权限 - 本地 git config 中 user.name/user.email 为空，导致
git merge提交时失败（错误信息类似*** Please tell me who you are...），脚本里得提前设好：git config user.name "sync-bot"、git config user.email "bot@example.com"
自动化同步不是设完就高枕无忧的事——它把人工操作压缩成一行命令，却把所有边界条件都放大了。每次上线新同步策略，务必手动跑一遍脚本、看日志、验证测试分支 HEAD 是否真等于主分支最新提交，再放开定时任务。
