git pull *之后* git rebase? [英] git pull *after* git rebase?

问题描述

我有一个功能分支和一个主分支.

I have a feature branch, and a master branch.

Master分支已经发展，我的意思是使这些更新与Master分支的差异尽可能小.

Master branch has evolved and I mean to have those updates to diverging as little as possible from master branch.

所以我在两个分支git checkout feature/branch中都git pull，最后是git rebase master.

So I git pull in both branches, git checkout feature/branch and finally git rebase master.

现在，在这里我要么希望一切都能顺利运行要么出现冲突，我需要解决，然后再继续进行基础，直到所有主提交都成功地重新应用到功能分支上.

Now here I either expect everything to work smoothly or conflicts showing up that I need to resolve before continuing rebase until all master commits are re-applied successfully on feature branch.

现在我真正发生的事情是我不了解的事情:

Now what really happened in my case is something I do not understand:

$>git rebase master
First, rewinding head to replay your work on top of it...
Applying: myFirstCommitDoneOnTheBranch
Applying: myOtherCommitDoneOnTheBranch
$>git status
On branch feature/branch
Your branch and 'origin/feature/feature' have diverged,
and have 27 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
nothing to commit, working tree clean
$>git pull
*load of conflicts*

现在，据我所知，他在拉动后的冲突负荷很大.我不明白需要拉.从逻辑上讲，它应该在分支时回滚到master，保存在分支上所做的提交，转发到master上的最新提交，然后应用保存的提交.

Now, as much as I can understand he load of conflicts after the pull; I do not understand the need for a pull. Logically, it should rollback to master when it got branched, save the commits made on the branch, forward to latest commit on master and then apply the saved commits.

我不明白Applying消息指的是什么:将提交应用于哪个版本?

I do not understand to what the Applying message refers to: what is applying the commits on which version?

推荐答案

tl; dr 您应先使用git pull和git pull --rebase 更新master和feature 在master顶部重新设置feature. 在您将feature分支重新建立在master之上之后，无需执行 git pull .

tl;dr You should update both master and feature with git pull and git pull --rebase before rebasing feature on top of master. There is no need to do a git pull after you have rebased your feature branch on top of master.

在您当前的工作流程中，git status告诉您的原因:

With your current workflow, the reason why git status is telling you this:

您的分支机构和来源/功能"有所不同， 分别具有27和2个不同的提交.

Your branch and 'origin/feature' have diverged, and have 27 and 2 different commits each, respectively.

是因为您重新设置了基础的feature分支现在具有 25 个新提交，而这些新提交不能从origin/feature到达(因为它们来自master的重新设置)加上 2 提交从origin/feature可到达 但具有不同提交ID的提交.这些提交包含相同的更改(即，它们是等效补丁程序)，但是它们具有不同的SHA-1散列，因为它们基于origin/feature中的不同提交而不是基于您在其中进行重新引用的提交.您的本地存储库.

is because your rebased feature branch now has 25 new commits that aren't reachable from origin/feature (since they came from the rebase on master) plus 2 commits that are reachable from origin/feature but have different commit IDs. Those commits contain the same changes (i.e. they're patch equivalent) but they have different SHA-1 hashes because they are based off of a different commit in origin/feature than the one you rebased them on in your local repository.

这是一个例子.假设这是您在上执行git pull之前 的历史记录:

Here's an example. Let's assume that this is your history before doing git pull on master:

A - B - C (master)
         \
          D - E (feature)

在git pull之后，master获得了提交F:

A - B - C - F (master, origin/master)
         \
          D - E (feature)

此时，您将feature设置在之上，应用 D和E:

At that point, you rebase feature on top of master, which applies D and E:

A - B - C - F (master, origin/master)
             \
              D - E (feature)

同时，远程分支origin/feature仍基于提交C:

In the meantime, the remote branch origin/feature is still based off commit C:

A - B - C - F (master, origin/master)
         \   \
          \   D' - E' (feature)
           \
             D - E (origin/feature)

如果您在feature上执行git status，Git会告诉您feature分支已经从origin/feature与 3 (F，D'，E')和 2 (D，E)提交.

If you do a git status on feature, Git will tell you that your feature branch has diverged from origin/feature with 3 (F, D', E') and 2 (D, E) commits, respectively.

请注意，D'和E'包含与D和E相同的更改，但是具有不同的提交ID，因为它们已经基于F进行了重新构建.

Note that D' and E' contain the same changes as D and E but have different commit IDs because they have been rebased on top of F.

解决方案是在master和feature 上都执行git pull，然后在上重新建立feature上的feature基准.但是，由于您可能已经在feature上提交了尚未提交到origin的提交，因此您需要执行以下操作:

The solution is to do git pull on both master and feature before rebasing feature on master. However, since you may have commits on feature that you haven't yet pushed to origin, you would want to do:

git checkout feature && git pull --rebase

避免在origin/feature和本地feature之间创建合并提交.

to avoid creating a merge commit between origin/feature and your local feature.

根据此评论，我在分散的分支上扩展. git status报告在重新设置基准后feature和origin/feature 偏离的原因是由于重新基准化为feature带来了新的提交，并加上了重写 以前被推送到origin/feature的提交.

In light of this comment, I expanded on the diverging branches. The reason why git status reports that feature and origin/feature diverge after the rebase is due to the fact that rebasing brings in new commits to feature, plus it rewrites the commits that were previously pushed to origin/feature.

考虑拉动后但重新设置前 的情况:

Consider the situation after the pull but before the rebase:

A - B - C - F (master)
         \
          D - E (feature, origin/feature)

此时，feature和origin/feature指向同一提交E-换句话说，它们处于" sync "中.在master顶部重新设置feature后，历史记录将如下所示:

At this point, feature and origin/feature point to the same commit E—in other words, they're in "sync". After rebasing feature on top of master, history will look like this:

A - B - C - F (master)
         \   \
          \   D' - E' (feature)
           \
             D - E (origin/feature)

如您所见，feature和origin/feature有分歧，它们的共同祖先是提交C.这是因为feature现在包含来自master加上D'和E'的新提交F(读作" D素数"和" E素数" >)，它们是在F顶部应用的提交D和E.即使它们包含相同的更改，Git仍认为它们是不同的，因为它们具有不同的提交ID.同时，origin/feature仍引用D和E.

As you can see, feature and origin/feature have diverged, their common ancestor being commit C. This is because feature now contains the new commit F from master plus D' and E' (read as "D prime" and "E prime") which are commits D and E applied on top of F. Even though they contain the same changes, Git considers them to be different because they have different commit IDs. Meanwhile, origin/feature still references D and E.

至此，您已经重写了历史记录:您已经通过重新部署现有提交来修改现有提交，从而有效地创建了新"提交.

At this point, you've rewritten history: you've modified existing commits by virtue of rebasing them, effectively creating "new" ones.

现在，如果要在feature上运行git pull，将发生以下情况:

Now, if you were to run git pull on feature this is what would happen:

A - B - C - F (master)
         \   \
          \   D' - E'- M (feature)
           \         /
             D - E - (origin/feature)

由于git pull执行git fetch + git merge，因此将创建其父为E'和E的合并提交M.

Since git pull does git fetch + git merge, this would result in the creation of the merge commit M, whose parents are E' and E.

如果您改为运行git pull --rebase(即git fetch + git rebase)，则Git会:

If, instead, you ran git pull --rebase (that is, git fetch + git rebase) then Git would:

1. 移动feature提交C(feature和origin/feature的共同祖先)
2. 应用origin/feature
中的D和E
3. 应用F，D'和E'

1. Move feature to commit C (the common ancestor of feature and origin/feature)
2. Apply D and E from origin/feature
3. Apply F, D' and E'

但是，注意到D'和E'包含与D和E相同的更改，Git只会丢弃它们，从而产生如下所示的历史记录:

However, noticing that D' and E' contain the same changes as D and E, Git would just discard them, resulting in a history looking like this:

A - B - C - F (master)
         \   
          D - E - F' (feature)
              ^
             (origin/feature)

请注意，以前从feature可以到达的提交F如何应用到origin/feature的顶部，从而导致F'.此时，git status会告诉您以下内容:

Notice how commit F, previously reachable from feature, got applied on top of origin/feature resulting in F'. At this point, git status would tell you this:

您的分支比起源/功能"要早1次提交.

Your branch is ahead of 'origin/feature' by 1 commit.

该提交当然是F'.

这篇关于git pull *之后* git rebase?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！