我们有一个包含许多由Maven构建的Java项目（约20个左右）的存储库。
我们的存储库中有3个分支，patch，minor和major。
对于ProjectA，pom.xml分支上的MANIFEST.MF和patch设置为1.3.7，而minor则设置为1.4.0到major，在2.0.0上，他们设置为patch。
以下是痛点：从projecta-1.3.7分支执行发布时，我们希望将新标记（minor）合并到{{1} }和major分支。
问题在于，即使我们只修改了补丁分支上的一个.java文件（说它是一个关键的错误修正），每次我们都必须经历解决每个pom.xml和MANIFEST.MF文件的冲突。所以这个：
git checkout minor
git merge projecta-1.3.7
minor获得错误修复（woo hoo！）但也的结果要求我们通过补丁版本比较所有projecta-1.3.7项目之间的冲突，以及使用次要版本的minor项目。
有没有办法告诉Git，作为合并命令的一部分，我们要对pom.xml, MANIFEST.MF使用“我们的”策略，但任何其他冲突应该是使用默认策略解决？
答案 0 :(得分：3)
我通常通过将错误修复的代码更改作为单独的提交提交来提升版本＃（我假设是对pom.xml和MANIFEST文件的更改）来处理此问题。然后，我可以将代码更改提交正常合并到其他分支，然后最后“假冒”将“版本＃bump”更改为merge --strategy=ours单独更改。
Op问道：
我们的流程是：（1）发布项目1.3.7（2）将标签合并到未来的分支机构（'minor'）（3）将POM / MANIFEST更新为1.3.8，（4）......工作.. （5）然后，几周后，再次从（1）开始。
好的，我的流程有点不同，但是按照你的流程，如果第3步生成了＃1234ABCD，那么我会另外做第3a步：
$ git checkout MAINLINE
$ git merge --strategy=ours 1234ABCD
这将确保当你循环回arond并在将来点击步骤＃2时，版本#gump将被视为合并并被忽略。
或者，直到稍后才做3a。当你将来到达第2步时，然后执行＃1234ABCD的虚假合并，然后在＃1234ABCD之后合并分支上的所有提交。当您再次在分支中碰撞版本＃时 - “假合并”它（立即或稍后）。
核心思想只是隔离提交版本＃和“假”将其单独合并 - 当你这样做取决于你。即使版本#gump在你要合并的分支上的提交中间，然后合并所有其他提交之前的那个提交，然后假合并碰撞版本＃，然后合并所有提交在那之后。
这是我上周做的合并的粗略图片。提示左边距是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
| |