4

我们有一个存储库，其中包含由 Maven 构建的许多 Java 项目（大约 20 个）。

我们的存储库中有 3 个分支patch，minor、 和major。

对于ProjectA，分支上的pom.xml和设置为，而 on他们设置为，并且在他们设置为。MANIFEST.MFpatch1.3.7minor1.4.0major2.0.0

这是痛点：当从分支执行发布patch时，我们希望将新标签 ( projecta-1.3.7) 向前合并到minorandmajor分支中。

问题在于，即使我们只更改.java了补丁分支上的一个文件（比如说这是一个关键的错误修复），每次pom.xml我们都必须检查并解决每个MANIFEST.MF文件的冲突。所以这：

git checkout minor
git merge projecta-1.3.7

结果minor得到了错误修复（哇哦！），但也需要我们仔细比较所有projecta-1.3.7使用补丁版本的minor项目和使用次要版本的项目之间的冲突。

有没有办法告诉 Git，作为合并命令的一部分，我们想对两者都使用“我们的”策略pom.xml, MANIFEST.MF，但是应该使用默认策略解决任何其他冲突？

4

1 回答 1

3

我通常通过将错误修复的代码更改提交为与提交不同的提交来处理此问题，以提高版本#（我假设这是对 pom.xml 和 MANIFEST 文件的更改）。然后我可以正常地将代码更改提交合并到其他分支中，然后最后“伪造”将“版本#bump”更改与merge --strategy=ours.

欧普问：

我们的流程是：(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

这将确保当您循环返回并在将来点击步骤 #2 时，版本 #bump 将被视为合并并被忽略。

或者，直到稍后再执行 3a。当您将来到达第 2 步时，请进行 #1234ABCD 的假合并，然后在 #1234ABCD 之后合并分支上的所有提交。当您再次在分支中更改版本号时 - “假合并”它（立即或稍后）。

核心思想只是将提交与版本号隔离开来，并“假”将其单独合并-何时执行取决于您。即使版本#bump 在您要合并的分支上的提交中间，然后先合并该提交之前的所有其他提交，然后伪造合并版本# 的提交，然后合并所有提交在那之后。

这是我上周进行的合并的粗略图片。左边距下的提交是主线开发，不在左边距上的提交是在 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
| |
于 2013-11-05T17:22:24.920 回答