Question

方案：在git中有每个（活动）版本的分支，

顺序是：

Bob对 R1 进行更改，提交，拉 R1 并将 R1 推送到共享。不会在共享上更新 R2 。
Jane对 R1 进行了更改，提交。
Jane从共享中提取 R1 ，处理任何冲突，推送 R1 。
再次转到第1步
Jane被告知他们需要通过 R1

R2

Jane从共享

R1

R2

Jane在本地将 R1 合并到 R2 。合并Bob在其中工作的某些代码区域的冲突。

Jane必须从共享中获取R2并在她可以推送之前处理合并。但是，她不知道如何处理鲍勃的变化。

分支机构： R1 ， R2

 State of Shared Repository

 C1    - Bob
 |
 C2-+  - Jane
 |  |
 |  C3 - George
 |  |
 |  C4
 C5 |  - Bob
 |  |
 C6 |  - Jane  [R1]
    |
    C7 - Alice [R2]

Bob和Jane对 R1

Jane然后想将 R1 合并到 R2 以更新最新版本。她解决了由她的变化引起的合并冲突，但她不知道如何解决因鲍勃所做的变化而导致的冲突。

Jane是否有办法使用git并让Bob完成合并？

我理所当然地知道，Bob已经将他的更改合并到 R2 ，但是假设情况并非如此。

可能的解决方法（寻找更好的东西）

Jane打电话给Bob，然后Bob解决了冲突。远程办公时很难
Jane将冲突的文件和电子邮件保存到Bob，Bob修复文件并将其通过电子邮件发送给Jane，然后Jane在她的提交中使用它们。

Answer 1

假设Bob被封锁且Jane急于推动此问题，Jane会尽最大努力进行合并。

$ git fetch
$ git checkout R2
$ git merge --ff-only origin/R2
$ git checkout -b wip/R2-with-R1

以上wip代表正在进行中的工作，并且是一项向团队发出信号，表明树木和历史会发生根本性变化的惯例。也许Jane真的希望Bob在将它们集成到基线之前查看影响他的R1代码的分辨率。（注意：这是一种反模式;更好的方法是使用自动化测试来保护R1中新代码的所需行为，并允许Bob以外的开发人员自信地合并。）

Jane在合并中做出了最好的尝试。

$ git merge origin/R1
$ hack
$ git add ..
$ hack
$ git add ..

wip / R2-with-R1分支甚至可能包含多个检查点样式的提交。每个包含的另一个好信号会让团队知道它是推测性的。

$ git commit -m 'FIXME: fix conflicts in Potrzebie'

当她准备让鲍勃看着它时，她会把它推到一个他们都可以看到的存储库

$ git push --set-upstream origin wip/R2-with-R1

如果他们需要在新分支上协同工作，那么--set-upstream选项就会存在。

然后，她启动了她的邮件用户代理。

To: Bob
From: Jane
Subject: speculative merge: wip/R2-with-R1

Bob: please look over my attempted merge in the subject branch and make
any necessary fixes that I may have overlooked.

I am particularly concerned about my Potrzebie conflict-resolutions.
Changes there always seem to bite us one way or the other.

Thanks,
Jane

在鲍勃修复和获取之后，历史将类似于

$ git lola
* 77d472c (origin/wip/R2-with-R1) fix by Bob
* ba1eb24 (HEAD, wip/R2-with-R1) FIXME: merge 2
*   80c207d FIXME: merge 1
|\
| * 2cf6ad4 (origin/R1, R1) R1 #2
* | 137b39d (origin/R2, R2) R2 #2
* | cb9a761 R2
...

此时，Jane希望保留合并但不想保留丑陋的检查点提交。压缩到合并提交只需要一点小心。

$ echo Merge R1 into R2 | \
  git commit-tree origin/wip/R2-with-R1^{tree} \
  -p $(git rev-parse origin/R1) -p $(git rev-parse origin/R2)
84b177c498bc635612b66932f3d41096999e6d3f

$ git checkout R2
Switched to branch 'R2'

$ git merge --ff-only 84b177c498bc635612b66932f3d41096999e6d3f
Updating 137b39d..84b177c
Fast-forward
...

这留下了

的历史

$ git lola
*   84b177c (HEAD, R2) Merge R1 into R2
|\
| | * 77d472c (origin/wip/R2-with-R1) fix by Bob
| | * ba1eb24 FIXME: merge 2
| | *   80c207d (wip/R2-with-R1) FIXME: merge 1
| | |\
| |/ /
| | /
| |/
|/|
* | 2cf6ad4 (origin/R1, R1) R1 #2
| * 137b39d (origin/R2) R2 #2
| * cb9a761 R2
...

和R2现在通过构建与Bob的最终树相同的树。

Answer 2

除了Jane打电话给她的办公桌并在她的电脑上查看更改之外，我认为这不能用git完成。

正在解决合并时，您正在创建一个新的提交，这一切都在本地发生。 Jane可以进行合并，并决定不将更改推送到远程。在推送合并提交之前，无法知道是否有其他人合并到他们的遥控器副本中。 Jane必须解决提交才能完成合并，而这只是在本地发生。

无论如何，在遥控器中进行未合并的更改似乎是一个坏主意。假设我开始使用repo并在Bob完成解决冲突之前进行更改。那么呢？

Jane知道她是否解决了提交的另一种方式是她有一个测试套件可以运行。然后她知道在测试开始失败时她犯了一个错误。

Answer 3

我们处于类似情况。

这是我们在一些不同的失败方法之后以某种方式工作的方式。关键是如何通过远程存储库分享冲突的帅哥。

Jane从R2的顶端创建了两个分支，并将R1合并到它们上面与一套“互补”合并策略;

$ git branch wip/reference R2
$ git checkout wip/reference
$ git merge -s recursive -X theirs R1

$ git branch wip/merging R2
$ git checkout wip/merging
$ git merge -s recursive -X ours R1

现在
```
$ git diff wip/reference..wip/merging
```
显示R1将如何与R2冲突，因为'-s递归-X我们/他们的'合并策略“通过支持我们/他们的版本来强制冲突的帅哥干净地自动解决。”
Jane对wip / merge进行必要的更改，以解决之前更改导致的“虚拟”冲突，并保持Bob不受影响。
然后Jane推wip / reference和wip / merge，并调用/ IM / email / owlpost Bob获取它们。
Bob检查虚拟冲突和中途分辨率Jane 制定并进一步改变他过去改变的冲突引起的。
然后，如果他觉得一切都很好或者可选择让George / Alice做出进一步的决议，他会将wip / merge合并回R2。

我们仍在调查这会影响以后的合并（例如，如果git rerere正常工作）。

Answer 4

如果我正确理解了行动顺序，则如下：

Bob对R1进行更改，提交，与他的R2副本合并并推送到共享。
Jane对R1进行更改，提交，与她的R2副本合并，并尝试推送到共享，但得到过时的错误。
Jane必须从共享中获取R2并在她可以推送之前处理合并。但是，她不知道如何处理鲍勃的变化。

在这种情况下，Jane和Bob可以执行以下操作：

Jane可以在共享上创建一个包含她对R2的更改的分支：
```
git push origin R2:R2-from-Jane
```
Jane然后可以打电话/发送电子邮件/ IM Bob并要求他合并他的更改。
鲍勃不满地叹了口气，不得不再次再次， ^{为什么简总是如此紧张地将她的变化与他合并？这很愚蠢......} 然后从服务器解析与Jane的分支的合并：
```
git fetch origin R2-from-Jane
git checkout R2
git merge R2-from-Jane
git push
git branch -d R2-from-Jane
```
Bob回复Jane，让她知道合并已经完成。
Jane从服务器中删除了她的临时分支：
```
git push origin :R2-from-Jane
```
然后回复谢谢鲍勃。 ^{然后让他去喝咖啡，也许......}

（显然，Bob也可以处理删除Jane在服务器上的临时分支，但这也不符合叙述。）

合作修复合并冲突

4 个答案: