由于较小的版本更改，Git 合并发布分支冲突

Question

对于一个项目，假设我有一些发布分支：

release/1.2
release/1.1
release/1.0

这些发布分支基于次要版本。因为它们一直受到支持，所以它们中的每一个都将处于不同的补丁版本，存储在某个构建配置文件的某个位置（在我的例子中是 gradle）。例如：

release/1.2
  build.gradle contains "version 1.2.1"
release/1.1
  build.gradle contains "version 1.1.4"
release/1.0
  build.gradle contains "version 1.0.7"

现在，假设我修复了分支 release/1.0 中的错误。然后我想将此分支合并到下两个分支，以传播修复。一般来说，这会很顺利。

但是，在修复release/1.0 中的错误时，我还想将其补丁版本从 1.0.7 更改为 1.0.8，将文件 build.gradle 更改为包含“版本 1.0.8”。但如果我这样做，合并到下一个版本分支将在该文件上产生冲突。

显然，必须有更好的方法来支持我最初的意图。在这种情况下，最佳做法是什么？

我能想到的一种方法是不将完整版本存储在文件中，而仅使用 git 标签，然后让 gradle（或任何其他构建工具）从 git 标签中获取完整版本。这种方法的一个主要缺点是构建会在从 git 导出的源库上失败。

Answer 1

想到了两种可能的解决方案：

樱桃采摘

我发现git cherry-pick 不是合并，而是工作得更好。通过合并，您会遇到您所描述的问题，并且版本号可能只是其中的一个实例。随着分支进一步分歧，您会发现其他不容易解决的冲突。由于合并将始终尝试从创建分支的点开始合并，因此在许多情况下，会引入太多更改。

使用cherry-picking，您可以将单个提交从一个分支迁移到另一个分支。这会更好，因为您可以选择要迁移的部分。

git cherry-pick 1234567

这将采用由提到的哈希标识的提交（它可以在任何分支上，在您的情况下为 release/1.0）并将提交应用到您当前的分支上。它将只包括这次提交的更改，没有其他内容。

对我来说，这比在支持分支之间合并要好得多，因为我可以只获取我想要修复的部分，并且不包括来自先前或不相关提交的任何其他更改。

Git 属性

如果樱桃采摘不是您想要的，您可以使用 Git 属性为特定文件或一组文件定义 merge-strategy。

更多详情请见here。

它允许您定义如下属性，其中对于 database.xml 文件，在合并时始终使用 our 端，在此文件合并期间不允许任何传入更改：

database.xml merge=ours

您可以在 repo 的 .gitattributes 文件中定义上述内容。

在你的情况下，你可能会使用类似的东西

build.gradle merge=ours