如何用浅克隆移除敏感提交并保留分支可合并性，尽量避免强制推送

场景说明 #

我们的Git提交历史如下：

G
                /
               /
--A---B---C---D---E---F
           \
            \
             H

需要彻底移除包含敏感信息或大文件的提交A-E，但要求分支G、H仍能与F所在的主分支正常合并。

可行方案：重写分支历史（推荐） #

通过git checkout --orphan创建无历史的新分支，再用git rebase --onto将G、H的变更移植到新历史上，无需删除整个仓库。

步骤1：创建干净的主分支（替代原A-E+F的历史） #

# 切换到F所在的主分支（假设分支名为main）
git checkout main
# 创建一个无历史记录的新分支
git checkout --orphan new-main
# 添加当前所有文件到暂存区
git add -A
# 提交为新的初始提交，备注清楚替换了原A-E历史
git commit -m "Clean initial state (replaced commits A-E)"

步骤2：重写G分支的历史 #

G是从提交D分叉出来的，我们把D之后G的变更移植到新主分支上：

git checkout G
# 将G分支中D之后的提交，重放到new-main分支末尾
git rebase --onto new-main D

步骤3：重写H分支的历史 #

H是从提交C分叉出来的，同理移植变更：

git checkout H
# 将H分支中C之后的提交，重放到new-main分支末尾
git rebase --onto new-main C

步骤4：替换原分支并强制推送 #

# 将new-main重命名为原主分支名
git checkout new-main
git branch -M main

# 强制推送主分支到远程（注意：远程历史会被覆盖）
git push -f origin main

# 同样强制推送重写后的G、H分支
git push -f origin G
git push -f origin H

注意事项 #

• 所有协作开发者必须重新克隆仓库，或执行git fetch origin后用git reset --hard origin/<分支名>同步本地分支，因为历史已被重写，普通pull会导致冲突。
• 若存在其他基于A-E的分支，需用同样的rebase --onto方法重写历史。
• 此方法保留了G、H和主分支的所有内容，且三者共享新的初始提交，后续可正常执行合并操作。

对比删除.git文件夹的方案 #

直接删除.git文件夹重建仓库的方法会导致G、H与新仓库完全无历史关联，合并时需手动处理所有差异；而上述重写历史的方法能保留分支的变更逻辑，合并更顺畅。

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