Git有没有办法让未来的合并忽略分支之间pom文件中的版本号差异？

Question

我的团队正计划从 Perforce 切换到 Git，我正试图找到一种方法让 Git 忽略分支之间的 pom 版本差异。这在 Perforce 中运行良好，我没有运气用 Git 重现该行为。

这是我的步骤：

1. 结帐父分支

   ndeckard@ws /c/dev/proj/testgit (master)
   $ git checkout release/1.0
   Switched to branch 'release/1.0'
   Your branch is up-to-date with 'origin/release/1.0'.
   

2. 从中创建子分支

   ndeckard@ws /c/dev/proj/testgit (release/1.0)
   $ git branch branch/FEA-650
   

3. 切换到新分支

   ndeckard@ws /c/dev/proj/testgit (release/1.0)
   $ git checkout branch/FEA-650
   Switched to branch 'branch/FEA-650'
   

4. 更新子分支pom版本

   <version>1.0.0-FEA-650-SNAPSHOT</version>
   

5. 添加并提交

   ndeckard@ws /c/dev/proj/testgit (branch/FEA-650)
   $ git status
   On branch branch/FEA-650
   Changes not staged for commit:
     (use "git add <file>..." to update what will be committed)
     (use "git checkout -- <file>..." to discard changes in working directory)
   
           modified:   pom.xml
   
   no changes added to commit (use "git add" and/or "git commit -a")
   
   ndeckard@ws /c/dev/proj/testgit (branch/FEA-650)
   $ git add pom.xml
   
   ndeckard@ws /c/dev/proj/testgit (branch/FEA-650)
   $ git commit -m "set feature branch pom version"
   [branch/FEA-650 59e156e] set feature branch pom version
   1 file changed, 1 insertion(+), 1 deletion(-)
   

6. 切换回父分支

   ndeckard@ws /c/dev/proj/testgit (branch/FEA-650)
   $ git checkout release/1.0
   Switched to branch 'release/1.0'
   Your branch is up-to-date with 'origin/release/1.0'.
   

7. 将子分支合并到父自动接受的父分支版本中（使用“我们的”合并策略）

   ndeckard@ws /c/dev/proj/testgit (release/1.0)
   $ git merge branch/FEA-650 -s ours
   Merge made by the 'ours' strategy.
   

8. 尝试第二次将孩子合并到父母中（已经是最新的。）很好。这就是我想要的

   ndeckard@ws /c/dev/proj/testgit (release/1.0)
   $ git merge branch/FEA-650
   Already up-to-date.
   

9. 签出子节点并将父节点合并到子节点（它快进并将父分支 pom 版本粘贴在子节点上）。不好。我需要它像上面一样说“已经是最新的”，并保持子分支 pom 版本已经在子分支上

   ndeckard@ws /c/dev/proj/testgit (release/1.0)
   $ git checkout branch/FEA-650
   Switched to branch 'branch/FEA-650'
   
   ndeckard@ws /c/dev/proj/testgit (branch/FEA-650)
   $ git merge release/1.0
   Updating 59e156e..2f3a2a0
   Fast-forward
   pom.xml | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
   

在第 7 步之后，我想在父母和孩子之间的任一方向合并说（已经是最新的。）

Git 有没有办法让未来的合并忽略分支之间 pom 文件中的版本号差异？

Answer 1

我最初的想法是通过部分外部化 POM <version> 计算来自动化您的 POM 版本号，请参阅答案。如果您不想这样做，那么您需要重新评估您的 Git 工作流程。

两种方式合并，进入master，然后回到特性分支会导致问题。您的 git merge branch/FEA-650 -s ours 使用 ours 策略告诉 Git 您已将功能分支中的 所有 提交和更改集成到 master，包括您的 pom.xml 版本更改，这丢失，master 保留其版本。 master 分支现在认为特性分支的 HEAD 是一个共同的祖先（它是合并时的父提交），所以当你将它合并回特性分支时，Git 说“当你合并到 master 时一切都已解决，没有变化……快进”。

简单的答案是你应该在合并到 master 之后重新分支到一个新的特性分支，给你的特性分支一个新的/以后最年轻的共同祖先，然后你需要以某种方式重放你的 POM <version> 更改。您不应继续在原始功能分支上工作，因为它已被合并。要从 master 获取新的更改，您应该重新分支。似乎有些暗示您可能在未与 master 合并的功能分支上留下了更改，否则您将不再需要它并可以重新分支，或者它可能只是您感兴趣的 <version> 更改提交.

有许多方法可以简化/加速/自动化重新分支时的版本号管理，从外部化（见下文）到 cherry-picking 从占位符分支，使用 Maven 插件，例如Versions Maven Plugin.

原答案

另一种方法是根据分支元数据或来自 CI 的其他输入从外部计算 POM 文件之外的最终/有效<version>。在 Maven 中执行此操作有点棘手，无需在结帐后自行预先设置 pom.xml，但请查看 Maven External Version Plugin。

它与 Maven 生命周期挂钩，并将即时构建一个 pom.xml.new-version 文件（您可以 .gitignore），根据您提供的任何内容动态替换全部或部分版本号 - 功能分支名称、git commit hash 等。

构建/部署插件并将其添加到您的 POM：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-external-version-plugin</artifactId>
    <version>0.1.0-SNAPSHOT</version>
    <extensions>true</extensions>
    <configuration>
        <strategy hint="sysprop"/>
    </configuration>
</plugin>

...然后通过替换版本字符串获得创意，例如您可以：

mvn install -Dexternal.version-qualifier=$(git symbolic-ref --short HEAD| sed s_^master\$__)

...如果当前签出的 Git 分支是 FEA-650，这会将 1.2.3-SNAPSHOT 更改为 1.2.3-FEA-650-SNAPSHOT。您可能需要考虑在您的分支命名策略中将/ 替换为-，具体取决于Maven 的想法（我发现/s 令人困惑，但这只是我），或者相应地修改sed .

在最坏的情况下，这将允许您从 POM 中删除您的版本号，因此可以安全地合并其他 POM 更改并且已知与版本号无关 - 如有必要，您可以将版本号保留在另一个文件中，使用 Maven 属性插件加载它们并在需要时替换整个版本号。

Answer 2

每次合并都这样做可能会很麻烦，但这里有一个想法。

git merge --no-ff --no-commit <other-branch>

git checkout HEAD -- pom.xml

第一个命令允许您在合并完成之前进行内容更改，即使没有任何合并冲突。第二个将 pom.xml 替换为当前分支上一次提交中的任何内容 - 有效地忽略了来自另一个分支的 pom.xml。

如果在 pom.xml 以外的任何文件中存在冲突，使用合并策略 --ours 是有问题的，所以我会厌倦将它用于此目的。