Git合并策略将'patch'分支集成到'minor'，'minor'分支到'major' [英] Git merge strategy for integrating 'patch' branch into 'minor', 'minor' branch into 'major'

问题描述

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

对于 ProjectA ， pom.xml 和 MANIFEST.MF 补丁分支上的设置为 1.3.7 ，而在 minor 它们被设置为 1.4.0 ，并且在 major 重新设置为 2.0.0 。

以下是难点：执行发布时从修补程序分支中，然后我们要将该新标记（ projecta-1.3.7 ）合并到次要和主要分支。

即使我们只修改了patch分支上的一个 .java 文件（假设它是一个严重的bug修复），每次我们都必须通过并解决每个 p的冲突om.xml 和 MANIFEST.MF 文件。所以这：

  git checkout minor 
 git merge projecta-1.3.7 
  

结果在 minor 获得bugfix（woo hoo！），然后也要求我们使用修补程序版本比较所有 projecta-1.3.7 项目与次要使用次要版本的项目。

有没有办法告诉Git，是合并命令的一部分，我们想要对 pom.xml，MANIFEST.MF 使用我们的策略，但是应该使用默认策略解决其他冲突？

$ b

解决方案

我通常通过将错误修复的代码更改作为独立提交（s）提交以提升版本＃（其中I假设是对pom.xml和MANIFEST文件的更改）。然后，我可以将代码更改提交合并到其他分支中，然后最后假将版本＃凹凸更改与 merge --strategy = ours 分开合并。

---

操作询问：

我们的过程是：（1）发布项目1.3.7（2）将标签合并到未来的分支中（'minor'）（3）将POM / MANIFEST更新为1.3.8，（4）... work ...（5） ），然后，几个星期后，再次回到（1）。

好的，我的流程有点不同，你的流程，如果第3步生成提交＃1234ABCD，那么我会额外做第3a步：

  $ git checkout MAINLINE 
 $ git merge --strategy = our 1234ABCD 
  

这样可以确保当你循环回去并且命中步骤＃2，版本＃bump将被视为合并并被忽略。

另外，不要做3a直到后来。在将来到达第2步时，请执行＃1234ABCD的假合并，然后在＃1234ABCD之后合并分支上的所有提交。当你在分支中再次碰到版本＃ - 假合并它（立即或以后）。

核心思想是隔离提交碰撞版本＃和假分开合并 - 当你这样做取决于你。即使版本＃bump位于要合并的分支上的提交中间，然后将所有其他提交合并到第一个提交之前，然后合并碰撞版本＃的合并，然后合并所有提交在那之后。

---

下面是我上周做过的合并的粗略图片。向下提交左边界是MAINLINE开发，不在RELEASEBRANCH（维护分支）中的左边界。提交顺序与您的流程不匹配，但无关紧要。

  * bc26f91 Oct 31假合并IT17p2忽略不适用的提交：所有web应用程序：等等等等等等等等等等等等等等等等等等等等等等等等等。 * 3cd69ad 10月31日所有网络应用程序：新版本的发布版本（RELEASEBRANCH）
 * | 8eae339 10月31日从IT17p2合并修复程序：所有网络应用程序：等等等等等等等等等等。 | / 
 | * 3612072 Oct 31所有网络应用程序：等等等等等等等| 
  

We have a repository containing a number of Java projects (~20 or so) built by Maven.

We have 3 branches in our repository, patch, minor, and major.

For ProjectA, the pom.xml and MANIFEST.MF on the patch branches are set to 1.3.7, while on minor they're set to 1.4.0, and on major they're set to 2.0.0.

Here's the pain point: When performing a release from the patch branch, we then want to merge that new tag (projecta-1.3.7) forward into the minor and major branches.

The issue, is that even if we've only changed one .java file on the patch branch (say it was a critical bugfix), every time we have to go through and resolve the conflicts for every one of the pom.xml and MANIFEST.MF files. So this:

git checkout minor
git merge projecta-1.3.7

Results in minor getting the bugfix (woo hoo!) but then also requires us to go through and compare the conflict between all the projecta-1.3.7 projects using patch versions, and the minor projects using minor versions.

Is there a way to tell Git, as part of the merge command, that we want to use the 'ours' strategy for both pom.xml, MANIFEST.MF, but that any other conflicts should be resolved using the default strategy?

解决方案

I usually handle this by committing the code changes for the bug fix as a separate commit(s) from the commit to bump up the version # (which I assume is the change to the pom.xml and MANIFEST files). I can then merge the code change commits into the other branches normally and then lastly "fake" merge the "version # bump" change separately with merge --strategy=ours.

---

Op asks:

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.

Okay, my flow was a little different, but following your flow, if step 3 generated commit #1234ABCD, then I would additional do step 3a:

$ git checkout MAINLINE
$ git merge --strategy=ours 1234ABCD

This will ensure that when you loop back arond and hit step #2 in the future, the version # bump will have been considered merged and be ignored.

Alternatively, don't do 3a until later. When you reach step #2 in the future, then do the fake merge of #1234ABCD and then merge all the commits on the branch after #1234ABCD. When you bump the version # in the branch again - "fake merge" it (immediately or later).

The core idea is just to isolate the commit the bumps the version # and "fake" merge it separately - when you do that is up to you. Even if the version # bump is in the middle of the commits on the branch you want to merge, then merge all the other commits before the one that one first, then fake merge the one that bumps the version #, then merge all the commits after that one.

---

Here's a rough pic of a merge I did last week. Commits down the left margin are MAINLINE development, the ones not on the left margin where made in the RELEASEBRANCH (maintenance branch). The commit order doesn't match your flow, but that doesn't matter.

*   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合并策略将'patch'分支集成到'minor'，'minor'分支到'major'的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！