Improving a git rebase workflow

user_90457 0
Viewed 2004

I'm currently working a very simple git workflow using feature branches and rebasing on to master before pushing. 

git checkout -b feature
.. make some commits
git checkout master
git pull

If there are no changes from the pull:

git merge feature
git push

If there are changes:

git checkout feature
git rebase master
git checkout master
git merge feature
git push

While has been great to learn how git works but it's getting a little tedious to type all the time and I suspect there's some faster ways to achieve what I'm doing but can't find them.

git
3 Answers

Your shortest amount of steps had a total of 6 steps (no changes case):

git checkout -b feature
.. make some commits
git checkout master
git pull
git merge feature
git push

This technique should work in both cases (6 steps as well):

git checkout -b feature
.. make some commits
git fetch
git rebase origin/master
git checkout master
git merge feature
user_16461060

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 ;)

user_3219730
Related