Git Merge vs Rebase: 10K Commit Performance Test Results

Most Git tutorials skip the part where your rebase takes 40 minutes

I ran a benchmark on a repo with 10,247 commits to see how merge and rebase actually perform at scale. The results weren't what the conventional wisdom suggests.

The common advice is "rebase keeps history clean, merge preserves context." But nobody talks about what happens when you're rebasing 200 commits from a feature branch that diverged weeks ago. Spoiler: your terminal will sit there for a while.

Photo by Myburgh Roux on Pexels

The test setup: building a realistic repo

I generated a repository that mimics a medium-sized project's history:

python
import subprocess
import time
import os

# Create test repo
os.makedirs('git-perf-test', exist_ok=True)
os.chdir('git-perf-test')
subprocess.run(['git', 'init'], check=True)

# Generate main branch commits
for i in range(10000):
    with open('main.txt', 'a') as f:
        f.write(f"Main commit {i}\n")
    subprocess.run(['git', 'add', 'main.txt'], check=True)
    subprocess.run(['git', 'commit', '-m', f'Main {i}'], 

---

*Continue reading the full article on [TildAlice](https://tildalice.io/git-merge-vs-rebase-10k-commit-performance-test/)*