git rebase,跟踪“本地”和“远程”

在做git rebase的时候,在解决冲突的时候,我经常很难弄清楚“local”和“remote”是怎么回事。 我有时会有这样的印象:他们从一个承诺转到另一个承诺。

这可能(绝对),因为我还没有正确理解。

当重组时,谁是“本地”,谁是“偏远”?

(我用P4Merge来解决冲突)

TL; DR;

总结(如Benubird 评论 ),当:

 git checkout A git rebase B # rebase A on top of B 
  • localB (rebase ),
  • remoteA

和:

 git checkout A git merge B # merge B into A 
  • localA (并入),
  • remoteB

rebase切换ours (rebase开始之前的当前分支)和theirs (你想要rebase之上的分支)。


kutschkem指出, 在一个GUI mergetool上下文中

  • 本地引用部分重新发布的提交 :“ ours ”(上游分支)
  • 远程指的是传入的变化 :“ theirs ” – 当前分支之前的变调。

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


倒置时反转

这个混乱可能与ourstheirs在反转时的倒置有关 。
(相关摘录)

git rebase手册页 :

请注意,通过在<upstream>分支之上重播来自工作分支的每个提交,分隔合并工作。

因此,当发生合并冲突时:

  • 报道为“ ours ”的一面是迄今为止重新发布的系列文章,从<upstream>
  • theirs ”是工作分支。 换句话说,双方交换。

反演说明

在合并

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

,我们不改变当前的分支'B',所以我们仍然是我们正在工作(我们从另一个分支合并)

 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 

git rebase upstreamgit rebase upstream会首先将B的HEAD更改为上游分支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 

注意: “上游”概念是从其中读取数据或添加/创build新数据的参考数据集(全部回购或像这里的分支,可以是本地分支)。


local ”和“ remote ”与“ mine ”和“ theirs

Pandawood在评论中补充道:

对于我来说,问题依然存在,那就是“本地化”,谁是“远程化”(因为在重组git时不使用“我们”和“他们的”这个术语,只是提供了一个比较混乱的答案) 。

GUI git mergetool

kutschkem补充说,正确如此:

在解决冲突时,git会说:

 local: modified file and remote: modified file. 

我相当确定这个问题是针对当地和偏远地区的定义。 在这一点上,从我的经验来看,在我看来:

  • 本地引用部分重新发布的提交 :“ ours ”(上游分支)
  • 远程指的是传入的变化 :“ theirs ” – 当前分支之前的变调。

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会显示合并分辨率,如下所示 :

kdiff3

而融合也会显示它 :

梅尔德差异

同样的VimDiff , 它显示 :

用git mergetool -t gvimdiff调用Vimdiff作为mergetool。 最新版本的Git使用以下窗口布局调用Vimdiff:

 +--------------------------------+ | LOCAL | BASE | REMOTE | +--------------------------------+ | MERGED | +--------------------------------+ 
  • LOCAL
    包含当前分支上文件内容的临时文件。
  • BASE
    包含合并的公共基础的临时文件。
  • REMOTE
    包含要合并的文件内容的临时文件。
  • MERGED
    包含冲突标记的文件。

Git已经执行了尽可能多的自动冲突解决scheme,而且这个文件的状态是LOCALREMOTE的组合,它们之间的冲突标记是Git无法自行解决的。
mergetool应该将parsing结果写入这个文件。

底线

git rebase

  • LOCAL =你正在重塑的基地
  • REMOTE =你正在提交的提交

混帐合并

  • LOCAL =你正在合并的原始分支
  • REMOTE =你正在合并的其他分支

换句话说, LOCAL总是原来的,而REMOTE总是那些没有提交的人,因为他们被合并或者重新组合

certificate给我看!

当然。 不要拿我的话! 这是一个简单的实验,你可以做自己看。

首先,确保你已经正确configuration了git mergetool。 (如果你没有,那么你可能不会读这个问题。)然后find一个工作目录。

设置您的存储库:

 md LocalRemoteTest cd LocalRemoteTest 

创build一个初始提交(一个空文件):

 git init notepad file.txt (use the text editor of your choice) (save the file as an empty file) git add -A git commit -m "Initial commit." 

在不是主控的分支上创build一个提交:

 git checkout -b notmaster notepad file.txt (add the text: notmaster) (save and exit) git commit -a -m "Add notmaster text." 

在主分支上创build一个提交:

 git checkout master notepad file.txt (add the text: master) (save and exit) git commit -a -m "Add master text." gitk --all 

此时你的仓库应该是这样的:

有基本提交和两个一个提交分支的仓库

现在进行rebasetesting:

 git checkout notmaster git rebase master (you'll get a conflict message) git mergetool LOCAL: master REMOTE: notmaster 

现在合并testing。 closures您的mergetool而不保存任何更改,然后取消rebase:

 git rebase --abort 

然后:

 git checkout master git merge notmaster git mergetool LOCAL: master REMOTE: notmaster git reset --hard (cancels the merge) 

你的结果应该和上面显示的一样。

我没有完全确定你的问题,但我认为下面的图解决了你的问题。 (Rebase:远程仓库—>工作区)

http://assets.osteele.comhttp://img.dovov.com2008/git-transport.png

来源: 我的Git工作stream程