Azure中含Git子模块的分支正确合并方法及最佳实践咨询

一、解决ACU1/ACU2的子模块合并冲突步骤 #

当COMMON的hotfix已经合并到develop并生成新提交ID后，按以下步骤处理ACU1/ACU2的PR冲突：

• 拉取本地ACU1的develop和hotfix分支，确保代码最新：

  git checkout develop
  git pull origin develop
  git checkout hotfix/xxx
  git pull origin hotfix/xxx
  

• 更新ACU1的COMMON子模块到PR1合并后的新提交ID：
  可以直接指定COMMON的目标提交ID，或者切换到COMMON目录拉取最新develop分支：

  # 方式1：直接指定提交ID
  cd COMMON
  git checkout <PR1合并后的COMMON提交ID>
  cd ..
  # 方式2：拉取COMMON的develop分支
  cd COMMON
  git checkout develop
  git pull origin develop
  cd ..
  

• 提交ACU1中子模块的版本变更：

  git add COMMON
  git commit -m "Update COMMON to latest develop commit after hotfix merge"
  git push origin hotfix/xxx
  

• 回到Azure DevOps的ACU1 PR页面，此时子模块冲突已解决，可正常完成合并。ACU2重复上述步骤即可。

二、Azure DevOps中含子模块项目的合并最佳实践 #

• 子模块变更优先合并：所有依赖子模块的主项目（ACU1/ACU2），必须等子模块的对应分支（如COMMON的develop）完成变更合并后，再处理主项目的PR，从根源避免子模块版本不一致导致的冲突。
• 启用PR子模块状态检查：在Azure DevOps的PR设置中，开启子模块的有效性检查，确保PR中子模块指向的提交是对应分支的已合并正式提交，禁止引用临时分支或未合并的提交。
• 统一子模块更新规范：主项目的hotfix/feature分支更新子模块时，必须明确对齐到子模块目标分支的最新已合并提交，禁止直接引用子模块的开发分支。
• 自动化同步流程：借助Azure Pipeline编写自动化脚本，当COMMON的develop分支有新合并时，自动触发ACU1/ACU2的子模块更新，推送变更并自动创建PR，减少手动操作的误差。

三、先合并COMMON再处理主模块的合理性与更优方案 #

当前流程的合理性 #

先合并COMMON的hotfix到develop，再处理ACU1/ACU2的PR是完全正确的流程。因为子模块是主项目的依赖项，只有依赖项的变更先同步到目标分支，主项目才能对齐到统一的版本，避免合并时出现子模块的版本冲突。

更优方案 #

• 子树合并替代子模块：如果团队觉得子模块的维护成本过高，可以将COMMON作为子树合并到ACU1和ACU2中。这样COMMON的变更会直接成为主项目的一部分，无需单独维护子模块的版本引用，但缺点是COMMON的变更需要同步到多个主项目。
• 全自动化子模块更新Pipeline：基于Azure DevOps Pipeline实现端到端自动化：当COMMON的hotfix PR合并到develop后，自动触发ACU1/ACU2的hotfix分支更新子模块到最新提交，推送变更并自动创建合并到develop的PR，全程无需手动干预，彻底避免冲突。

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