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.
git reflogandgit reflog --date=humancan 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.
https://render.com/blog/git-organized-a-better-git-flow
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.