In Git, why is amending an already-pushed commit riskier than amending a local one?

## The asymmetry A local amend is a private edit to a private ref. You create a replacement commit, move your branch, and the old object lingers in your reflog. Nobody else can observe any of it, so nothing can go wrong beyond your own recovery, which the reflog covers. A published commit is different in kind, not degree, because copies exist that you cannot reach. Git has no mechanism to recall an object from a clone or to tell a remote "this commit was replaced". The amend only changes what **your** branch points at. ## Consequence 1: your push is rejected Git accepts a push only when the new tip is a descendant of the old one — a fast-forward. After an amend, the remote's tip is the original commit and your tip is a sibling of it: both share the same parent, neither is an ancestor of the other. The push is refused as non-fast-forward. That rejection is a safety feature: it is Git telling you that accepting your update would drop a commit the remote currently has. The only way forward is a force update of the branch, which overwrites the remote ref. That is a deliberate act with its own safety mechanics and flags, covered as its own subject. ## Consequence 2: colleagues reintroduce the old commit Suppose a teammate fetched the original commit `A` and built `B` on top of it. You amend `A` into `A'` and force-update the branch. Their next pull now merges a history containing `A` and `B` with a history containing `A'`. The merge succeeds — Git has no idea `A` and `A'` are meant to be the same change — and the result contains **both**, so the branch carries the same content twice under different SHAs, plus a good chance of conflicts because the two versions touch the same lines. Cleaning that up means someone has to rebase or reset their work onto the new tip, which is a conversation, not a command. ## Consequence 3: stale references SHAs get quoted in places Git does not control: a comment on a ticket, a deployment log, a message in chat, a tag or another branch you created for safety, an annotation in an incident write-up. After the rewrite those SHAs still resolve locally for a while, because the objects are not deleted, but they name a commit no longer on the branch. Anyone following the link sees history that appears to have vanished. ## What makes it acceptable anyway Rewriting published history is not forbidden; it is a coordination cost you should be able to pay. It is routine and low risk when: - The branch is a personal feature branch nobody else builds on. Publishing it is a backup and a review vehicle, not a shared base. - The team has agreed that such branches may be rewritten, so nobody expects their local copy to be a stable base. - You announce it if anyone could plausibly have pulled. It is unacceptable on shared long-lived branches — the mainline, a release branch — because the number of clones that hold the old commit is unbounded and the cleanup cost is paid by everyone. ## How to avoid needing it - Amend before you push, not after. A fixup commit recorded now and collapsed by a rebase just before publishing gives you a clean series without touching anything shared. - When a published commit is wrong, prefer a new commit that corrects it, or a revert. Both are append-only: every clone converges by fast-forward and no coordination is needed. - Reserve rewrites of published history for cases where the content itself must not remain in the history — and even then treat exposed material as compromised regardless, since copies already exist. ## Interview framing A strong answer distinguishes the two situations by *who else holds a copy*, names the non-fast-forward rejection as the mechanism you actually hit, and describes the duplicate-commit failure mode concretely. Saying "just force push" without naming the coordination cost is the weak answer interviewers are listening for.