Well, you could use git pull --rebase
after merging, which does just that:
-r
--rebase
Rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the
upstream branch and the upstream branch was rebased since last
fetched, the rebase uses that information to avoid rebasing non-local
changes.
See pull.rebase, branch.<name>.rebase
and branch.autosetuprebase
in git-config
(1) if you want to make git pull always use --rebase
instead of merging.
Note
This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history
already. Do not use this option unless you have read git-rebase
(1)
carefully.
So in summary:
git branch -b feature
...
git checkout master
git merge feature # By the way, merge's --no-ff might interest you
git pull --rebase # rebases feature onto the new-fetched head if necessary
Just one note: The result of this is slightly different from your way if you made changes to master
as well, since git pull --rebase
rebases all your changes since the last pull/push
onto the pulled HEAD
, while you way would cause the pulled changes and your master
changes to be merged and then feature
be rebased upon that. This is mostly irrelevant (and personally I prefer not having unnecessary pull
-induced merges in my history) but you should be aware of it nonetheless...
In pictures, before:
/-O origin/master
C--A--B master
\--F--G feature
After your way:
/-O-----\
C--A--B--C*-----(FG) (origin/)master - fast-forward merge (unless --no-ff)
\-F-G-/ feature (rebased!)
git pull --rebase
way:
/-O
C--A--B--M* => C--O--A--B--M* (origin/)master
\-F-G-/ feature (not rebased!)
If instead you want the end result to be
C--O--A--B--F--G
use
git branch -b feature
...
git checkout master
git rebase feature
git pull --rebase
Also note how much fun you can have with git-rebase -i
;)