推送合并冲突的分支

Question

在我们的项目中，我们每季度发布2个月用于开发，1个月用于UAT。我们是一个非常大的项目，我们的项目中有大约20个团队，每个团队都在处理一些不同的模块。

所以我们如何遵循的是我们继续为master工作，2个月后我们创建了一个发布版本，例如发布版本，例如RELEASE_VERSION_20.1。发布后，我们将RELEASE分支合并回master。

现在我们必然会在RELEASE_VERSION分支和master之间产生冲突。现在，其中一位开发人员负责将RELEASE_VERSION合并到master。因此，我们创建分支或master说merge_RV20.1_into_master。然后，他/她尝试解决冲突，但他们可能不了解每个模块，并可能最终做错合并，即master中的某些更改可能会被覆盖，或者发布分支的某些更改可能会丢失。

那么我们是否有办法创建合并分支merge_RV20.1_into_master。有所有冲突，我们可以将这个分支推送到远程，这样每个团队的1个开发人员可以检查这个分支并解决他们所知道的冲突并推送到远程？

Answer 1

理论上，您可以使用合并标记添加和提交文件，以便将来解决。

git checkout -b merge_RV20.1_into_master master
git merge RELEASE_VERSION_20.1
# add everything, including files with conflict markers in them
git add .
git commit -m "merge with conflicts"

可是：

• 您将无法再在合并工具中看到它们。
• 您必须为这些合并标记进行grep，以便逐个文件地解析它们。
• 默认冲突标记不提及基础（共同祖先），这将使任何未来的解决方案变得复杂（请参阅＆＃34; Why is a 3-way merge advantageous over a 2-way merge?＆＃34;）

如果您仍想这样做，请至少将merge.conflictstyle设置为diff3。请参阅＆＃34; Checking Out Conflicts＆＃34;：

def hello
<<<<<<< ours
  puts 'hola world'
||||||| base
  puts 'hello world'
=======
  puts 'hello mundo'
>>>>>>> theirs
end

这样，未来的评论不仅仅基于＆＃34;我们的＆＃34; ＆＃34;他们的＆＃34;，但也＆＃34;普通＆＃34;：你会知道自上一个普通版本以来哪一方发生了变化。

Answer 2

  

那么我们是否有办法创建合并分支merge_RV20.1_into_master。

     

有所有冲突，我们可以将这个分支推送到远程，这样每个团队的1个开发人员可以检查这个分支并解决他们所知道的冲突并推送到远程？

如果可以，您应该使用拉取请求来执行此操作。 Pull请求会显示差异，因此您可以在将任何提交返回主分支之前检查它们。

这是一个来自github的例子，它们如何显示拉取请求的变化。

Answer 3

对于我的意见，不应该直接在发布分支上进行提交。相反，开发人员应该拥有他们将从中执行的功能分支 - 一个进入发布分支，一个进入合并。这将防止所有（或大部分）冲突。

此外，请解释需要从发布分支合并回master的动机，以及在发布分支上完成的更改（以及如何管理）。