In Git, what happens when you run git rebase -i HEAD~3?

## What the command actually means `git rebase -i <base>` says: take every commit reachable from `HEAD` but not from `<base>`, let me script what happens to them, then re-apply them one at a time on top of `<base>`. The `-i` (`--interactive`) part only adds the scripting step; the replay itself is ordinary rebase. The range is **exclusive** at the base end. `HEAD~3` names the commit three back from the tip, so the todo list contains the **three commits after it** — the base commit is untouched. `git rebase -i <sha>` starts just after that sha. To include the very first commit of the repository you need `git rebase -i --root`, because the root commit has no parent to use as a base. ## The todo list Git writes a plain text file (`.git/rebase-merge/git-rebase-todo`) and opens it in the editor named by `GIT_SEQUENCE_EDITOR`, then `sequence.editor`, then your normal `core.editor`. It looks like: pick 9f2a1c3 add parser skeleton pick 4b7e0aa fix typo in parser pick c11d902 add parser tests Two things surprise people. First, the order is **oldest at the top** — the file reads like a script that runs downward, not like `git log`, which shows newest first. Second, the lines are **instructions, not a report**: whatever the file says when you save is what Git does. The commonly used verbs, each with a one-letter alias: - `pick` (`p`) — apply the commit unchanged. - `reword` (`r`) — apply it, then open an editor for its message only. - `edit` (`e`) — apply it, then **stop** with the commit already made so you can amend it, add files, or split it. - `squash` (`s`) — combine into the previous line's commit and open an editor with both messages. - `fixup` (`f`) — combine into the previous line's commit and discard this one's message. - `drop` (`d`) — discard the commit. Deleting the line entirely does the same thing. - `exec` (`x`) — not a commit at all; run a shell command at this point in the replay. - `break` (`b`) — stop here with no commit to edit, so you can look around. With `--rebase-merges` the todo can also contain `label`, `reset` and `merge` lines that rebuild a branch topology, and recent Git adds `update-ref` lines that carry other branch tips along. ## What Git does when you save Git checks out the base commit in a detached HEAD state and works through the todo list top to bottom, applying each commit's *change* rather than moving the commit object. Because a commit's SHA is a hash of its content **including its parent and its committer timestamp**, every replayed commit is a brand-new object with a new SHA — even the ones you left as `pick`. Only when the whole list finishes does Git move the branch ref to the new tip. If a step conflicts, Git stops and you resolve and run `git rebase --continue` (or `--skip` / `--abort`) — the general replay-and-conflict machinery is the same for interactive and non-interactive rebase. If you realise mid-rebase that the plan itself was wrong, `git rebase --edit-todo` reopens the remaining list. ## Practical notes - Deleting **all** lines and saving aborts the rebase instead of deleting all the commits — a deliberate safety valve. Lines starting with `#` are comments. - `squash` and `fixup` combine into the line **above**, so the first line can never be one of them; Git rejects the todo if it is. - The pre-rebase commits are not destroyed the moment the rebase runs — they remain reachable through the reflog until it expires, which is what makes a bad rebase recoverable. - Because every commit is rewritten, a branch you already pushed will diverge from its remote and need a force push. Rewriting history that other people have already pulled is the well-known hazard here. - Interactive rebase is for **your own unpublished work**: cleaning up a five-commit branch into a reviewable story before you open it for review.