Git Rebase冲突：谁是负责人？

我有一个项目，远程回购有一个主要的开发分支，我有一个包含实验分支的分支。在我开始之前，我需要将开发分支的更改重新设置为实验分支的更改。所以它是这样的：

git checkout experimentalbranch
git fetch remoterepo
git rebase remoterepo/developmentbranch

这时，我遇到了冲突。但是，我对这些更改都不熟悉（我正在对数周的更改进行重定，因为它们没有立即合并我的更改）。而且，这是我第一次做

重设基础
。我更习惯于
合并

在meld中，它通常类似于
合并的
，这听起来非常直观。但是在
重新基址
，它是
。谁是头？是开发部门的
主管吗？它是开发部门或其他地方的最新代码吗？
TL；DR（于2018年5月增补）
从根本上讲，整个过程至少有点混乱，因为Git让它的内部工作直接显示给您

请注意，我们在这里关注的情况发生在您运行时：

git checkout somebranch; git rebase origin/their-branch

或类似的。rebase已暂时停止，以强制您解决合并冲突，之后您应该
git添加已解决的冲突并运行
git rebase--continue
。（如果您将某个合并工具与
git mergetool
一起使用，或者使用一个奇特的GUI界面，该界面可能会以其他方式为您完成部分或全部操作，但在下面，它是
git add
处理已解析的文件并运行
git rebase--continue
）

在一开始，
头
提交是他们的分支，因此如果您使用
git checkout——我们的
或
git checkout——他们的
，
--我们的
表示他们的
源代码/他们的分支
的最终提交，而
--他们的
表示您的第一次提交，您正在重定基。这是正常的日常Git混乱（请参阅），而不是导致最初问题的原因

然而，后来，
HEAD
commit实际上是一种混合体。这是在最新提交上复制一些提交的结果。现在，您自己的部分构建的新提交系列与您自己的原始提交之间存在冲突。这种冲突的根源通常是“他们”所做的事情（在
origin/this branch
的过程中发生了变化）。你仍然需要解决这一冲突。当您这样做时，您可能会在以后的提交中看到相同的冲突再次发生

同样，
头
或
本地
或
--我们的
是rebase通过组合您的更改和他们的更改而构建的一个提交，而另一个提交（
远程
或
>>>>
或
--他们的
）是您自己的提交，rebase正试图在
头
上复制它

比较长的
合并时（包括重新定基，这是内部重复“合并”的特殊情况），涉及两个“头”（两个特定分支提示）。让我们将它们称为
您的分支
和
来源/它们的分支
：

              G - H --------      <-- HEAD=your-branch
            /               \
... - E - F                   M   <-- desired merge commit [requires manual merge]
            \               /
              I - J - K - L       <-- origin/their-branch

git在这里需要做的是复制提交
G
和
H
的效果，即
git cherry pick
commit
G
，然后使用提交
H
再次执行。但要做到这一点，git必须首先在内部（使用“分离头”模式）切换到提交
L
：

如果合并不顺利，
HEAD
仍保留在commit
L
（因为commit
G'
还不存在）。因此，是的，
HEAD
是他们开发部门的负责人，至少现在是这样

一旦
G
的副本存在，
HEAD
移动到
G'
，git尝试以相同的方式从
H
复制更改（diff
G
vs
H
，然后diff
F
vs
G'
，并合并结果）：

现在，您重新设置了基础，
HEAD
再次成为您所期望的。但是在重基过程中，
HEAD
要么是它们的分支提示（commit
L
），要么是复制并附加到分支提示之后的新提交之一；而
--ours
表示在
L
末尾生长的分支，而
--theres
表示从（
G
或
H
上面）复制的提交

（这基本上是git公开了它如何做事情的原始机制，这在git中发生得相当多。）
Definitions
在本节中，我们将看到我们被要求回答的缺陷：

谁是校长

HEAD：当前提交您的回购协议。大多数情况下，HEAD指向分支中的最新提交，但情况并非如此。
HEAD
实际上只是指“我的回购协议目前指向的是什么”

如果提交
头
引用的不是任何分支的顶端，则称为“
分离头”

是发展部的负责人吗

在进行合并或重新基础时，
头立即传递到指向已创建或重构的提交，因此将指向开发分支

在
gitbash
中，我们可以看到
HEAD
的情况，其中列出了提交：

# Normal commit list
git log
# List of commit in a single line
git log --oneline 
# All commits graphically-linear (Recommended as alias)
git log --all --graph --decorate --oneline

实践
在本节中，我们将看到“用户如何执行某些操作”

当用户继续执行以下操作时：

# Command to change from the branch to the current one to experimentalbranch
git checkout experimentalbranch
# Command that traverses the typical workflow to synchronize its local repository with the main branch of the central repository (remoterepo)
git fetch remoterepo
# git fetch origin
# git fetch origin branch:branch
# With the command git rebase, you can take all the changes confirmed in one branch (remoterepo), and reapply them over another developmentbranch
git rebase remoterepo/developmentbranch

这时，我遇到了冲突。但是，我对这些更改都不熟悉（我正在对数周的更改进行重定，因为它们没有立即合并我的更改）。而且，这是我第一次做重基。我更习惯于合并

分支机构的联合有两种方式：


git合并

git rebase


注:

对于示例，我们将
              G - H           <-- your-branch
            /
... - E - F                   G'   <-- HEAD
            \               /
              I - J - K - L   <-- origin/their-branch

              G - H           <-- your-branch
            /
... - E - F                   G' - H'   <-- HEAD
            \               /
              I - J - K - L   <-- origin/their-branch

              G - H
            /
... - E - F                   G' - H'   <-- HEAD=your-branch
            \               /
              I - J - K - L   <-- origin/their-branch

# Normal commit list
git log
# List of commit in a single line
git log --oneline 
# All commits graphically-linear (Recommended as alias)
git log --all --graph --decorate --oneline

# Command to change from the branch to the current one to experimentalbranch
git checkout experimentalbranch
# Command that traverses the typical workflow to synchronize its local repository with the main branch of the central repository (remoterepo)
git fetch remoterepo
# git fetch origin
# git fetch origin branch:branch
# With the command git rebase, you can take all the changes confirmed in one branch (remoterepo), and reapply them over another developmentbranch
git rebase remoterepo/developmentbranch

* a122f6d (HEAD -> remoterepo) Commit END
* 9667bfb Commit MASTER
| * b9bcaf0 (origin/experimentalbranch, experimentalbranch) Commit 3
| * 110b2fb Commit 2
| * e597c60 Commit 1
|/
* 0e834f4 (origin/remoterepo) First commit

git checkout remoterepo
git merge experimentalbranch

*   003e576 (HEAD -> remoterepo) Merge branch 'experimentalbranch' in remoterepo
|\
| * b9bcaf0 (origin/experimentalbranch, experimentalbranch) Commit 3
| * 110b2fb Commit 2
| * e597c60 Commit 1
* | a122f6d Commit END
* | 9667bfb Commit MASTER
|/
* 0e834f4 (origin/remoterepo) First commit

git checkout remoterepo
git rebase experimentalbranch


* f8a74be (HEAD -> remoterepo) Commit END
* 4293e9d Commit MASTER
* b9bcaf0 (origin/experimentalbranch, experimentalbranch) Commit 3
* 110b2fb Commit 2
* e597c60 Commit 1
* 0e834f4 (origin/remoterepo) First commit