如何将已压缩合并的旧提交转为空提交后执行Git变基？

方法一：空提交标记法（匹配你的思路） #

这个方法就是把被压缩过的原提交（比如A、B、C、D）以空提交的形式追加到release分支，让Git后续变基时自动识别这些提交已“合并”，直接跳过。

操作步骤：

1. 切换到release分支：

   git checkout release
   

2. 针对每个被压缩的原提交，创建保留原提交信息但无变更的空提交：
   比如处理提交A（用哈希值或相对引用定位，比如main~5）：

   git commit --allow-empty --reuse-message=A
   

   把所有被压缩的提交都按这个方式处理一遍。
3. 推送修改后的release分支（如果是共享分支，需要--force，提前和团队同步）：

   git push origin release --force
   

之后再执行git rebase main release时，Git会识别这些空提交对应了main上的原提交，自动跳过旧提交，只处理新的变更。

方法二：用git replace关联压缩提交与原提交（更优方案） #

这个方法不用修改分支历史，而是给Git添加映射规则，让它把压缩提交识别为对应原提交的“替身”，变基时自动跳过原提交。

操作步骤：

1. 找到压缩提交Sq1对应的最后一个原提交（比如B），执行映射：

   git replace Sq1 B
   

   其中Sq1是release分支上压缩提交的哈希，B是main分支上对应原提交的哈希。
2. 同理处理Sq2和对应的原提交D：

   git replace Sq2 D
   

3. 如果团队需要共享这个规则，推送映射到远程：

   git push origin refs/replace/<Sq1的哈希>
   

   其他成员拉取映射：

   git fetch origin refs/replace/*:refs/replace/*
   

这个方法不会污染分支历史，是最干净的解决方案，适合熟悉Git高级功能的团队。

方法三：指定变基起点，只处理新提交 #

每次变基时，直接跳过已同步的历史，只处理main上的新提交：

1. 找到release分支上最后一个和main同步的提交（比如F*对应的F），执行：

   git rebase --onto release F main
   

2. 再把release分支快进到更新后的main：

   git checkout release
   git merge main
   

如果想简化操作，可以每次同步后给release打标签：

git tag sync-20240520

下次变基直接用标签当起点：

git rebase --onto release sync-20240520 main

各方法优缺点对比 #

• 空提交法：直观易操作，但会给分支添加无意义的提交，适合临时快速解决或团队Git基础较弱的场景。
• git replace法：不修改历史，最优雅，但需要团队统一配置映射规则，适合熟悉Git的团队。
• 指定起点法：无需额外配置，但每次要手动确定同步起点，适合提交频率不高的场景。

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