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 属性来定义一个特定文件或一组文件的合并策略。

请参阅此处了解更多详情。

它允许您定义如下所示的属性，其中对于database.xml文件，合并时始终使用我们的一侧，不允许在合并期间对该文件进行任何传入更改：

database.xml merge=ours

您将在您的存储库中的.gitattributes文件中定义上述内容。

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

build.gradle merge=ours