Force-Push Safety

## What a push actually does A push asks the remote to move a ref from one commit to another. By default the remote accepts the update only if the new value is a descendant of the old one — a **fast-forward**. That single rule is the reason ordinary collaboration is safe: an update that would make existing commits unreachable is refused, and you are told to fetch and integrate first. `git push --force` (or `-f`) tells the remote to skip that check and set the ref regardless. The commits that used to be at the tip are not deleted immediately — objects survive until they are unreachable *and* pruned — but nothing points at them anymore, so from every user's perspective they are gone, and the server will collect them in time. ## The two failure modes **Losing other people's commits.** You rebase, someone else pushes two commits, you force-push. Your new tip descends from the tip you had before their push, so their commits are simply not in it. The remote now has no ref reaching them. Unless someone still has them locally, they are lost. **Splitting everyone's history.** Rewriting a branch replaces its commits with new ones carrying the same changes but different SHAs. Every clone that already fetched the branch still has the originals. Their next `git pull` sees a remote-tracking ref that no longer descends from their local branch, and the default merge behaviour tries to reconcile the two — producing duplicated commits and conflicts, or quietly reintroducing the commits you removed. This is why a rewritten shared branch usually costs the team more than the rewrite saved. ## Why it is still a normal thing to do Force-pushing is not forbidden; it is the *published and shared* part that matters. Rewriting your own feature branch — squashing fixups, rebasing onto an updated base, amending a message — is routine, and republishing it requires a force. The distinction to state clearly is ownership: a branch only you push is yours to rewrite; a branch other people commit to or build on is not. ## Safer defaults - Use `git push --force-with-lease` instead of `--force`. It refuses the push if the remote branch is not where you last saw it, so a teammate's push turns a silent overwrite into a rejection you must think about. - Fetch and look before rewriting, so you know whether anyone else moved the branch. - Keep long-lived shared branches out of scope entirely; the receiving repository can be configured to reject non-fast-forward updates on them. - If you must rewrite a branch someone else uses, tell them first and tell them how to move their work onto the new tip. ## Recovering when it goes wrong Nothing is instantly unrecoverable. Anyone who had the branch still has the old commits in their object store and in their reflog, and `git reflog` on the machine that force-pushed shows the pre-rewrite tip. Pushing the old tip back restores the ref, after which you integrate deliberately. The window is bounded by garbage collection, so speed matters — a good reason to speak up immediately rather than quietly retry. ## The sentence to say in an interview "A forced push replaces the branch pointer without the fast-forward check, so it can make other people's commits unreachable and it splits the history of every clone that already fetched the branch. I force-push my own branches with `--force-with-lease`, and I do not rewrite branches other people build on."