在执行 git rebase 时，在解决冲突时，我经常难以弄清楚“本地”和“远程”发生了什么。有时我的印象是他们从一个提交到下一个提交交换了立场。

这可能(肯定)是因为我还没有正确理解。

rebase 时，谁是“本地”，谁是“远程”？

(我使用 P4Merge 来解决冲突)

最佳答案

TL;DR;

总结(如 Benubird comments )，当:

git checkout A
git rebase   B    # rebase A on top of B

• local是B ( rebase 到)，
• remote是A

和:

git checkout A
git merge    B    # merge B into A

• local是A ( merge 到)，
• remote是B

rebase 开关 ours (rebase 开始前的当前分支)和 theirs (您要在其上进行 rebase 的分支)。

kutschkem指出，在 GUI mergetool 上下文中:

• local references the partially rebased commits:“ours”(上游分支)
• remote 是指传入的更改:“theirs ” - rebase 之前的当前分支。

请参阅本答案最后部分的插图。

rebase 时反转

混淆可能与 inversion of ours and theirs during a rebase 有关.
(相关摘录)

git rebase man page :

Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch.

因此，当发生 merge 冲突时:

• 报告为“ours”的一方' 是到目前为止重新设置的系列，从 <upstream> 开始,
• 和' theirs ' 是工作分支。 换句话说，双方交换了。

反转说明

关于 merge

x--x--x--x--x(*) <- current branch B ('*'=HEAD)
    \
     \
      \--y--y--y <- other branch to merge

，我们不更改当前分支“B”，所以我们拥有的仍然是我们正在处理的内容(并且我们从另一个分支 merge )

x--x--x--x--x---------o(*)  MERGE, still on branch B
    \       ^        /
     \     ours     /
      \            /
       --y--y--y--/  
               ^
              their

关于 rebase :

但是在 rebase 上，我们换边了，因为 rebase 做的第一件事就是检查上游分支! (重播当前的提交)

x--x--x--x--x(*) <- current branch B
    \
     \
      \--y--y--y <- upstream branch

A git rebase upstream 会先变HEAD B到上游分支HEAD (因此与之前的“当前”工作分支相比，“我们的”和“他们的”的切换。)

x--x--x--x--x <- former "current" branch, new "theirs"
    \
     \
      \--y--y--y(*) <- upstream branch with B reset on it,  
                       new "ours", to replay x's on it

，然后 rebase 将在新的“我们的”B 分支上重放“他们的”提交:

x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
    \
     \
      \--y--y--y--x'--x'--x'(*) <-  branch B with HEAD updated ("ours")
               ^
               |
        upstream branch

注:"upstream" notion是从中读取数据或向其添加/创建新数据的引用数据集(所有存储库或分支，可以是本地分支)。

' local ' 和 ' remote ' 与 ' mine ' 和 ' theirs '

Pandawood添加 the comments :

For me, the question still remains, which is "local" and who is "remote" (since the terms "ours" and "theirs" are not used when rebasing in git, referring to them just seems to make an answer more confusing).

GUI merge 工具

kutschkem添加并正确地添加:

When resolving conflicts, git will say something like:

local: modified file and remote: modified file. 

I am quite sure the question aims at the definition of local and remote at this point. At that point, it seems to me from my experience that:

• local references the partially rebased commits:“ours”(上游分支)
• remote 是指传入的更改:“theirs ” - rebase 之前的当前分支。

git mergetool确实提到了“本地”和“远程”:

Merging:
f.txt

Normal merge conflict for 'f.txt':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (kdiff3):

例如，KDiff3会 display the merge resolution like so :

和meld会 display it too :

VimDiff 相同, which displays :

Invoke Vimdiff as a mergetool with git mergetool -t gvimdiff. Recent versions of Git invoke Vimdiff with the following window layout:

+--------------------------------+
| LOCAL  |     BASE     | REMOTE |
+--------------------------------+
|             MERGED             |
+--------------------------------+

• LOCAL:
  A temporary file containing the contents of the file on the current branch.
• BASE:
  A temporary file containing the common base for the merge.
• REMOTE:
  A temporary file containing the contents of the file to be merged.
• MERGED:
  The file containing the conflict markers.

Git has performed as much automatic conflict resolution as possible and the state of this file is a combination of both LOCAL and REMOTE with conflict markers surrounding anything that Git could not resolve itself.
The mergetool should write the result of the resolution to this file.

关于git rebase，跟踪 'local' 和 'remote'，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3051461/