In a Git interactive rebase todo list, how do squash and fixup differ?

## The shared behaviour When `git rebase -i` replays the todo list, both `squash` and `fixup` mean "do not create a commit of your own; add these changes to the commit produced by the previous line". The result is one commit whose tree is the combination of the two, sitting where the earlier one was. You can chain them: three `fixup` lines under one `pick` collapse four commits into one. Because both fold **upward**, neither is legal on the first line of the todo list — Git refuses the list with an error saying the first command cannot squash, since there is nothing before it to squash into. If you want the *first* commit gone into the second, reorder the lines first. ## The difference: the commit message `squash` stops the rebase and opens your editor with a buffer containing both messages, commented with a header explaining that this is a combination of two commits. You delete, merge or rewrite them and save; what you save becomes the message of the combined commit. `fixup` does not stop at all. The folded commit's message is discarded and the earlier commit keeps its message verbatim. That is the whole point: a rebase of ten commits with six `fixup` lines runs to completion with no prompts. Recent Git added two options on the `fixup` line. `fixup -C <commit>` folds the change but takes the **later** commit's message as the message of the result — useful when the follow-up commit is the one that describes the finished change. `fixup -c` does the same but opens the editor so you can adjust it, which makes it behave like `squash` with the messages the other way round. ## Choosing between them A useful rule: does the folded commit's message tell a future reader anything? - "fix typo", "oops", "address review comment", "rerun formatter" — nothing of value. `fixup`. - "also handle the empty-input case", "add the missing index" — that is real information about what the final commit does. `squash`, then write a single message that covers both. A history full of "fix review comment" commits is exactly what reviewers and future archaeologists complain about, and `fixup` is the tool that removes them without you having to hand-write a merged message ten times. ## How this pairs with prepared fixup commits The todo verbs are one half of a workflow. The other half is creating commits that are already marked as belonging to an earlier one, so the todo list can be arranged automatically instead of by hand — that is what `--autosquash` consumes. Even so, the verbs stand on their own: you can always open the todo list and type `fixup` yourself, which is what most people do the first time. ## Things that go wrong - **Squashing into the wrong neighbour.** The verb folds into the line above *in the todo list*, not into the commit that looks related. If you also reorder lines, check what is now above. - **A conflict during a fold.** Folding replays two changes onto the same base; if the later one depended on intermediate state you dropped or moved, you will get a conflict and have to resolve it before continuing. - **Squashing published commits.** Folding rewrites every commit from that point on, so a pushed branch will diverge from its remote and need a force push. That is fine for a personal feature branch and a problem for a shared one. - **Expecting fixup to delete the change.** It discards the *message*, never the diff. Dropping a change entirely is `drop`. - **Blank squash message.** If you empty the editor buffer during a `squash`, the rebase stops with an error rather than silently committing an empty message. ## Verifying the outcome After the rebase, `git log --oneline` should show the folded commits gone, and `git diff` between the old tip (from the reflog) and the new tip should be empty when you only folded commits — the content is meant to be identical, only the packaging changed. That empty diff is the sanity check worth mentioning in an interview, because it proves the cleanup did not silently drop work.