如何将远程分支的提交写入本地分支?

时间:2019-04-16 16:50:49

标签: git

我有一个远程分支,我们称之为FIN-985_the_original。我有我的本地分支,称为FIN-985_v2FIN-985_v2是master的分支。

我做了两个命令,我很困惑,因为一个命令清楚地告诉了我我想要的东西

第一个是下面的一个

git rebase --onto FIN-985_the_original FIN-985_v2

这将FIN-985_the_original的内容放入FIN-985_v2,问题是似乎将FIN-985_the original的内容替换为FIN-985_v2,清除了对{{ 1}}。

第二部分似乎给了我我想要的东西,但这有点违背了我的逻辑

FIN-985_v2

我期望重新设置将在FIN-985_v2上完成,而是在git checkout FIN-985_the_original git rebase FIN-985_v2 上完成。从我的命令中,我知道这是因为在FIN-985_the_original上结帐是有意义的,但是当我读过this

时,这使我的逻辑错了

欢迎大家使用任何技巧来使我困惑。

欢呼

1 个答案:

答案 0 :(得分:2)

Basic rebase (your second case)

I'll start with your second case, since that's the easier one to explain.

git checkout A
git rebase B

asks Git to take any commits in A that are not in B, and move them to the end of B.

Sample scenario:

-- 0 (master)
    \
     1 -- 2 -- 3 (B)
      \
       4 -- 5 (A)

If, while A is checked out, I do git rebase B, I pluck commits 4 and 5 (they're on A but not on B) and move them to the end of B:

-- 0 (master)
    \
     1 -- 2 -- 3 (B)
                \
                 4' -- 5' (A)

So now A will have all the commits of B followed by the commits of A.

In your case, the commits of the_original should now be after those of v2, and the_original should be a branch of v2, although I'm not sure that's what you're saying happened.

Using --onto

When you use --onto, things get weird. I'll start with a checkout again because the branch that is currently checked out still is the one being moved:

git checkout A
git rebase --onto C B

asks Git to take the commits that are on A but not on B and move them, same as without --onto. But now, we gave the rebase a destination: put them at the end of C.

Let's add C to my initial scenario:

     6 (C)
    /
-- 0 (master)
    \
     1 -- 2 -- 3 (B)
      \
       4 -- 5 (A)

Since I'm on A, we're still going to move 4 and 5: they're on A but not on B; but we'll place them on C, i.e., after 6:

       6 (C)
      / \
     /   4' -- 5' (A)
    /
-- 0 (master)
    \
     1 -- 2 -- 3 (B)

So in your case, what should have happened depends on what was checked out before the rebase: the commits in the branch that was checked out that were not in v2 should have gotten moved to the end of the_original.

I find I rarely want --onto, and frankly I find it confusing enough that I would probably cherry pick the commits around instead of using git rebase --onto...

Pedantic notes

Following the convention at https://git-scm.com/docs/git-rebase, I'm using ' to mark the moved commits, since 4' and 5' are new commits reproducing 4 and 5, not 4 and 5 themselves.

I'm taking a linguistic shortcut when I say "moved": commits are not technically moved, they are re-applied, thus creating new commits that look more or less the same as the originals.