Reorder Commits Example

What Will We Learn?

Why, When and How to Reorder Git Commits. Each Tip and Warning provided here are gold standard, Don’t skip!

Why Reorder Commits?

You reorder commits mainly to make your project history cleaner, more logical, and easier to review.

For example, your history might be:

A — B — C — D

But you realize the logical order should be:

A — C — B — D

This is why you reorder commits:

Improve readability: Related changes appear together.
Make code review easier: Each commit tells a clear, focused story.
Fix dependencies: A commit that depends on another should come afterward.
Clean up history: You can arrange commits before merging a feature branch.
Make future debugging easier: Tools like git bisect work better with meaningful, self-contained commits.

In Git, this is commonly done with interactive rebase:

git rebase -i HEAD~4

Git then lets you change the order of the commits (among other things).

Warning

Reordering commits rewrites history, so be careful if those commits have already been pushed and shared with others.

How to Reorder Commits?

You can reorder commits by first starting interactive rebasing and reordering pick commands in todo list.

Tip

First git status to check status of your project and git stash if any uncommitted changes! This will safely save your unfinished work as rebasing alters history.

Commits Needed To Be Reorderd

Suppose, your commit history is:

    gitGraph
    commit id: "A"
    commit id: "B"
    commit id: "C"
    commit id: "D"

git log --oneline output:

d30ca88 (HEAD -> master) D
0ce4336 C
31fbd66 B
7552ecc A

Start Reordering

For some good reason, you need to reorder last three commits. What you can do now is start interactive rebase:

git rebase -i HEAD~3

Git will open todo list like:

.git/rebase-merge/git-rebase-todo

pick 31fbd66 B
pick 0ce4336 C
pick d30ca88 D

This is already in the order which is for some reason you don’t want. Now change the order which you aim to achieve. Assuming you want A — D — C — B:

.git/rebase-merge/git-rebase-todo

pick d30ca88 D
pick 0ce4336 C
pick 31fbd66 B

After edit and saving file…

Important

Merge Conflicts during reordering is common and almost inevitable in complex real world projects. Deal gracefully. For more, see resolving conflicts.

Handle Merge Conflicts

After saving, often you will encounter merge conflict — consider yourself lucky otherwise.

When you encounter conflict, Resolve them and continue the rebase for each conflict till rebase process is not completed:

git add .
git rebase --continue

Reordering Completed

Finally after a long sign, you will see success:

[detached HEAD 003909d] B'
 1 file changed, 1 insertion(+), 1 deletion(-)
Successfully rebased and updated refs/heads/master.

Your commit history is reorderd and altered, git log --oneline output:

003909d (HEAD -> master) B'
db2c590 C'
e05c5eb D'
7552ecc A

If you compare this will the starting commit history, you will see only the last line:

7552ecc A

is unchanged. Every other has been reordered in your desired order and the commit hash for all three has been changed. If you are following recent chapters, you already know the reason. Anyway:

When you rebase, Git creates new commit objects. So the commit hash above for B — C — D changes. The B' — C' — D' is just there to denote the change.

Before and After Comparision

Before:

    gitGraph
    commit id: "A"
    commit id: "B"
    commit id: "C"
    commit id: "D"

After:

    gitGraph
    commit id: "A"
    commit id: "D'"
    commit id: "C'"
    commit id: "B'"

What’s After Reordering

Generally — Nothing just Verifying with git log is often enough. But if you remember, a tip was given to stash uncommitted changes before starting rebasing. If you had uncommitted, unfinished tasks and had sincerly git stash, then you can pop your recent stash:

git stash pop