我们有一个存储库，其中包含许多由 Maven 构建的 Java 项目(约 20 个)。
我们的存储库中有 3 个分支，patch、minor 和 major。
对于ProjectA，patch分支上的pom.xml和MANIFEST.MF设置为1.3.7，而在 minor 上，它们被设置为 1.4.0，在 major 上，它们被设置到 2.0.0。
这是痛点:从 patch 分支执行发布时，然后我们想要 merge 那个新标签(projecta-1.3.7) 转发到 minor 和 major 分支。
问题是，即使我们只更改了补丁分支上的一个 .java 文件(假设这是一个关键错误修复)，每次我们都有遍历并解决每个 pom.xml 和 MANIFEST.MF 文件的冲突。所以这个:
git checkout minor
git merge projecta-1.3.7
导致 minor 获得错误修复(呜呜呜!)但随后还需要我们检查并比较所有 projecta-1.3 之间的冲突。 7 项目使用补丁版本，minor 项目使用次要版本。
有没有办法告诉 Git，作为 merge 命令的一部分，我们要对 pom.xml、MANIFEST.MF 使用“我们的”策略>，但是否应使用默认策略解决任何其他冲突？
最佳答案
我通常通过将 bug 修复的代码更改作为单独的提交提交来处理这个问题，以提高版本号(我假设是对 pom.xml 和 MANIFEST 文件的更改)。然后我可以将代码更改提交正常 merge 到其他分支，然后最后“伪造” merge “version #bump”更改分别与 merge --strategy=ours。
操作请求:
Our process is: (1) release project 1.3.7 (2) merge the tag into future branches ('minor') (3) update POM/MANIFEST to 1.3.8, (4) ...work... (5) then, a couple weeks later, start back at (1) again.
好的，我的流程有点不同，但按照您的流程，如果第 3 步生成提交 #1234ABCD，那么我会额外执行第 3a 步:
$ git checkout MAINLINE
$ git merge --strategy=ours 1234ABCD
这将确保当您返回并在将来点击第 2 步时，#bump 版本将被视为已 merge 并被忽略。
或者，稍后再执行 3a。当您将来到达第 2 步时，然后执行#1234ABCD 的伪 merge ，然后 merge #1234ABCD 之后分支上的所有提交。当您再次在分支中修改版本号时 - “假 merge ”它(立即或稍后)。
核心思想只是将提交与版本# 的颠簸隔离开来，然后“伪造”将其单独 merge ——何时执行取决于您。即使版本 # bump 位于要 merge 的分支上的提交中间，然后 merge 所有其他提交之前的第一个提交，然后假 merge 那个颠簸版本 # 的提交，然后 merge 所有提交在那之后。
这是我上周进行的 merge 的粗略图片。左边距下方的提交是 MAINLINE 开发，不在左边距的是在 RELEASEBRANCH(维护分支)中进行的。提交顺序与您的流程不匹配，但这并不重要。
* bc26f91 Oct 31 Fake merge from IT17p2 to ignore inapplicable commit: All web-apps: blah blah blah (MAINLINE)
|\
| * 3cd69ad Oct 31 All web-apps: bump release # for new release (RELEASEBRANCH)
* | 8eae339 Oct 31 Merge fix from IT17p2: All web-apps: blah blah blah
|\ \
| |/
| * 3612072 Oct 31 All web-apps: blah blah blah
| |
关于Git merge 策略将 'patch'分支整合到 'minor'， 'minor'分支整合到 'major'，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19794135/