In this lesson, you will learn why rewriting pushed commits can disrupt your team's workflow and how to identify when modifying shared history is safe versus destructive.
The Golden Rule of Rebasing
Up until now, you have used interactive rebase to clean up your local work. This is powerful because your local commits belong only to you. However, once you git push a branch to a shared repository, that history is no longer yours alone—it is the "shared truth" that your teammates are basing their own work upon.
If you perform an interactive rebase (like squashing or reordering) on a branch that others have already pulled, you are essentially deleting reality and replacing it with a new one. When your teammates try to git pull, Git will see a divergence. Because the commit hashes have changed, they will encounter complex merge conflicts or, worse, duplicate commits when their local branch tries to integrate your "new" history with the "old" one they already have.
When is it Appropriate?
Rewriting shared history should be a rare exception, not a daily habit. It is generally only acceptable if:
- The branch is private to you: Even if pushed to GitHub, if you are the only person working on that specific feature branch and your team is aware you are cleaning it up, it is safe.
- Security concerns: You accidentally pushed sensitive information (like an API key). In this extreme case, you must rewrite history to remove the secret, and you must communicate clearly to your team that they need to reset their local branches to match the new upstream state.
The Risk
If you force-push (git push --force-with-lease) after rewriting history, you are telling the remote server to discard the previous commits. If a colleague has based their work on one of those discarded commits, their local history becomes broken. Always use --force-with-lease instead of a plain --force to ensure you don't accidentally overwrite work that has been pushed by someone else in the meantime.
Key Takeaway: Never rewrite or rebase commits that other developers have already pulled into their local environments unless you have explicit team consensus to perform a disruptive history correction.