Question

我在处理功能或问题时使用Github.com并正常创建主题分支。

假设我正在处理多个并行处理共享文件（比如配置）的主题，这些主题需要在底部添加代码，我无法将PR发送到Github.com，因为它已经开始了反正是冲突。

例如，假设我有一个共同的配置文件C，由文件M1 ... Mn表示的所有模块共享。我从名为M1-Feature的主人开始了一个Topic分支，并且确实提交了M1和C（只有附加一些行到C）。再次从Master-for M2-Bug开始一个主题分支，并致力于M2和C（只需附加某些行到C）等等。由于C是共享的，因此当我将其发送到最终合并时，由于行号而出现冲突。从本质上讲，这些PR并不是真正有效的，而且我的工作实际上是我提前知道的。

      /----m1-commit----c-commit
master
      \----m2-commit----c-commit

那么如何处理这个解决冲突的问题呢？

我正在考虑 cherry-picking 对文件C的提交，按照我最终希望它在主服务器中的顺序顺序到主题分支。但它创建了一个部分状态，即存在配置更改但不支持它的代码。

      /----m1-commit----c-commit(first)
master
      \----m2-commit----c-commit(first-cherry-pick)----c-commit

另一种方法是始终使用主题保持重新定位主题b。我认为这更好。这基本上是线性化所有提交，尽管它是并行发生的。

      /----m1-commit----c-commit(first)
master
      \----m1-commit----c-commit(first)----m2-commit-----c-commit(second)

我的目标是公关不应该等待解决冲突，因为我事先知道了！

Answer 1

您的最后一个选项（重新定位）是正确的方法，因为即使您有两个并行的主题分支，在您想要将它们集成到主服务器的那一刻，您必须决定订单 。所以它总是首先是主题A然后是主题B或主题B然后是主题A.因此其中一个将不得不处理另一个的变化。

为了减少拉取请求的冲突，我认为你在这里有一点问题，因为通常你不知道哪个功能会先集成。还有可能只集成一个主题分支。在这种情况下，您可以做的是将您的行动传达给整合您的拉动请求的人，并告诉他们使用哪个订单。

Answer 2

你所做的与git的正常操作程序没有什么不同。它旨在处理多个分支。这就是它存在的原因。

这基本上是线性化所有提交，虽然它是并行发生的。

它也在摧毁历史。正如你所说：他们并行发生。

我的目标是公关不应该等待解决冲突，因为我事先知道了！

只需使用git merge。

$ git checkout master
$ git merge M1-Feature 
<deal with any conflicts by editing the files in question>
$ git apply <files you've edited>
$ git commit
$ git push

然后从你的git repo发出拉取请求到有问题的那个

$ git checkout master
$ git merge M2-Bug
<deal with any conflicts by editing the files in question>
$ git apply <files you've edited>
$ git commit

然后从你的git repo发出拉取请求到有问题的那个

在处理多个主题分支时如何处理冲突？

2 个答案: