Reordering commits in Git - Mini Project: Build & Apply

Reordering Commits with Git

📖 Scenario: You are working on a project using Git. You made three commits in a row, but you realize the order of these commits should be changed to make the history clearer.Imagine you wrote three small changes: first a README update, then a bug fix, and finally a new feature. You want to reorder these commits so the bug fix comes first, then the feature, and the README update last.

🎯 Goal: Learn how to reorder commits in Git using interactive rebase.You will create three commits, then reorder them so the commit history shows the bug fix first, the feature second, and the README update last.

📋 What You'll Learn

Create three commits with exact commit messages: 'Update README', 'Fix bug', 'Add feature'

Use a Git interactive rebase to reorder commits

Verify the new commit order by listing commits

💡 Why This Matters

🌍 Real World

Reordering commits helps keep project history clean and understandable, which is important when collaborating with others.

💼 Career

Many software development and DevOps roles require managing Git histories effectively to maintain code quality and collaboration.

1

Create three commits with exact messages

Create three commits in this exact order with these commit messages: Update README, Fix bug, and Add feature. Use git commit -m with these messages exactly.

Git

# Your code here

Hint

Use git commit -m "message" to create commits with exact messages.

2

Start interactive rebase to reorder commits

Start an interactive rebase for the last three commits using git rebase -i HEAD~3.

Git

git init

echo "Initial README" > README.md
git add README.md
git commit -m "Update README"

echo "Bug fix code" > bugfix.txt
git add bugfix.txt
git commit -m "Fix bug"

echo "Feature code" > feature.txt
git add feature.txt
git commit -m "Add feature"

# Start interactive rebase for last 3 commits
# Your code here

Hint

Use git rebase -i HEAD~3 to edit the last three commits.

3

Reorder commits in the interactive editor

In the interactive rebase editor, reorder the commits so the commit with message Fix bug is first, then Add feature, and finally Update README. Save and exit the editor to apply the new order.

Git

git init

echo "Initial README" > README.md
git add README.md
git commit -m "Update README"

echo "Bug fix code" > bugfix.txt
git add bugfix.txt
git commit -m "Fix bug"

echo "Feature code" > feature.txt
git add feature.txt
git commit -m "Add feature"

git rebase -i HEAD~3

# Reorder commits in the editor
# Your code here

Hint

In the editor, move the lines so the commit messages are in the order: Fix bug, Add feature, Update README.

4

Verify the new commit order

Use git log --oneline to display the commit history and verify the commits are now ordered with Fix bug first, Add feature second, and Update README last.

Git

git init

echo "Initial README" > README.md
git add README.md
git commit -m "Update README"

echo "Bug fix code" > bugfix.txt
git add bugfix.txt
git commit -m "Fix bug"

echo "Feature code" > feature.txt
git add feature.txt
git commit -m "Add feature"

git rebase -i HEAD~3

# In the editor, reorder lines to:
# pick  Fix bug
# pick  Add feature
# pick  Update README
# Then save and exit

# Now verify commit order
# Your code here

Hint

Run git log --oneline and check the commit messages appear in the new order.

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