我有一个远程分支,我们称之为FIN-985_the_original
。我有我的本地分支,称为FIN-985_v2
。 FIN-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
欢迎大家使用任何技巧来使我困惑。
欢呼
答案 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.