Rebasing is really useful for creating a clean git history. It technically means changing the original base commit of a branch, but for this post, I want to talk about it in practical terms. If you want the technical details, there are plenty of resources available to you. First, let’s quickly answer some questions. And actually, I’ll do just that, with actual speaking and showing you!
More details are included in writing below. This post is dedicated to Aleksa Sarai who was the first to ever show me, with care, how to perform a rebase.
When might I want to rebase?
Generally, when you are working on a branch and want to clean up your git history, it’s easy to rebase with master.
What are the general steps?
While this isn’t a copy paste and go example, it will walk you through general steps. We generally start with checkout of a new branch from an updated master:
# checkout master
git checkout master
# make sure your upstream master is up to date
git pull origin master
# now checkout a new branch
git checkout -b add/cool-feature
And then we make an awesome change! And we commit it.
# make some changes here, and then commit
git commit -a -s -m "This is my awesome change"
Then we maybe push, and open up a pull request, and are told to make more changes. Our commits get sloppy.
git push origin add/cool-feature
# opens pull request, request for changes
# each of the below is associated with some mistake/more changes
git commit -a -s -m 'making this other change'
git commit -a -s -m 'oops'
git commit -a -s -m 'oops'
git commit -a -s -m 'whyyyyyy'
Then our git history is a mess! So we do an interactive rebase against master.
git rebase -i master
And then change all of the crappy commits to “fixup” to squash and disregard the squashed commit messages. And we push to the branch with force!
git push origin add/cool-feature --force
That’s it! Happy rebasing, folks.
Suggested Citation:
Sochat, Vanessa. "Rebasing in Practical Terms." @vsoch (blog), 08 Oct 2019, https://vsoch.github.io/2019/rebasing/ (accessed 18 Nov 24).