Git Rebase,跟踪“本地”和“远程”

Tl;Dr;

总结(如 benubird comments ),when:。

git checkout a
Git钢筋B钢筋A位于B顶部
< /代码> 


localisb(rebaseonto),

remoteisa



和:

git checkout a
Git合并b将b合并为a
< /代码> 


localisa(mergeinto),

remoteisb



a rebase switchesours.(rebase启动前的当前分支)andtheir.(the branch on top of which you want to rebase).




kutschkempoints out that,in a gui mergetool context:。



local references the partly rebased commits:“ours”(the upstream branch))。

remote指的是传入的更改。:“their的更改。”-the current branch before the rebase.



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




重新平衡时反转

混淆可能与inversion ofours.andtheirs.during a rebase.

(相关摘录)


git-rebaseman page:。


< Buff行情>
请注意,Rebase合并的工作方式是重放位于上游<upstream>分支顶部的工作分支中的每个提交。

< /块引用>

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


报告为“ours”的一侧是迄今为止重新调整的系列,从<upstream>,”

“theirs”是工作分支。
换言之,双方交换。





图示反转

合并时

x--x--x--x(*)<-current branch b('*'=head)
\
\
\--Y--Y--Y<—要合并的其他分支
< /代码> 

,我们不更改当前分支“b”,所以我们现在的分支仍然是我们正在处理的(并且我们从另一个分支合并)。

合并,仍在分支B上
\^/
\我们的/
\/
--Y-Y-Y/-
^
他们的
< /代码> 



在钢筋上:

但是,在Rebase上,我们切换侧边,因为Rebase做的第一件事是签出上游分支!(重放当前提交)

x--x--x--x(*)<-当前分支B
\
\
\--Y--Y--Y<—上游分支
< /代码> 

Agit rebase upstreamwill first changeheadof B to the upstream branchhead(因此,将'ours'和'theirs'的开关与之前的“current”working branch进行比较。)


x--x--x--x--x<-former“current”branch,new“their”
\
\
\--Y--Y--Y(*)<—上游分支,其上重置了B,
新的“我们的”,重放X的
< /代码> 

,然后rebase将在新的“our”b分支上重播“their”提交:

x--x..x..x..x<-old“their”commits,now“ghosts”,available through reflogs
\
\
\--Y--Y--Y--X'--X'--X'(*)<-B分支,更新了头(“我们的”)。
^
γ
上游分支
< /代码> 



注:从哪个数据被读取或到哪个新数据被添加/创建的”upstream“concept是数据的参照集(a all repo or,like here,a branch,which can be alocal.>em>branch)。




'local.'and'remote.'vs.mine.'and'theirs.''


pandawoodadds inThe comments:”

< Buff行情>
对我来说,问题仍然存在,这是“本地的”和“远程的”(因为在Git中重新平衡时不使用“我们的”和“他们的”这两个术语,引用它们似乎会使答案更加混乱)。
< /块引用>

图形用户界面Git合并工具

kutschkemadds,and rightly so:。


< Buff行情>
解决冲突时,Git会说:
< /块引用>

local:modified file and remote:modified file.
< /代码> 

< Buff行情>
我很肯定这个问题是针对本地和远程的定义的。从我的经验来看:
< /块引用>


local references the partly rebased commits:“ours”(the upstream branch))。

remote指的是传入的更改。:“their的更改。”-the current branch before the rebase.



git mergetooldoes really associate‘local’and‘remote’:。


合并:
F.TXT

“f.txt”的正常合并冲突:
本地:修改的文件
远程:修改的文件
点击返回开始合并解决工具(kdiff3):
< /代码> 

例如,kdiff3woulddisplay the merge resolution like so.:。




以及meldwuwon.id.au/2010/09/painless-merge-conflict-resolution-in.html”rel=“noreferrer”>display it too.:。




同样适用于显示的

< Buff行情>
使用git mergetool-t gvimdiff将vimdiff作为合并工具调用。Git的最新版本使用以下窗口布局调用VimDiff:
< /块引用>

+-----------------------------------+
|本地基地远程|
+—————————————————————————+
|合并|
+——————————————————————+
< /代码> 

< Buff行情>

local:

包含当前分支上文件内容的临时文件。

base:

包含合并公用基的临时文件。

remote:

包含要合并的文件内容的临时文件。

merged:

包含冲突标记的文件。



Git已经执行了尽可能多的自动冲突解决,并且此文件的状态是local和remotewith conflict markers around anything Git could not resolve self.

mergetool应该将解析结果写入此文件。

< /块引用>
comments):


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



local是B(重新基础)到上面)
remote是A


还有:

git checkout A
git merge    B    # merge B into A



地方的是一(合并)进入之内)
遥远的是乙


A REBASE开关ours(REBASE启动前的当前分支)和theirs(您要在其上重新平衡的分支)。



kutschkem指出,在GUI合并工具上下文中:


局部引用部分重新平衡的提交:我们的“(上游分支机构)
远程是指传入的更改:他们的“—钢筋前的当前分支。


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



重新平衡时反转

混乱可能与inversion of ours and theirs during a rebase.

(相关摘录)

git rebase man page:


请注意,通过在<upstream>分支机构。


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


该方报告为'我们的'是到目前为止重新调整的系列,从<上游& GT;,
和他们的'是工作部门。
换言之,双方交换。




图示反转

关于合并

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做的第一件事就是检查上游分支!(重放当前提交)

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


一git rebase upstream会先换吗HEADB到上游分支头(因此,与之前的“当前”工作分支相比,“我们的”和“他们的”的切换。)

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是一组参考数据(全回购,或者像这里一样,是一个分支,可以是地方的分支)从中读取数据或向其中添加/创建新数据。



’地方的“和”遥远的“VS”mine“和”他们的’

Pandawood加入the comments:


对我来说,问题仍然存在,这是“本地的”和“远程的”(因为在Git中重新平衡时不使用“我们的”和“他们的”这两个术语,引用它们似乎会使答案更加混乱)。


图形用户界面Git合并工具

库茨克姆补充,正确地说:


解决冲突时,Git会说:


local: modified file and remote: modified file. 



我很肯定这个问题是针对本地和远程的定义的。从我的经验来看:



局部引用部分重新平衡的提交:我们的“(上游分支机构)
远程是指传入的更改:他们的“—钢筋前的当前分支。


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:


使用git mergetool-t gvimdiff将vimdiff作为合并工具调用。Git的最新版本使用以下窗口布局调用VimDiff:


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




LOCAL:

包含当前分支上文件内容的临时文件。
BASE:

包含合并公用基的临时文件。
REMOTE:

包含要合并的文件内容的临时文件。
MERGED:

包含冲突标记的文件。


Git已经执行了尽可能多的自动冲突解决,这个文件的状态是两者的组合局部的和远程的在Git自身无法解决的任何问题周围使用冲突标记。

这个mergetool应将分辨率的结果写入此文件。

底线

md本地远程测试
CD本地远程测试
< /代码> 

创建初始提交(使用空文件):。

git init
notepad file.txt(使用您选择的文本编辑器)
(将文件另存为空文件)
Git加-A
git commit-m“初始提交”。
< /代码> 

在非主分支上创建提交:

git checkout-b notmaster
记事本文件.txt
(添加文本:notmaster)
(保存和退出)
git commit-a-m“添加notmaster文本”。
< /代码> 

在主分支上创建提交:

git checkout master
记事本文件.txt
(添加文本:master)
(保存和退出)
git commit-a-m“添加主控文本”。

GITK——所有
< /代码> 

此时,您的存储库应该如下所示:



现在进行钢筋测试:

git checkout notmaster
Git钢筋主控形状
(您将收到一条冲突消息)
吉特混血儿
本地:硕士
远程:NotMaster
< /代码> 

现在是合并测试。关闭合并工具而不保存任何更改,然后取消重新设置:

git-rebase--abort
< /代码> 

 >:

git checkout master
Git合并NotMaster
吉特混血儿
本地:硕士
远程:NotMaster
git reset--硬(取消合并)
< /代码> 

您的结果应与顶部显示的结果相同。

E再基到上面
REMOTE=你在上面的承诺


合并分支


本地=要合并到的原始分支
远程=要合并其提交的另一个分支


换言之,局部的总是原始的,并且远程的总是那些承诺不存在的人,因为他们正在被合并或重新安排在上面

证明!

当然。别相信我的话!这是一个简单的实验,你可以自己去看看。

首先,确保已经正确配置了git mergetool。(如果你没有,你可能也不会读这个问题。)然后找到一个工作目录。

设置存储库:

md LocalRemoteTest
cd LocalRemoteTest


创建初始提交(使用空文件):

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


在非主分支上创建提交:

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


在主分支上创建提交:

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

gitk --all


此时,您的存储库应该如下所示:



现在,对于钢筋测试:

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


现在是合并测试。关闭合并工具而不保存任何更改,然后取消重新设置:

git rebase --abort


然后:

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


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

我没有完全理解您的问题,但我认为下图解决了您的问题。(REBASE:远程存储库--->工作区)

来源: my git工作流

来源: My Git Workflow