假设我有一个名为 的功能分支,它与它所基于的FeatureA
(remote) 不同步。development
通常我会通过调用(在自然地git rebase development
同步我的本地开发之后)来重新设置我的分支。origin/development
今天,我做了不同的事情,而是git pull --rebase origin development
从我的功能分支调用。现在,有什么区别?
假设我有一个名为 的功能分支,它与它所基于的FeatureA
(remote) 不同步。development
通常我会通过调用(在自然地git rebase development
同步我的本地开发之后)来重新设置我的分支。origin/development
今天,我做了不同的事情,而是git pull --rebase origin development
从我的功能分支调用。现在,有什么区别?
git pull --rebase origin development
是这些命令的快捷方式:
git fetch origin development
git rebase origin/development
也就是说,获取origin/development
并在其之上重新设置当前分支。
更新
正如@torek指出的那样:
是的,除了 fetch 的两个参数版本不会更新 git 1.8.3 或更早版本中的 origin/development。(rebase 结果是一样的,但是 origin/development 不动。)
短版:如果变基顺利,它工作正常。如果没有,它仍然可以正常工作,只是在图形查看器中可能会有点混乱。
与往常一样,git pull
基本上git fetch
后面是 ... 好吧,在这种情况下,git rebase
而不是git merge
. 所以:
origin
development
分支并将其放入FETCH_HEAD
git merge <commit-ID-from-FETCH_HEAD>
,git rebase
与该 ID 一起使用因此,假设您的本地树中的提交图如下所示(我们假设您git fetch
在某个时间点运行 a 并更新origin/development
了他们的提交E
和F
):
C - D <-- FeatureA
/
A - B <-- development
\
E - F <-- origin/development
而且,让我们进一步假设 on origin
,现在他们的分支上还有一个名为development
. fetch
-from-origin 步骤将把它捡起来并指出这FETCH_HEAD
一点,所以让我们把它画成 node G
:
C - D <-- FeatureA
/
A - B <-- development
\
E - F <-- origin/development
\
G <-- FETCH_HEAD
(如果您的 git 足够新,1.8.4 或更高版本,origin/development
此时也将更新,指向 node G
。如果不是,则development
存储在您的 git 中的本地副本origin/development
落后。这对rebase,它只会改变你在git log --graph
视图或图形提交树查看器中查看结果的方式。)
现在rebase
将以通常的方法复制您的FeatureA
提交以进行变基,并FeatureA
指向副本,放弃原始提交。我们将调用重新定位的C'
和D'
:
C - D [abandoned]
/
A - B <-- development
\
E - F <-- origin/development
\
G <-- FETCH_HEAD
\
C' - D' <-- FeatureA
如果你git fetch
在这一点上运行一个普通的,或者如果你有足够新的 git,那么它origin/development
已经移动了;如果我们去掉“废弃”的部分并简化绘图,它会变成:
A - B <-- development
\
E - F - G <-- origin/development
\
C' - D' <-- FeatureA
如果您将本地分支标签快进合并development
到 match origin/development
,则绘制起来会更简单(将扭结从 B 下拉到 E 并将两者development
和放在origin/development
指向 的箭头的右侧G
)。