Question

当将两个分支合并在一起导致1000多个冲突（分支机构分歧很多）时，能够在一个团队中划分这些工作的最佳做法是什么？

假设代码库位于包含20个项目的Visual Studio解决方案中，每个团队成员一次合并项目，解决冲突然后提交并推送到远程以便其他团队成员是有意义的可以获得已经完成的合并工作。

这是一个场景：

有3个分支：主分支，A和B. A分支主分支，B分支A分支。
分支A不断更新，但经常被推入主人。
B已经完成了很多工作，但很长一段时间没有将A合并到其中。
需要将A合并到B中以使B尽可能接近A以确保一切正常，然后最终将B合并到A中（然后A可以进入主模式，B可以删除）

我们遇到的问题是，只要团队成员将他们的A-＆gt; B合并工作推送到B，git就会假定从A到B合并的整个合并已经解决。

e.g。假设第一个团队成员想要将分支A的 Project1 合并到分支B的 Project1 中。他们将B分支关闭（称之为 B-submerge ）然后将A合并到 B-submerge 中，修复 Project1 中的冲突然后阶段，提交并将 Project1 文件推送到B。

这使得git相信在从A-> B合并时不需要进一步的合并工作。这意味着当另一个团队成员试图制作他们自己的 B-sumbmerge2 并将A合并到其中以解决 Project2 中的冲突时，git认为没有工作要做完成。

是否有可用于处理这种情况的策略？

Answer 1

历史

所以，你有以下分支，对吧？

 --o--o--------------o-----o--------o--------o   master 
       \            /     /        /        /          
        \          /     /        /        /           
         o--o--o--o--o--o--o--o--o--o--o--o--o--o--o   A
                \                                      
                 \                                     
                  o--o--o--o--o--o--o--o--o--o   B

我将描述解释为（不包括）“将Project1文件推送到B”，大致如下git命令：

cd /the/source/project1
get checkout -b project1.B_submerge B
git merge A
# Fix the conflicts
git add $the_modified_files_in_project1
git commit -m "Merge of branch A into project1"

问题

此时，您希望将分支project1.B_submerge合并到B，而不执行“{A <}}}合并导致的”从A合并的内容“属性（例如，创建{ {1}}以下版本。）

解决方案

可以使用X命令完成此操作。

---------o--------o   master
    /        /
   /        /
--o--o--o--o--o--o--o   A
                     \
                      \
--o--o--o--o--o-----------------X   B
               \        \      *
                \        \    *
                 o--------o--o   project1.B_submerge

git apply命令接受补丁并应用于当前分支，并通过从当前分支和其他任何东西提供差异，它将有效地使当前分支与其内容100％相同别的什么。

因此，这将使cd /the/source/project1 git checkout B git diff B project1.B_submerge | git apply git add . git commit -m "Merge of project1.B_submerge using git apply"分支的内容与git apply分支的内容相同，但没有任何合并引用。请注意，这将是一个单独的“压扁”提交。

注意：这将完全放弃在B命令后对project1.B_submerge进行的任何提交。如果有可能，请使用

创建目标分支

并在上面的git apply命令部分中使用它代替get checkout -b project1.B_submerge B，然后合并或重新绑定到git checkout -b target_B $(git merge-base B project1.B_submerge B)的提示。

Answer 2

@hlovdal的答案很好，但我会详细说明。

诀窍是在“B”之外创建一个“集成”分支，从而没有将“A”合并到其中。这可以防止git在合并历史方面出现任何混淆。

对于'B'的每个子分支

合并'A'
取消暂停因合并而自动显示的所有更改。
解决 project1 合并冲突。
为 project1
在提交 project1 之前和之后的点之间创建差异/补丁，例如git diff e5ffdee a3ae287 > merge_project1.diff

现在，在集成分支中，将修补程序应用于git apply <path to patch file>/merge_project1.diff

从那里，另一个合并 project2 的人现在可以获得 project1 修复。假设他们已经将A合并到他们的B分支中，他们：

现在可以使用git checkout origin/integration -- project1_dir

project1

集成

提交 project1 更改（到其本地分支）
解决 project2 更改
提交并提交 project2 更改
根据 project2 提交之前和之后的差异创建补丁。
将补丁应用于集成

当一切都完成后，集成可以合并到 A 。

如何在团队成员之间共享大型git合并

2 个答案:

历史

问题

解决方案