Git将主开发分支从jdk8切换为main并反向合并的方案咨询

• 你当前使用的git merge -s ours main的初始合并逻辑本身是成立的，核心作用是标记main分支当前所有历史变更已经在jdk8分支处理完毕，后续合并只会同步该节点之后的新提交，符合你的需求，但存在几个可预见的潜在问题：
  1. 如果你通过git attributes全局忽略了构建文件的合并，后续main分支修改了公共配置（比如业务依赖版本、通用打包逻辑），这部分有效变更会被自动过滤，需要手动同步容易遗漏
  2. 纯手动排除文件的操作不稳定，合并次数多了很容易误操作带入jdk11专属文件，或者遗漏业务代码的变更
  3. 未提前配置冲突处理规则，后续业务代码出现冲突时每次都需要手动解决，效率低且容易出错

第一步：配置合并规则 #

在jdk8分支根目录新增.gitattributes文件，给专属文件配置定向合并规则，不需要全量忽略文件：

# JDK11专属的模块化文件，合并时永远取jdk8分支的内容（相当于自动忽略该文件的变更）
module-info.java merge=ours
# 其他JDK11专属的构建文件、插件配置等也按这个格式添加
build-jdk11.gradle merge=ours
settings-jdk11.gradle merge=ours

配置完成后提交到jdk8分支，后续合并时这些文件会自动保留当前分支的内容，不会产生冲突也不需要手动处理。

第二步：执行初始合并 #

和你当前的操作一致，执行以下命令完成基准合并：

# 切换到jdk8分支
git checkout jdk8
# 合并main分支的所有历史，完全保留jdk8分支的内容
git merge -s ours main

合并完成后务必验证jdk8分支的代码编译、单测、打包逻辑完全正常，再推送远程仓库。

第三步：后续合并标准化流程 #

每次main分支有稳定的可同步变更后，按以下步骤操作：

1. 切换到jdk8分支，拉取最新的远程代码
2. 执行合并命令，不自动提交，方便人工核验：

git merge main --no-commit --no-ff

3. 检查变更列表：业务代码变更直接保留，构建配置类变更区分公共变更（比如通用依赖升级需要同步）和JDK11专属变更（直接丢弃）
4. 核验所有变更无误后提交合并结果，推送远程

备选方案（适合仅需同步部分变更的场景） #

如果后续jdk8分支仅需要同步核心bug修复，不需要同步所有新功能，可以改用cherry-pick的方式同步单条/多条提交：

git checkout jdk8
# 同步main分支的指定提交到jdk8
git cherry-pick <需要同步的提交哈希>

该方式灵活性更高，不会带入多余的无关变更，适合两个分支差异逐渐变大后的长期维护。

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