Interactive rebase (git rebase -i) - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When using interactive rebase in Git, it is important to understand how the time it takes grows as you work with more commits.
We want to know how the number of commits affects the work Git does during rebase.
Analyze the time complexity of the following git interactive rebase command.
git rebase -i HEAD~5
# This opens an editor to reorder, squash, or edit the last 5 commits.
# Git will then replay these commits one by one on top of the base commit.
This command lets you change the last 5 commits by replaying them interactively.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Git replays each commit one by one during the rebase.
- How many times: Once for each commit in the range (here, 5 times).
As the number of commits to rebase increases, Git must replay more commits, so the work grows linearly.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | Replays 10 commits |
| 100 | Replays 100 commits |
| 1000 | Replays 1000 commits |
Pattern observation: Doubling the commits roughly doubles the work Git does during rebase.
Time Complexity: O(n)
This means the time to complete the interactive rebase grows directly with the number of commits you want to change.
[X] Wrong: "Interactive rebase time stays the same no matter how many commits I edit."
[OK] Correct: Each commit must be replayed, so more commits mean more work and longer time.
Understanding how operations scale with input size shows you think about efficiency, a key skill in real-world software work.
"What if we only rebase a single commit instead of many? How would the time complexity change?"
Practice
git rebase -i (interactive rebase)?Solution
Step 1: Understand the purpose of interactive rebase
Interactive rebase allows you to change the order, combine, edit, or remove recent commits.Step 2: Compare with other git commands
Creating branches, deleting history, or pushing commits are different git operations.Final Answer:
To reorder, edit, or combine recent commits before sharing -> Option AQuick Check:
Interactive rebase = reorder/edit commits [OK]
- Confusing rebase with branch creation
- Thinking it deletes all history
- Assuming it pushes commits automatically
Solution
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.Step 2: Check the options
HEAD^3 and HEAD^^3 are invalid for this purpose; HEAD~ alone is incomplete.Final Answer:
git rebase -i HEAD~3 -> Option BQuick Check:
HEAD~3 selects last 3 commits [OK]
- Using HEAD^3 instead of HEAD~3
- Omitting the number after ~
- Using double carets ^^ incorrectly
pick a1b2c3 Commit A pick d4e5f6 Commit B pick 789abc Commit C
If you change it to:
pick d4e5f6 Commit B squash 789abc Commit C pick a1b2c3 Commit A
What will happen after completing the rebase?
Solution
Step 1: Understand 'pick' and 'squash' in rebase
'pick' applies a commit as is; 'squash' combines the commit with the previous one.Step 2: Analyze the new order
Commit B is picked first, Commit C is squashed into B, Commit A is picked last.Final Answer:
Commits B and C will be combined, and Commit A will be last -> Option DQuick Check:
squash merges commits; order changed [OK]
- Thinking squash drops commits
- Assuming order stays same after rebase
- Confusing squash with fixup
git rebase -i HEAD~2 and change the second commit's action from pick to edit. After saving, what should you do next to modify that commit?Solution
Step 1: Understand 'edit' in interactive rebase
When a commit is marked 'edit', rebase pauses to let you change it.Step 2: Modify commit and continue rebase
You make changes, amend the commit withgit commit --amend, then continue withgit rebase --continue.Final Answer:
Make changes, then run git commit --amend and git rebase --continue -> Option AQuick Check:
Edit = amend commit + continue rebase [OK]
- Pushing before finishing rebase
- Aborting instead of continuing
- Resetting commits incorrectly
pick 111aaa Commit 1 pick 222bbb Commit 2 pick 333ccc Commit 3 pick 444ddd Commit 4
Solution
Step 1: Reorder commits to put last commit first
Commit 4 (444ddd) should be first in the list to reorder it first.Step 2: Combine second and third commits
To combine commits 2 and 3, use 'pick' on commit 2 and 'squash' on commit 3 immediately after.Step 3: Verify the todo list
pick 444ddd Commit 4 pick 111aaa Commit 1 pick 222bbb Commit 2 squash 333ccc Commit 3
places commit 4 first, then commit 1, then picks commit 2 and squashes commit 3, matching requirements.Final Answer:
pick 444ddd Commit 4 pick 111aaa Commit 1 pick 222bbb Commit 2 squash 333ccc Commit 3
-> Option CQuick Check:
Reorder + squash =pick 444ddd Commit 4 pick 111aaa Commit 1 pick 222bbb Commit 2 squash 333ccc Commit 3
[OK]
- Squashing commits in wrong order
- Not moving last commit to first position
- Using squash on wrong commits
