假设我有一个名为 的功能分支,它与它所基于的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. 所以:
origindevelopment分支并将其放入FETCH_HEADgit 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)。