Mastering ‘git’ with ‘git rebase’
IntroductionRecently, I started a new job. I sat down, checked out some repos, and cracked on with some work. When I was ready to commit my first changes, I typed
git logto see how my new colleagues like to format their commits… No merge commits. A handful of devs all working on one branch simultaneously? What kind of elegant version control choreography had to be involved? I knew something was up…
The answer? One command:
What does ‘git rebase’ actually do?
If we imagine the scenario below:
- Starting on
git checkout -b blue-branchcreates the new branch
- Commit two sets of changes with git commit
- Then, a teammate pushes a couple of commits to
grey-branchwhile your changes are still in review or you haven’t had time to merge.
- We switch back to
grey-branchand pull the changes our teammate added.
At this point, I was used to using git merge where I would solve any conflicts and create a merge commit, making the tree look like this:
However, instead of using
git merge , this is where
git rebase comes in. If I am
blue-branch in figure 3 and I use
git rebase grey-branch, magic happens:
Isn’t that so amazing? My commits have now been ‘rebased’ on top of the commits
git push blue-branch:grey-branchI get this beauty:
So satisfying… All the changes with their relevant commit info but discarding branch history and those (now) pointless merge commits!
I hope you enjoyed reading this blog post! Sign up to my newsletter here: