Git浅克隆分支合并子模块引用冲突 求可行操作步骤

主仓库浅克隆合并适配方案 #

• 调整actions/checkout配置，将fetch-depth设置为20（可根据两个分支的分叉提交数量调整，常规部署场景下20足够覆盖绝大多数情况），同时拉取所有需要用到的分支：

- uses: actions/checkout@v4
  with:
    fetch-depth: 20
    ref: <你的源分支名，如main>
    submodules: recursive

• 切换到release分支后，执行额外fetch确保本地有两个分支的完整提交链到分叉点：
  git fetch origin <源分支> release --update-head-ok
• 合并前验证共同祖先是否存在：执行git merge-base <源分支> release，如果返回正常哈希值说明历史深度足够；如果返回空，执行git fetch --deepen=10重复验证，直到拿到共同祖先。
  注意原合并命令的参数格式应为git merge -s recursive -X theirs <源分支>，如果之前参数格式书写错误也可能导致冲突无法自动解决
• 确认共同祖先存在后执行合并操作，Git可正常识别子模块引用变更，自动应用指定策略解决冲突。

子模块冲突专项处理 #

如果主仓库历史深度足够但子模块仍报冲突，执行以下操作处理子模块的浅克隆问题：

• 遍历所有子模块，拉取主仓库两个分支中引用到的子模块提交及对应共同祖先：

git submodule foreach --recursive 'git fetch origin $(git rev-parse HEAD) $(git -C $toplevel rev-parse <源分支>:$path) $(git -C $toplevel rev-parse release:$path) --depth=10'

• 若仍存在子模块引用冲突，直接强制使用源分支的子模块配置即可：
  git checkout --theirs -- .gitmodules **/.gitmodules
git checkout --theirs -- $(git submodule foreach --quiet 'echo $path')
  执行完成后直接提交，不需要处理子模块内部的文件冲突。

最小拉取量优化方案 #

如果不想固定拉取深度，可通过脚本自动计算需要的深度，拉取的历史量最小、速度最快：

1. 初始以深度1拉取源分支和release分支的头提交
2. 循环执行git merge-base <源分支> release，如果返回为空就执行git fetch --deepen=5，直到返回共同祖先哈希
3. 子模块也按照同样逻辑循环加深，直到覆盖两个分支引用的子模块提交的共同祖先

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