Reordering commits in Git - Commands & Configuration

Introduction

Sometimes you want to change the order of your recent work steps in Git to make your history cleaner or fix mistakes. Reordering commits lets you rearrange these steps before sharing your work with others.

When you want to group related changes together before pushing to a shared repository

When you accidentally committed changes in the wrong order and want to fix it

When preparing a pull request and want a logical sequence of commits

When cleaning up your commit history to make it easier for others to review

When you want to squash or reorder commits to simplify the project history

Commands

Shows the last 5 commits in short form so you can see their order and decide how to reorder them.

Terminal

git log --oneline -5

Expected Output

a1b2c3d Fix typo in README

b2c3d4e Add user login feature

c3d4e5f Update styles for homepage

d4e5f6a Improve error handling

e5f6a7b Initial commit

→

--oneline - Shows each commit in one line for easy reading

→

-5 - Limits output to last 5 commits

Starts an interactive rebase for the last 4 commits so you can reorder them. This opens a text editor with the commits listed.

Terminal

git rebase -i HEAD~4

Expected Output

Successfully rebased and updated refs/heads/main.

→

-i - Interactive mode to edit commit order and messages

→

HEAD~4 - Specifies the last 4 commits to include in the rebase

Checks the new order of commits after reordering to confirm the changes.

Terminal

git log --oneline -5

Expected Output

c3d4e5f Update styles for homepage

b2c3d4e Add user login feature

a1b2c3d Fix typo in README

d4e5f6a Improve error handling

e5f6a7b Initial commit

→

--oneline - Shows commits in one line

→

-5 - Limits output to last 5 commits

Key Concept

If you remember nothing else from this pattern, remember: interactive rebase lets you safely reorder recent commits before sharing your work.

Common Mistakes

Running 'git rebase -i' with a number larger than the number of commits available

Git will show an error because it cannot find that many commits to reorder.

Check the number of commits with 'git log --oneline' and use a correct count with 'git rebase -i HEAD~N'.

Editing the rebase todo list incorrectly, such as deleting lines or using wrong commands

This can cause the rebase to fail or produce unexpected commit history.

Only reorder lines by moving them up or down, or use supported commands like 'pick', 'reword', 'squash'. Save and exit properly.

Trying to reorder commits that have already been pushed to a shared repository

Reordering published commits rewrites history and can cause conflicts for others.

Only reorder local commits that have not been pushed, or coordinate with your team before rewriting shared history.

Summary

Use 'git log --oneline -N' to view recent commits and decide which to reorder.

Run 'git rebase -i HEAD~N' to start interactive rebase for the last N commits.

Rearrange commits by moving lines in the editor, then save to apply the new order.

Verify the new commit order with 'git log --oneline -N'.

Practice

1. What is the main purpose of using git rebase -i when working with commits?

easy

A. To create a new branch from the current commit

B. To reorder, edit, or squash commits interactively

C. To merge two branches automatically

D. To delete the entire commit history

Solution

1. Step 1: Understand the function of git rebase -i

   This command opens an interactive editor allowing you to reorder, edit, or squash commits.

2. Step 2: Compare with other options

   Creating branches, merging, or deleting history are not the main purposes of this command.

3. Final Answer:

   To reorder, edit, or squash commits interactively -> Option B

4. Quick Check:

   Interactive rebase = reorder commits [OK]

Hint: Use interactive rebase to reorder commits easily [OK]

Common Mistakes:

• Confusing rebase with branch creation
• Thinking rebase deletes history
• Mixing rebase with merge commands

2. Which of the following is the correct command to start an interactive rebase for the last 3 commits?

easy

A. git rebase -i HEAD~3

B. git rebase -i HEAD^3

C. git rebase -i HEAD~

D. git rebase -i HEAD^^3

Solution

1. Step 1: Recall the syntax for interactive rebase

   The correct syntax uses HEAD~N to specify the last N commits, so HEAD~3 means last 3 commits.

2. Step 2: Check other options for syntax errors

   HEAD^3 and HEAD^^3 are invalid for this purpose; HEAD~ is incomplete.

3. Final Answer:

   git rebase -i HEAD~3 -> Option A

4. Quick Check:

   Use HEAD~N for last N commits [OK]

Hint: Use HEAD~N to specify last N commits in rebase [OK]

Common Mistakes:

• Using caret (^) incorrectly for commit range
• Omitting the number after ~
• Confusing HEAD~ with HEAD^

3. Given the following interactive rebase todo list:

pick a1b2c3 Commit A
pick d4e5f6 Commit B
pick 789abc Commit C

If you change it to:

pick d4e5f6 Commit B
pick a1b2c3 Commit A
pick 789abc Commit C

What will be the order of commits after the rebase?

medium

A. Commit B, Commit A, Commit C

B. Commit A, Commit B, Commit C

C. Commit C, Commit B, Commit A

D. Commit A, Commit C, Commit B

Solution

1. Step 1: Understand the todo list order

   The interactive rebase applies commits in the order listed. Changing the order changes commit history order.

2. Step 2: Apply the new order

   New order is Commit B, then Commit A, then Commit C.

3. Final Answer:

   Commit B, Commit A, Commit C -> Option A

4. Quick Check:

   Rebase applies commits in listed order [OK]

Hint: Order commits in todo list to reorder history [OK]

Common Mistakes:

• Assuming original order stays after rebase
• Confusing commit hashes with order
• Ignoring the todo list sequence

4. You ran git rebase -i HEAD~3 and changed the order of commits, but Git shows a conflict error. What is the best way to fix this?

medium

A. Force push the branch without resolving conflicts

B. Abort the rebase with git rebase --abort and try again

C. Delete the .git folder and start over

D. Manually resolve conflicts, then run git rebase --continue

Solution

1. Step 1: Understand rebase conflict handling

   When conflicts occur during rebase, you must manually fix them in files.

2. Step 2: Continue rebase after resolving conflicts

   After fixing conflicts, run git rebase --continue to proceed.

3. Final Answer:

   Manually resolve conflicts, then run git rebase --continue -> Option D

4. Quick Check:

   Fix conflicts + git rebase --continue [OK]

Hint: Fix conflicts, then continue rebase with git rebase --continue [OK]

Common Mistakes:

• Ignoring conflicts and force pushing
• Aborting rebase without trying to fix
• Deleting .git folder which loses repo data

5. You want to reorder the last 4 commits to put the oldest commit last without changing their content. Which sequence of commands correctly achieves this?

hard

A. Run git reset --hard HEAD~4 then cherry-pick commits in new order

B. Run git merge --reorder HEAD~4 to reorder commits automatically

C. Run git rebase -i HEAD~4, then move the first commit line to the bottom in the editor

D. Run git rebase -i HEAD~3 and swap the last two commits

Solution

1. Step 1: Use interactive rebase on last 4 commits

   Running git rebase -i HEAD~4 opens the last 4 commits for editing order.

2. Step 2: Move the oldest commit line to the bottom

   In the editor, reorder lines so the oldest commit is last, preserving content.

3. Final Answer:

   Run git rebase -i HEAD~4, then move the first commit line to the bottom in the editor -> Option C

4. Quick Check:

   Interactive rebase + reorder lines = reorder commits [OK]

Hint: Use interactive rebase and reorder lines to change commit order [OK]

Common Mistakes:

• Using reset which loses commit history
• Trying non-existent git merge --reorder command
• Using wrong commit range in rebase