摘樱桃

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更改为包含＆＃34;版本1.0.8＆＃34 ;.但是，如果我这样做，合并到下一个版本分支将在该文件上产生冲突。

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

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

Answer 1

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

摘樱桃

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

通过挑选，您可以将单个提交从一个分支迁移到另一个分支。这样可以更好地工作，因为您可以选择要迁移的部分。

git cherry-pick 1234567

这将采用上述哈希标识的提交（它可以在任何分支上，在release/1.0的情况下）并在当前分支上应用提交。它只包含来自这一次提交的更改，没有别的。

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

Git Attributes

如果不是您正在寻找的挑选，您可以使用Git属性为特定文件或一组文件定义合并策略。

有关详细信息，请参阅here。

它允许您定义如下所示的属性，对于database.xml文件，在合并时始终使用我们的方，在此文件的合并期间不允许任何传入的更改：< / p>

database.xml merge=ours

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

在你的情况下，你可能会使用像

这样的东西

build.gradle merge=ours

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

1 个答案:

摘樱桃

Git Attributes