Rebase, undo and rescue: rebase, reset, revert, reflog and stash

What rebase does

Merging keeps both lines of history and joins them with a merge commit. Rebasing does something different: it takes the commits that are only on your branch, temporarily removes them, moves your branch to the tip of the other branch, and then replays your commits one by one on top. The result looks as if you had started your work from the latest main.

# before:  main: A - B - C        feature: A - B - X - Y
git switch feature
git rebase main
# after:   feature: A - B - C - X' - Y'   (X' and Y' are NEW commits)

Interactive rebase: tidy up before you share

While working, you often make commits like "wip", "fix typo" and "really fix it". Before opening a pull request, interactive rebase lets you clean them up. git rebase -i HEAD~4 opens an editor listing the last four commits, oldest first, each with an action word.

pick   1a2b3c4 Add coupon field to checkout
fixup  5d6e7f8 fix typo
squash 9a8b7c6 Validate coupon expiry date
drop   0f1e2d3 Temporary debug logging
reword 4c5d6e7 add tests

If a replayed commit conflicts, Git stops. Fix the files, git add them, and run git rebase --continue. git rebase --abort returns everything to how it was.

The golden rule

Merge or rebase?

Cherry-pick: copy one commit

git cherry-pick <id> applies the changes of one commit onto your current branch as a new commit. It is useful to bring a single bug fix from main into a release branch, without merging everything else.

Undoing: reset versus revert

git reset moves the current branch pointer back to an earlier commit. The three modes differ in what happens to the changes from the commits you step back over.

git reset --soft HEAD~1    # undo the last commit, keep its changes STAGED
git reset --mixed HEAD~1   # (default) undo the commit, keep changes in your files, unstaged
git reset --hard HEAD~1    # undo the commit AND throw away its changes (dangerous)

git revert 5e2c8d1         # make a NEW commit that undoes 5e2c8d1; history is kept

reset rewrites history, so it follows the golden rule: use it only on commits nobody else has. On a shared branch use git revert, which adds a new commit with the opposite changes. Everyone simply pulls it.

reflog: the safety net

Git writes down every place HEAD has pointed to in the reflog (reference log). Even after a reset --hard or a bad rebase, the old commits usually still exist for a while (by default, unreachable entries are kept about 30 days). Find the ID and bring it back.

git reflog
# 7d41c2e HEAD@{0}: reset: moving to HEAD~3
# a19f0b3 HEAD@{1}: commit: Add UPI QR payment option
git branch rescue a19f0b3     # a new branch pointing at the "lost" commit

stash: park unfinished work

git stash push -m "half-done coupon form"   # save changes and clean the working directory
git stash list                               # stash@{0}: On feature: half-done coupon form
git stash apply stash@{0}                    # bring it back (the stash stays in the list)
git stash pop                                # bring back the latest and remove it from the list
git stash push -u -m "with new files"        # -u also stashes untracked files

Common mistakes and how to fix them

• Ran reset --hard and lost work: check git reflog straight away and create a branch at the old commit. Uncommitted changes that were never staged or committed cannot be recovered this way.
• Rebased main and force-pushed: tell the team at once. Restore the old tip from someone's clone or the reflog, and protect main so force pushes are blocked.
• Squash in the first line of the todo list fails, because there is no earlier commit to melt into. The first line must be pick or reword.