A closer look at git rebase

Jason McCreary on February 21, 2017

Most of the comments to my recent articles on 3 Git commands I use every day and When to make a Git commit have mentioned using git rebase. So, ... [Read Full]
markdown guide

Just remember to always git branch backup before you rebase. Then, after the rebase, you can git diff backup to make sure it went well. If something does go awry, you can just git reset --hard backup and start over.


There's no need to create a backup branch. You can do git diff HEAD@{N}~range and git reset --hard HEAD@{N}. Also see git reflog


I agree. But from my experience, people just learning how to rebase really don't want to know anything about git reflog.
The branch method is simpler for beginners.


You can also use git commit --fixup <hash> to prepare a fixup (or squash using --squash). They will be added on top of your branch so you still have to do a rebase using git rebase -i --autosquash to do the fixup or squash. I use this a lot to quickly fix PR review comments or mistakes I made along the way.


git commit --amend --no-edit

is also useful in such cases, which simply adds your changes to previous commit,

 tells git to leave previous commit message

Yup, but that only goes for the last commit whereas a fixup can blend into any commit after a rebase.

Really neat, I didn't understand initially what it is


git reflog works, but finding the original pre-rebase ref in the mass of reflog output that occurs during a rebase disaster can be difficult, especially for beginners.

I find it way easier to just create a backup branch, giving you an easily, visible "last good" ref you can quickly reset to. After all - this is git, branches are cheap!


In the stale branch example, using the video editing metaphor, do the dates of commits on the base and branch influence how the branch merge is done? Do newer base commits get applied after older branch commits?


No, the commit dates do not influence a rebase. The base branch commits are fast forwarded, then the stale branch commits are replayed.

Techically a replayed commit creates a new commit. So it has a new SHA and time stamp, and everything else is the same.


I agree that it is a much cleaner approach than merging feature branches into master (and master back into the feature branch to get changes from other branches and developers) and as well that squashing and rebasing helps to keep the history of master clean, e. g. by squashing work unit and WIP commits into a single or few feature commits on master. I found this post via How I Git, so my question might relate to that post as well.

But I have one caveat with this workflow:

How do I rebase my feature branch on top of master to get rid of it's stale status when it is remote tracked on GitHub or GitLab? And there are mainly three reasons to remote track a feature branch and regularly push it:

  • Having a backup of the code in case something happens my the local working copy or machine it is on.
  • Working on the same branch on different computers, e. g. office and home office or workstation and notebook.
  • More than one developer is working on a branch, maybe first the backend developer does all the business logic and then the frontend developer takes over to implement the UI.

Try --onto as well, it's pretty neat. It allows you to rebase on a changed base branch (e.g. when the base has rebased itself).


Thanks a lot, Jason. This is my guide, moreover man pages.

code of conduct - report abuse