场景：如果代码分支，测试版本和生产版本差距非常大，需要把测试版本的代码同步到生产版本，但是采用代码合并会出现很多冲突，打算直接把测试分支变成生产分支，怎么操作合适？
方案一：
原理：-s ours 策略会记录一次合并，但内容完全保持当前分支不变。然后在生产分支做普通 merge 时，Git 认为差异已经被"合并过了"，不会再冲突。
⚠️ 注意：这个方案有个前提------测试分支需要包含生产分支的所有历史。如果两个分支已经完全分叉，更稳妥的做法是方案二。
生产分支 production 测试分支 test
我们要让测试分支的内容覆盖生产分支
1. 切换到测试分支
git checkout test
2. 以 ours 策略合并生产分支（意思是：合并生产分支的历史，但冲突时全部取"我们"即测试分支的代码）
git merge -s ours production
3. 切换到生产分支
git checkout production
4. 合并测试分支（此时已经没有冲突了，因为上一步已经解决了）
git merge test
方案二：直接重置生产分支指向测试分支
生产分支的历史记录会丢失（被测试分支的历史替代）
强制推送会影响其他协作者，需要通知团队
1. 切换到生产分支
git checkout production
2. 将生产分支直接重置到测试分支
git reset --hard test
3. 强制推送到远程
git push origin production --force
方案三：使用 theirs 策略合并
优点：保留了生产分支的提交历史，非冲突文件也会自动采用测试分支的版本。 缺点：-X theirs 只解决冲突时取测试分支，对于非冲突的差异（比如某文件只在生产分支修改过），仍然会保留生产分支的版本
1. 切换到生产分支
git checkout production
2. 使用 recursive + theirs 策略合并测试分支
冲突时全部取测试分支（theirs）的内容
git merge -X theirs test
3. 如果有未冲突但需要检查的文件，手动确认
git status
4. 推送到远程
git push origin production