Clean up historyAlways fixable

Reorder commits in your branch

How do I change the order of commits in Git?

Short answer

Run git rebase -i and move the lines in the editor — Git replays them in whatever order you leave them. Conflicts happen when the commits touch the same code, in which case reordering may not be possible without editing.

quick fix
git rebase -i HEAD~4
# move the lines into the order you want, save, close

Reorder the last four commits by rearranging lines in the editor

Does this match your situation?

  • A bug fix should come before the feature that depends on it.
  • You want the refactor commit first so the review reads sensibly.
  • A commit needs to move earlier so you can cherry-pick just that part.

Step-by-step fix

  1. Start an interactive rebase covering the commits

    Reach back far enough to include everything you want to reorder. The list appears oldest-first, which is the opposite of git log.

    step 1
    git log --oneline -5
git rebase -i HEAD~4

    The editor lists commits OLDEST at the top. Moving a line up moves that commit earlier in history.

  2. Rearrange the lines

    Cut and paste whole lines into the order you want, leave every action as pick, then save and close. Git replays them top to bottom.

    step 2
    # before:                        # after:
pick a1b2c3d Add feature       pick f4e5d6c Fix null check
pick f4e5d6c Fix null check    pick a1b2c3d Add feature
pick 9a8b7c6 Update tests      pick 9a8b7c6 Update tests

  3. Resolve conflicts if the commits overlap

    Two commits touching the same lines can't always be swapped cleanly. Resolve as you would any conflict and continue — or abort if it turns out not to be worth it.

    step 3
    # fix the conflicted files, then:
git add .
git rebase --continue

# not worth it?
git rebase --abort

  4. Check the result and push

    Every reordered commit has a new hash, so the branch no longer fast-forwards and needs a lease-protected force push.

    step 4
    git log --oneline -5
git push --force-with-lease

    Only on branches you own. Never reorder commits others have pulled.

Why this works

Rebase doesn't move commits — it replays each one as a fresh commit on a new base, in the order you list them. Because a commit records its parent by hash, changing the order necessarily changes every hash from that point forward. Conflicts arise when a later commit assumed the changes of an earlier one that is now behind it; the diff simply no longer applies to the code it finds. That's also why reordering unrelated commits is effortless and reordering interdependent ones is painful.

How to stop it happening again

  • Commit in logical order as you work rather than fixing it afterwards.
  • Use git commit --fixup so related fixes attach to their target automatically.
  • Keep commits small and independent - they reorder cleanly.

Commands used in this guide

git rebase -i

Reorder, squash, split, reword or drop your recent commits.

git rebase

Replay your commits on top of another branch to produce a straight, linear history.

git reflog

The undo history for everything - the single most important recovery command.

git push

Upload your commits to the remote repository.

Still stuck?

Search the full command reference and every other rescue guide — there are 56 of them, covering everything from detached HEAD to force-push disasters.

Browse all guides →

Frequently asked questions

How do I reorder commits in Git?

git rebase -i HEAD~n, then rearrange the lines in the editor and save. Git replays the commits in the new order. Remember the list is oldest-first, the reverse of git log.

Why do I get conflicts when reordering?

Because a commit you moved earlier now applies to code that doesn't yet contain the changes it expected. If two commits touch the same lines, their order isn't freely interchangeable and you'll have to resolve the difference by hand.

Can I undo a reorder that went wrong?

Yes. git reset --hard ORIG_HEAD immediately afterwards, or find the pre-rebase commit in git reflog and reset to it. The original commits stay in the object database until garbage collection.

Related rescue guides

Always fixable

How do I combine multiple commits into a single commit?

git rebase -i HEAD~n opens an editor where you mark commits as squash or fixup to fold them into the one above. For a quick all-in-one collapse, git reset --soft HEAD~n followed by a fresh commit achieves the same result with no editor at all.

Read the fix →Always fixable

How do I remove a single commit without losing the ones after it?

Mark it drop in git rebase -i and Git replays everything except that commit. On a shared branch, git revert is the safe alternative — it neutralises the change without rewriting anyone's history.

Read the fix →Always fixable

How do I break a large commit into multiple commits?

Mark the commit as edit in git rebase -i, then run git reset HEAD~ to turn it back into unstaged changes. Stage the pieces one at a time with git add -p, commit each, and finish with git rebase --continue.

Read the fix →Usually recoverable

My rebase went wrong and my commits are gone — how do I get them back?

The pre-rebase commits are still in the object database. git reflog shows the position from before the rebase started, and ORIG_HEAD is a shortcut to it — git reset --hard ORIG_HEAD usually restores everything in one command.

Read the fix →
← All Git Rescue guides