Rebasing is one of the features you probably want to have, if you plan to work on a neat git-based project. A clean history is a gift to your future self and to every teammate who reads your pull requests later: instead of a tangle of “fix typo” commits, you get a linear, readable story of how the feature actually came together.
🍣 Where to Rebase?
If you know how many commits you made, to rebase you use git rebase with the -i flag to enable interactive rebasing. The HEAD~ corresponds to the number of commits you have done (e.g., HEAD~4 if you have 4 commits to roll back to get to the common ancestor commit).
git rebase -i HEAD~<n>Sometimes, you commit a lot and forget how many commits you’d make. To know the least common ancestor you have with master, you do git merge-base with your branch name as the parameter:
git merge-base <your-branch> masterThe above command will return a git hash which you can use on the git rebase command.
If you already know the git hash, then you can roll back to that specific commit and move all current changes to unstaged. Once the editor pops up, you will choose which commits to retain, squash, and reword:
git rebase -i <git-ref-hash>The interactive editor is where the magic happens: pick keeps a commit, squash folds it into the previous one, and reword lets you write a better message. That is how ten messy commits become three clean ones.
🍣 Merge Latest from Master
If you’ve already rebased your changes and need to get the latest changes from master, all you have to do is rebase onto the latest changes from master.
This command will do that:
git rebase origin/masterIn any case you’ve encountered some conflict, first resolve it, then continue rebasing instead of creating a new merge commit:
git rebase --continueThe rule of thumb: resolve, stage, continue. Git walks through each conflicted commit one at a time, so the problem stays small instead of becoming one giant merge mess.
🍣 Overwriting Remote Repo Changes
Once all is done, overwrite your remote repo’s latest changes if you’ve pushed it. This will do a force push ignoring the current ref on the remote repo:
git push -fA word of caution: force pushing rewrites history that others may have already pulled, so only do this on branches that are yours alone, or coordinate with the team first. On a shared branch, prefer git push --force-with-lease, which refuses to overwrite changes you have not seen.
🍣 Did Something Wrong? In Need of Rollback
Did something go wrong with merging conflicts? Don’t worry, you can still see your previous changes using the command git reflog, short for reference log.
You can check out the reference hash then re-merge your changes:
git reflogThe reflog is Git’s safety net: it records every move of your HEAD, so even after a botched rebase, the old commits are still findable. It is the reason rebase is not actually scary, because nothing is truly lost until the reflog entries expire.
🧠 Final Thoughts
Rebase is the tool that turns messy history into a story, and with reflog as the escape hatch, the fear evaporates. Use interactive rebase to shape your commits, rebase onto master to stay current, and force push with care.
Start small: squash a couple of commits on a personal branch, watch the log turn clean, and the habit will stick. The reference below is a great next step for rebasing within a pull request workflow.