触发多Git仓库（含Yocto及依赖）时主仓库Git配置异常致构建失败

核心问题：当构建由依赖仓库触发时，主Yocto仓库（repo1.git）未切换至与依赖仓库兼容的分支，导致子模块拉取的核心层与meta-repo1层版本冲突（nanbield vs scarthgap）。

针对性修复方案 #

1. 强制主仓库切换至依赖兼容分支 #

在CI流程中，先切换repo1到对应兼容分支，再执行子模块配置：

• 维护触发仓库分支与repo1分支的映射关系（比如依赖仓库的scarthgap-compat分支对应repo1的scarthgap分支）
• 在CI脚本中添加分支切换逻辑：

  # 根据触发仓库的分支确定repo1需要切换的分支
  case $TRIGGER_REPO_BRANCH in
    scarthgap-compat) REPO1_TARGET_BRANCH="scarthgap" ;;
    nanbield-compat) REPO1_TARGET_BRANCH="nanbield" ;;
    *) REPO1_TARGET_BRANCH="main" ;;
  esac
  
  # 切换repo1到目标分支并拉取最新代码
  git -C repo1 checkout $REPO1_TARGET_BRANCH
  git -C repo1 pull origin $REPO1_TARGET_BRANCH
  

2. 修复子模块追踪配置 #

确保子模块拉取的是与repo1当前分支匹配的版本：

• 检查repo1的.gitmodules文件，给每个子模块添加明确的branch字段，比如：

  [submodule "meta-core"]
    path = meta-core
    url = <core-repo-url>
    branch = scarthgap
  

• 在CI的子模块配置步骤中，显式指定分支更新：

  git submodule update --init --recursive --remote --branch $REPO1_TARGET_BRANCH
  

3. 传递CI触发上下文的分支信息 #

多数CI系统（GitLab/GitHub Actions等）在跨仓库触发时会传递触发源的分支参数，需在YAML配置中捕获并使用：

• 比如GitLab CI中，用$CI_COMMIT_BRANCH获取触发仓库的分支，再映射到repo1的兼容分支
• 避免主仓库流水线默认使用自身的main或默认分支

4. 前置分支验证步骤 #

在Sanity检查前添加分支匹配验证，提前拦截问题：

# 检查repo1当前分支
REPO1_CURRENT_BRANCH=$(git -C repo1 rev-parse --abbrev-ref HEAD)
# 检查核心层子模块分支
CORE_LAYER_BRANCH=$(git -C repo1/meta-core rev-parse --abbrev-ref HEAD)

if [ "$REPO1_CURRENT_BRANCH" != "$REPO1_TARGET_BRANCH" ] || [ "$CORE_LAYER_BRANCH" != "$REPO1_TARGET_BRANCH" ]; then
  echo "ERROR: Branch mismatch - repo1 on $REPO1_CURRENT_BRANCH, core layer on $CORE_LAYER_BRANCH (expected $REPO1_TARGET_BRANCH)"
  exit 1
fi

关键排查点 #

• 确认CI日志中，依赖仓库触发时，repo1的克隆/切换步骤是否使用了默认分支而非兼容分支
• 检查"Configure submodules"步骤的执行时机：必须在repo1切换到目标分支之后，否则子模块会被重置为旧版本

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