合作修复合并冲突

Question

场景:在git中有每个(活动)版本的分支,

顺序是:

1. Bob对R1进行更改,提交,拉取R1并将R1推送到共享.不在共享上更新R2.
2. Jane对R1进行更改,提交.
3. Jane 从共享中拉出R1,处理任何冲突,推送R1.
4. 再次转到步骤1几次
5. Jane被告知他们需要让R2与R1的修复程序保持同步
6. Jane 从共享中拉出R1和R2
7. 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中,但是假设情况并非如此.

可能的解决方法(寻找更好的东西)

1. 简打电话给鲍勃,然后鲍勃解决冲突.远程办公很困难
2. 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以外的开发人员自信地合并.)

简是她合并的最佳尝试.

$ 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的最终树相同的树.