A Simple Explanation for git rebase


There are countless manuals, articles, blogs etc on why using git rebase is so awesome. It may just be that I'm a git neophyte, (though I've been using it for over 3 years), but none of these ever plainly explained to me why rebase was beneficial. Explanations such as. take all the changes that were committed on one branch and replay them on another one.



Tags: Blog Running Peninsula 
 
 

Related Links:

Content

Cached Text (at the time of saving)


by: brad robertson
There are countless manuals, articles, blogs etc on why using git rebase is so awesome. It may just be that I'm a git neophyte, (though I've been using it for over 3 years), but none of these ever plainly explained to me why rebase was beneficial. Explanations such as
take all the changes that were committed on one branch and replay them on another one
don't really tell me anything about the tool or why I should use it.
Convoluted explanations paired with some nightmare conflicts due to my misunderstanding of the tool and incorrect usage, have led me to generally avoid rebase altogether.
That is until a new colleague recommended it once again, but gave me a 30 second run-down of an appropriate dev workflow (to be explained) which really hit home.
Here is why (for me) git rebase is awesome:
When you're working on a feature branch, rebasing the main development line into your feature branch will keep all of your feature branch commits at the head of the branch
That's it.
In my mind, somehow, 'replaying history' to me always meant that others' commits would be inter-mingled with mine own based on the date of the commit, but it's in fact the exact opposite. Your feature branch commits remain at the tip
What this means is that at the moment you want to merge back into the mainline, you have all of your commits at the top and you can clean them up in any way you choose by amending, squashing etc to make it a more understandable pull request.
To further that, you can set git up to use rebase when you pull the remote development branch into your local, so that once again your latest local changes (if you have any) are at the tip. How many times have you pulled, created a merge commit, then realized you need to fix something? Well you can't amend anymore because you now have a merge commit at the HEAD. Doing a rebase instead will always allow you to amend since it's your latest change at the HEAD.
So, a quick, simple workflow for feature development:
Create your feature branch (we use git flow) so our feature branches look like feature/my-awesome-feature
Develop as usual
Checkout the main development line and make sure you're up to date by pulling (or fetch/rebase, whatever your preference)
Rebase the dev branch into your feature branch by checking out the feature branch and running git rebase development. Obviously change development to whatever your main line of dev branch is.
Push your changes to your git remote. You will likely have to git push -f since you've now changed the history of this feature branch. Don't let that scare you, that's what you need to do to get this to work.
A Few Caveats:
Never rebase into any shared branches in the system (development, master etc). This would require that everyone else force pull your changes since you've changed history, which isn't useful.
To go along with point #1, rebasing only works for your feature branches that aren't shared amongst your team. So if your feature branch is being worked on by multiple people (which is kind of weird anyway) you can't do this
If you're interested in having git pull always rebase locally, you can use the following git config in your project
git config branch.autosetuprebase always
You can also specify that this only happen for specific branches using:
git config branch.*branch-name*.rebase true
Happy rebasing!