git rebase basic usage - Time & Space Complexity
When using git rebase, it's helpful to know how the time it takes grows as the number of commits increases.
We want to understand how the work done by rebase changes when there are more commits to process.
Analyze the time complexity of the following git rebase command.
git checkout feature-branch
# Switch to the feature branch
git rebase main
# Replay feature commits on top of main branch
This code moves the feature branch commits to start after the latest commit on main.
Look for repeated work done during the rebase process.
- Primary operation: Applying each commit from the feature branch one by one onto the main branch.
- How many times: Once for each commit in the feature branch that is not in main.
As the number of commits to rebase increases, the work grows proportionally.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 commits | About 10 apply steps |
| 100 commits | About 100 apply steps |
| 1000 commits | About 1000 apply steps |
Pattern observation: The time grows linearly with the number of commits to rebase.
Time Complexity: O(n)
This means the time to complete the rebase grows directly with the number of commits being replayed.
[X] Wrong: "Rebasing is instant no matter how many commits there are."
[OK] Correct: Each commit must be applied one after another, so more commits mean more work and more time.
Understanding how git commands scale helps you explain your workflow choices clearly and shows you know what happens behind the scenes.
"What if we changed to an interactive rebase that skips some commits? How would the time complexity change?"