Git rebasing vs merging
When I switched to git for the first time I had a very hard time understanding what rebasing did to a point where I totally avoided it. I had been doing all my work on private and public repositories by going to master and merging to my feature branch or to a team member’s branch. I was happy with this way of working until I started on my new job a few months ago and they had a rebase based workflow. It goes something like this:
1
2
3
4
5
6
cd repo
git pull --rebase
// Do some work and add stage it
git commit -m 'Some message'
git pull --rebase
git push origin master
In this little example I am working in my local master branch, but if I wanted I could create a feature branch and rebase it to master as needed. The most obvious benefit about this workflow is a very clean history. Lets look at a simple example of a merge based history: