Final answer:
Rebasing commits that exist outside of your repo, especially those pushed to a shared repository, should be avoided due to the potential of causing confusion and disrupting others' work. If necessary, it should be done with clear team communication and understanding of the new history.
Step-by-step explanation:
When considering whether you should rebase commits that exist outside of your repo, it's vital to understand the implications of git rebase in the workflow. Rebasing is a process that rewrites the history of commits, changing the base of your branch to a new starting point, and may lead to a cleaner, more linear project history. However, it comes with cautionary advice, especially for commits that are already pushed to a shared repository.
Firstly, rebasing is recommended for local changes that haven't been shared with others. Here, it's safe to reorganize, squash, or edit commits as they are not affecting anyone else's work. But once commits are pushed and other collaborators are potentially basing their work on them, rebasing can cause significant confusion and problems - making it difficult for others to synchronize their work with the repository. Git best practices advise against rebasing commits that are public.
If it's necessary to rebase public commits for a project's benefit, clear communication with your team is crucial. This includes alerting them about the rebase and ensuring everyone understands the updated history. There are certain strategies, like feature flags or branch by abstraction, where rebasing public commits might be managed more safely and effectively.