I don't know what you did, or think you did, but origin/orgs_phase_2
is a remote-tracking branch. Its only purpose is to indicate where the branch reference called orgs_phase_2
pointed to in the remote repo called origin
the last time you communicated with the latter. The only way such a reference can move is via a fetch or a push. In particular, you can't rebase a remote-tracking branch.
Besides, the Pro Git book is correct. You have got the git-rebase
syntax backwards. Git's rebase
works as advertised in that book,
git rebase [basebranch] [topicbranch]
checks out the topic branch [...] for you and replays it onto the base branch [...]
and in the git-rebase
man page,
Assume the following history exists and the current branch is "topic":
A---B---C topic
/
D---E---F---G master
From this point, the result of either of the following commands:
git rebase master
git rebase master topic
would be:
A'--B'--C' topic
/
D---E---F---G master
To fix ideas, here is a baby example that you can reproduce at home:
#!/bin/bash
# set things up
cd ~/Desktop
mkdir test
cd test
git init
# write an initial shopping list
printf "4 pears\n" > shopping.txt
printf "3 lemons\n" >> shopping.txt
printf "1 stalk of celery\n" >> shopping.txt
printf "4 bananas\n" >> shopping.txt
# make a first commit on master
git add shopping.txt
git commit -m "add shopping list"
# modify the shopping list and make a second commit on master
sed -i '' 's/4 pears/4 apples/' shopping.txt
git add shopping.txt
git commit -m "replace pears by apples"
# create and check out a new branch called "kidscominghome"
git checkout -b kidscominghome
# make two more commits on kidscominghome
printf "16 pots of yoghurt\n" >> shopping.txt
git add shopping.txt
git commit -m "add yoghurt"
printf "beer\n" >> shopping.txt
git add shopping.txt
git commit -m "add beer"
# check out master, modify the file, and make one more commit
git checkout master
sed -i '' 's/stalk of celery/cauliflower/' shopping.txt
git add shopping.txt
git commit -m "replace celery by cauliflower"
At this stage, the output of
git log --graph --decorate --oneline --all
should be
* 5a0e340 (HEAD, master) replace celery by cauliflower
| * d3d22d0 (kidscominghome) add beer
| * edd730d add yoghurt
|/
* 7dc55b7 replace pears by apples
* 7079948 add shopping list
Here is a nicer-looking graph showing the same history:

Now, if you run
git rebase master kidscominghome
and then run the same git log
command, you should see
* 2acf37d (HEAD, kidscominghome) add beer
* dfac4a8 add yoghurt
* 5a0e340 (master) replace celery by cauliflower
* 7dc55b7 replace pears by apples
* 7079948 add shopping list
Again, here is a nicer-looking graph showing the same history:

As advertised, the kidscominghome
branch has been checked out, and the commits that were only reachable from kidcominghome
have been replayed on top of master
; not the other way around!