A git rebase stops on a conflict — what do --continue, --skip, and --abort each do?

## Why a rebase pauses at all Rebase does not compute one combined result the way a merge does. It replays commits individually, applying each commit's change to the state built so far. Any one of those applications can conflict, so a branch of N commits offers up to N separate pauses. This surprises people who expect a rebase to behave like a merge with a single conflict resolution. ## The paused state When a replay conflicts, Git leaves a well-defined state: - Conflicted paths are unmerged in the index, with markers written into the working tree. - HEAD is detached, pointing at the last successfully replayed commit — your branch ref has *not* moved yet. - The remaining todo list and the bookkeeping live in `.git/rebase-merge`, which is why `git status` can tell you which commit of how many you are on. A useful detail: because HEAD is detached and the branch ref still points at the original tip, an abort has an unambiguous place to return to, and the pre-rebase tip is also recorded in `ORIG_HEAD` and the reflog. ## --continue This is the normal exit. Resolve the conflicted files to the content you want, `git add` each one so the path becomes resolved in the index, then `git rebase --continue`. Git creates the commit for the current step from the staged content and proceeds to the next entry in the todo list — where it may conflict again. If you staged nothing and the resolution left no changes at all, Git tells you the commit has become empty and asks you to choose explicitly rather than guessing. A frequent error is running `--continue` while paths are still unmerged; Git refuses, because it will not commit an unresolved index. `git status` is the checklist. ## --skip `git rebase --skip` abandons the commit currently being replayed. It does not skip the *conflict*; it skips the *commit*, so that commit's change is simply absent from the rebased branch. There is a legitimate use: when the change is already present in the new base — a cherry-pick that was landed upstream, a fix applied twice — Git reports the commit as empty and skipping is exactly right. There is also a very common misuse: reaching for `--skip` to make an annoying conflict stop, which silently deletes work. If in doubt, abort and restart rather than skip. ## --abort `git rebase --abort` discards the partial replay and restores the branch to its pre-rebase tip and the working tree with it. Nothing you had committed before the rebase is lost, because the original commits were never modified — the branch ref simply goes back to pointing at them. Aborting is cheap and is the right reflex whenever you have lost track of what you resolved or suspect you resolved a hunk the wrong way round. ## --quit The fourth exit is `git rebase --quit`: it clears the rebase state but leaves HEAD where the replay currently sits, rather than rewinding. It is the tool for "I want to keep what has been replayed so far and stop treating this as a rebase" — rare, sharp, and easy to leave a confusing state behind, so it should be used deliberately. ## Recovering after the fact Once a rebase has completed, `--abort` is no longer available, but recovery is: the branch's previous tip is in the reflog, and resetting to it restores the pre-rebase branch exactly, since the original commits still exist as objects. This makes the whole operation far less frightening than it first appears — the question is never "can I get back?" but "do I know which position to get back to?". ## What a good answer includes State the three exits precisely, and be explicit that `--skip` drops a commit rather than a conflict — that single distinction is what the question is really probing. Adding that each pause is per commit, that the branch ref has not moved during the pause, and that a completed rebase is still recoverable through the reflog, turns a memorised triple into a demonstrated model of the sequencer.