Git合并发布分支冲突，因为版本发生了微小的更改

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

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"

现在，假设我修复了branch

release/1.0

中的一个bug。然后我想将这个分支合并到下两个分支，以传播修复。总的来说，这将非常顺利

但是，在修复

release/1.0

中的bug时，我还希望将其补丁版本从1.0.7升级到1.0.8，将build.gradle文件更改为包含“version 1.0.8”。但是如果我这样做，合并到下一版本分支将在该文件上创建冲突

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

---

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

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

樱桃采摘 我发现，与合并相比，

git cherry pick

的效果要好得多。通过合并，您将遇到您正在描述的问题，而版本号可能只是该问题的一个实例。随着分支进一步分化，您将发现其他不容易解决的冲突。由于合并将始终尝试从创建分支的位置进行合并，因此在许多情况下，引入了太多的更改

通过cherry picking，您可以将单个提交从一个分支迁移到另一个分支。这样做效果更好，因为您可以选择要移植的零件

git cherry-pick 1234567

这将采用上述散列所标识的提交（它可以在任何分支上，在您的情况下，在

release/1.0

）并将提交应用于当前分支。它将只包括这次提交的更改，而不包括其他更改

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

Git属性 如果cherry picking不是您想要的，那么可以使用Git属性为特定文件或一组文件定义合并策略

有关更多详细信息，请参阅

它允许您定义如下属性，其中对于

database.xml

文件，在合并时始终使用我方，不允许在此文件合并期间进行任何传入更改：

database.xml merge=ours

您可以在repo中的

.gittributes

文件中定义上述内容

在您的情况下，您可能会使用

build.gradle merge=ours

---

谢谢@nwinkler。我明白你的意思，不过我还是很难选择樱桃树。我想这也取决于，正如你所说，分支的分叉程度。在这样一个环境中，它们没有太大的差异，并且它们加起来与前面的相同，我认为合并更合适。也有很多帖子是关于如何在一开始就不应该使用cherry pick的。也许，像往常一样，真相在中间。我确实使用cherry pick，但只在少数特定情况下使用。我会喜欢一个基于合并的解决方案，即使这意味着意识到我使用了错误的分支模型！你可以在这里找到答案：多亏了这个链接，我找到了关于git属性的链接，这可能就是我的解决方案。如果你更新你的答案，把它作为另一个可能的解决方案，我会接受它。