Let's start from the beginning. Here's a diagram of your original state:
A-B-C (master, origin/master)
D-E-F-G-H-I (next, origin/next)
When you checked out next
and rebased next
onto origin/master
, it created 6 new commits after the two that are already on origin/master
. These new commits have "master commit #2" (C
in my diagram) as their ancestor, not their original ancestor where origin/master
and origin/next
diverged (A
in my diagram), so their hashes will be different. I believe this is why you'll see that next
has 8 different commits from origin/next
: the 2 from origin/master
and the 6 "rehashed" commits that were on origin/next
.
After git checkout next ; git rebase -i origin/master
, you should have this:
A-B-C (master, origin/master)
D'-E'-F'-G'-H'-I' (next)
D-E-F-G-H-I (origin/next)
You can see that next
does have 8 commits that aren't on origin/next
, and origin/next
does have 6 commits that aren't on next
. Granted this is just according to the SHA-1 hashes of the commits. The actual content should match very closely if you git diff origin/next next
-- the diff should just show the changes from B
and C
(as labeled in the diagram).
When you do git pull --rebase
while still on next
, it fetches changes from the source (the remote origin/next
) and rebases the current branch (next
) onto that remote. This causes the changes that were in the next
but not in origin/next
to appear after origin/next
on the new next
branch. It should look like this:
A-B-C (master, origin/master)
D-E-F-G-H-I (origin/next)
B'-C' (next)
If this is what you wanted the history graph to look like, then you've succeeded.
However, I suspect you really wanted things to look like the middle diagram, especially if next
is a feature branch where you're working on the next piece of the project and master
is for stable code and small bug fixes. If so, then you should have done git push
instead of git pull --rebase
to make the remote reflect your version of history instead of the other way around.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…