Git Rebase: What Can Go Wrong?

Julia Evans wrote another must-read article (if you’re using Git): git rebase: what can go wrong?

I often use git rebase to clean up the commit history of a branch I want to merge into a main branch or to prepare a feature branch for a pull request. I don’t want to run it unattended – I’m always using the interactive option – but even then, I might get into tight spots where I can only hope the results will turn out to be what I expect them to be. Always have a backup – be it another branch or a copy of the branch you’re working on in a remote repository.


  1. git reflog and git reflog --date=human can be useful. I believe it keeps a 6mo history of where your working directory and HEAD have been. Once stuff is in a commit, git doesn't forget it for quite a while, it can just be tricky to find it again.

    I also tend to push a branch before I do a lot of rebase work so I can always git reset --hard @{u} to get back to what I had before I started work.

    Lastly, if my commit history is too messy to clean up, I'll adopt Annie Sexton's method and just toss the commit history and generate new commits.

    Using this method in conjunction with git add --patch ... (can stage changes a hunk at a time) or a tool like tig/gitui that can stage individual lines at a time can make really readable commit histories.

Add comment