父分支被压缩后，如何变基子分支甚至将其挂至祖父分支？

场景回顾 #

交付阶段将feature分支的多个提交压缩为单个提交i并合并到master后，integration-tests分支仍依赖旧的feature提交{a,b,c,h}，引发分支依赖冲突。以下是两种满足需求的操作方法：

方案1：让integration-tests以压缩后的feature {i}为父分支 #

该方案会将integration-tests上的d,e提交，重新基于feature分支的压缩提交i，最终分支结构为：master <- feature {i} <- integration-tests {d,e}

操作步骤：

1. 切换到integration-tests分支：

   git checkout integration-tests
   

2. 使用rebase --onto迁移提交：

   git rebase --onto feature <旧feature最后提交哈希>
   

   • 这里的<旧feature最后提交哈希>指压缩前feature分支的最后一个提交h的哈希值，可通过git reflog或git log查询。
   • 这条命令的作用是：把integration-tests分支中，<旧feature最后提交哈希>之后的所有提交（即d,e），重新应用到feature分支的当前顶端（压缩后的i）。
3. 若rebase过程中出现冲突，解决冲突后执行：

   git add .
   git rebase --continue
   

   如需终止rebase，执行git rebase --abort即可。

方案2：让integration-tests直接基于master分支 #

该方案会将integration-tests上的d,e提交直接迁移到master分支，最终分支结构为：master <- integration-tests {d,e}

操作步骤：

1. 切换到integration-tests分支：

   git checkout integration-tests
   

2. 使用rebase --onto迁移提交：

   git rebase --onto master <旧feature最后提交哈希>
   

   • 同样，<旧feature最后提交哈希>是压缩前feature分支的最后一个提交h的哈希值。
   • 这条命令会把integration-tests中h之后的d,e提交，重新应用到已合并i的master分支顶端。
3. 冲突处理方式与方案1一致：解决冲突后执行git add . && git rebase --continue，终止则用git rebase --abort。

注意事项 #

• 若integration-tests分支已推送到远程仓库，操作后需强制推送：

  git push --force-with-lease origin integration-tests
  

  --force-with-lease比直接--force更安全，可避免覆盖他人提交，但操作前务必和团队成员沟通确认。
• 压缩feature分支后，旧提交{a,b,c,h}会成为孤儿提交，后续会被Git垃圾回收机制自动清理，无需手动处理。

内容的提问来源于stack exchange，提问作者Marc Le Bihan