Git中将变基后分支合并到其未变基版本的正确操作方法

直接将MY-FEATURE合并入FEATURE完全无法实现两者状态完全一致的目标，且极大概率触发大量无意义冲突，不建议使用该操作。
原因很明确：你对MY-FEATURE做rebase到最新main的操作时，已经改写了分支的提交历史——原FEATURE分支上6个月前合并main的提交被丢弃后，rebase后的MY-FEATURE是基于最新main节点重放自有改动生成的全新提交链，和原FEATURE的提交历史已经形成分叉。普通merge操作会基于两个分支的共同祖先做三方合并，你在rebase阶段已经处理过的、属于那次老main合并的改动会被重新识别为差异，直接催生大量重复冲突，最终合并出的分支还会残留冗余的合并节点、重复提交，和你要的「完全一致」目标差得很远。

你的核心需求是让远程FEATURE分支的提交历史、文件内容和本地已验证的MY-FEATURE完全对齐，最稳妥无冲突的方案是带安全校验的强制覆盖，操作步骤如下：

• 前置校验：先切到本地MY-FEATURE分支，执行git status确认工作区无未提交改动，且本地MY-FEATURE的rebase结果已经过你验证、是最终要上线的正确版本。
• 备份兜底（强烈建议执行）：给远程当前的FEATURE分支打备份标签，后续如果需要回滚老版本可以直接基于标签恢复，执行两条命令：

  git tag backup/feature-pre-overwrite origin/FEATURE
  git push origin backup/feature-pre-overwrite
  

• 安全强制覆盖：执行带租约检查的强制推送，直接将本地MY-FEATURE的状态同步到远程FEATURE：

  git push --force-with-lease origin MY-FEATURE:FEATURE
  

  这里用--force-with-lease而非裸--force的原因是，该参数会在推送前自动校验远程FEATURE的最新提交是否和你本地缓存的origin/FEATURE一致，如果操作间隙有其他同事往FEATURE推了新提交，推送会直接终止，不会误覆盖他人的改动，安全性更高。
• 结果校验：推送完成后执行git fetch origin拉取最新远程状态，再执行git diff MY-FEATURE origin/FEATURE，如果命令无任何输出，就证明两个分支的内容、历史已经完全一致，目标达成。

分支历史重写完成后，需要通知所有在本地拉取过老FEATURE分支的协作者，不要直接执行git pull同步，否则会把老的分叉历史重新合并回远程分支。正确的同步方式是执行以下命令：

git fetch origin
git checkout FEATURE
git reset --hard origin/FEATURE

内容的提问来源于stack exchange，提问作者TeabagD