10

场景：在 git 中每个（活动）版本都有一个分支，

顺序是：

  1. Bob 对R1进行更改、提交、拉取R1并将R1推送到共享。不更新共享的R2。
  2. Jane 对R1进行更改，提交。
  3. Jane 从 shared 中拉出R1，处理任何冲突，推送R1。
  4. 重复步骤 1几次
  5. Jane 被告知他们需要通过R1的修复来更新R2
  6. Jane从 shared 中拉取R1和R2
  7. Jane在本地将R1合并到R2中。在 Bob 处理的代码的某些区域中合并冲突。

Jane 必须先从 shared 获取 R2 并处理合并，然后才能推送。但是，她不知道如何处理 Bob 的更改。

分支：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以更新最新版本。她解决了由她的更改引起的合并冲突，但是她不知道如何解决由 Bob 所做的更改引起的冲突。

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

我知道理想情况下，Bob 已经将他的更改合并到R2中，但假设情况并非如此。

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

  1. Jane 将 Bob 叫到她的办公桌前，然后 Bob 解决了冲突。远程办公很困难
  2. Jane 将冲突的文件和电子邮件保存给 Bob，Bob 修复文件并将它们通过电子邮件发送给 Jane，Jane 然后在她的提交中使用它们。
4

4 回答 4

7

假设 Bob 被阻止并且 Jane 急于解决问题，Jane 会尽最大努力执行合并。

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

以上 wip 代表正在进行的工作，是一种约定，向团队表明树和历史将发生根本变化。也许 Jane 真的希望 Bob 在将它们集成到基线之前查看影响 R1 代码的她的决议。（注意：这是一种反模式；更好的方法是使用自动化测试来保护 R1 中新代码的预期行为，并允许 Bob 以外的开发人员自信地合并。）

简在合并方面做出了最大的尝试。

$ git 合并原点/R1
$黑客
$ 混帐添加 ..
$ hack 
$ git add ..

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

$ git commit -m 'FIXME：修复 Potrzebie 中的冲突'

当她准备好让 Bob 查看它时，她会将其推送到他们都可以看到的存储库

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

--set-upstream如果他们需要在新分支上协作工作，则可以选择该选项。

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

致：鲍勃
来自：简
主题：投机合并：wip/R2-with-R1

Bob：请查看我在主题分支中尝试的合并并进行
我可能忽略的任何必要修复。

我特别担心我的 Potrzebie 冲突解决方案。
那里的变化似乎总是以一种或另一种方式咬我们。

谢谢，
简

在 Bob 的修复和获取之后，历史将类似于

$ 混帐萝拉
* 77d472c (origin/wip/R2-with-R1) 由 Bob 修复
* ba1eb24 (HEAD, wip/R2-with-R1) FIXME: 合并 2
* 80c207d FIXME：合并 1
|\
| * 2cf6ad4（原点/R1，R1）R1 #2
* | 137b39d（原点/R2，R2）R2 #2
* | cb9a761 R2
...

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

$ echo 将 R1 合并到 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
切换到分支“R2”

$ git merge --ff-only 84b177c498bc635612b66932f3d41096999e6d3f
更新 137b39d..84b177c
快进
...

这留下了一段历史

$ 混帐萝拉
* 84b177c (HEAD, R2) 将 R1 合并到 R2
|\
| | * 77d472c (origin/wip/R2-with-R1) 由 Bob 修复
| | * ba1eb24 FIXME：合并 2
| | * 80c207d (wip/R2-with-R1) FIXME: 合并 1
| | |\
| |/ /
| | /
| |/
|/|
* | 2cf6ad4（原点/R1，R1）R1 #2
| * 137b39d（原点/R2）R2 #2
| * cb9a761 R2
...

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

于 2013-07-18T20:00:32.790 回答
3

除了 Jane 将 Bob 叫到她的办公桌并在她的计算机上查看更改之外，我认为这不能在 git 中完成。

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

无论如何，在遥控器中进行未合并的更改似乎不是一个好主意。假设我在 Bob 解决冲突之前开始使用 repo 并拉取更改。然后怎样呢？

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

于 2013-07-18T18:14:19.637 回答
3

我们处于类似的情况。

这是我们在几次不同的失败方法之后发现的某种工作方式。关键是如何通过远程存储库共享冲突的大块。

  1. 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

  2. 现在

    $ git diff wip/reference..wip/merging

    显示 R1 如何与 R2 发生冲突，因为 '-s recursive -X ours/theirs' 合并策略“通过支持我们/他们的版本强制冲突的大块头被自动解决干净。”

  3. Jane 对 wip/merging 进行了必要的更改，以解决由她之前的更改引起的“虚拟”冲突，并使 Bob 保持不变。

  4. 然后 Jane 推送 wip/reference 和 wip/merging 并调用/IM/email/owlpost Bob 来获取它们。

  5. Bob 检查虚拟冲突和 Jane 做出的中途解决方案，并针对他过去的更改引起的冲突进行进一步的更改。

  6. 然后，如果他觉得一切看起来都不错，或者可以选择要求 George/Alice 做出进一步的解决方案，他会将 wip/merging 合并回 R2。

我们仍在调查这如何影响以后的合并（即 git rerere 是否正常工作）。

于 2014-01-30T00:56:46.190 回答
1

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

  1. Bob 对 R1 进行更改、提交、与他的 R2 副本合并并推送到共享。
  2. Jane 对 R1 进行更改、提交、与她的 R2 副本合并并尝试推送到共享，但收到一个过期错误。
  3. Jane 必须先从 shared 获取 R2 并处理合并，然后才能推送。但是，她不知道如何处理 Bob 的更改。

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

  1. Jane 可以在 shared 上创建一个分支，其中包含她对 R2 的更改：

    git push origin R2:R2-from-Jane
  2. 然后简可以打电话/发电子邮件/即时消息 Bob 并要求他合并他的更改。

  3. Bob 对不得不再次这样做感到不满地叹了口气，然后从服务器解决了与 Jane 分支的合并：

    git fetch origin R2-from-Jane
git checkout R2
git merge R2-from-Jane
git push
git branch -d R2-from-Jane
  4. Bob 回复 Jane，让她知道合并已完成。

  5. Jane 从服务器中删除了她的临时分支：

    git push origin :R2-from-Jane

    然后回复感谢 Bob。

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

于 2013-07-18T18:56:24.823 回答