Project how a Git repository's size will grow over time based on commit trends.
Assuming linear growth, a repository's size trend can be extrapolated forward. Formula: growth_per_month = (current_size − initial_size) / months, then projected_size = current_size + growth_per_month × projection_months. This is a simple linear model — actual growth is often stepped (large binary commits, LFS migrations) rather than smooth, so treat projections as a planning floor, not a guarantee.
Growth rate
growth_per_month = (current_size - initial_size) / elapsed_months
Projected size
projected_size = current_size + growth_per_month × projection_months
Only roughly — repository growth is often bursty (a single commit adding a large dataset, or a history-rewrite reducing it sharply). Use this as a capacity-planning baseline and revisit it periodically with fresh measurements.
Periodic snapshots of `du -sh .git` (or your Git host's repo size API) at consistent intervals give you the initial/current size pair to compute a real growth rate.
Move large binaries to Git LFS, add generated artifacts to .gitignore before they're ever committed, and periodically run history-rewriting cleanups for accidentally committed large files.
Yes — early-stage projects often grow faster as scaffolding and dependencies are added; mature projects tend to plateau unless a major asset migration or history rewrite changes the trend.