In Git, how do you delete a remote branch, and what does git push origin :feature mean?

## The two spellings ``` git push origin --delete feature git push origin :feature ``` The first is explicit and hard to typo dangerously. The second is the refspec form, and understanding it teaches something about how push works in general. ## Why the colon form deletes Every push is driven by refspecs shaped `<src>:<dst>`: take the local revision `src` and update the remote ref `dst` to it. `git push origin main:main` moves the remote's `main` to your `main`. Now drop the source: `git push origin :feature` says "update the remote ref `feature` to *nothing*", and updating a ref to nothing is deletion. Nothing special-cases the syntax; it falls out of the refspec model. The same works for tags: `git push origin :refs/tags/v1.0` deletes a remote tag, and the destination is worth fully qualifying there so Git does not have to guess between a branch and a tag of the same name. ## What actually gets removed Only the ref on the remote. Specifically: - **Deleted:** `refs/heads/feature` on the remote, and — because your own push updated it — `refs/remotes/origin/feature` in your clone. - **Untouched:** your local branch `refs/heads/feature` and every commit on it; the commit objects on the remote, which merely become unreferenced there and are removed later by that repository's garbage collection, if ever; and every *other* clone's `refs/remotes/origin/feature`, which stays until its owner prunes. That last point is the source of the perennial "I deleted it, why can my colleague still see it?" confusion. Remote-tracking refs are per-clone caches and are only removed by pruning: `git fetch --prune`, `fetch.prune = true`, or `git remote prune origin`. ## When the remote refuses A deletion is a ref update like any other and can be rejected by the receiving repository: - `receive.denyDeletes = true` makes the receiving side refuse every branch deletion. - `receive.denyNonFastForwards` covers rewinds rather than deletions, but appears in the same family of receiver-side guards. - A `pre-receive` or `update` hook can reject the deletion of specific refs by name and print its own message. A refused deletion looks like any other rejected push: the branch remains and Git prints a rejected line with a reason. ## Recovering a deletion Because the commits usually still exist somewhere, deletions are often recoverable. If you still have the branch locally, just push it again. If not, and someone else still has a remote-tracking ref or a local copy, they can push it back under the same name. On the receiving repository itself the reflog for the ref may retain the previous value for a time, though whether you can reach that depends on your access to the machine, which is a separate matter from Git's mechanics. ## Order of operations that avoids surprises A safe habit for cleaning up a finished branch: 1. Confirm the work is integrated: `git log --oneline main..feature` should be empty, or use `git branch --merged main`. 2. Delete the remote branch: `git push origin --delete feature`. 3. Delete the local branch with `git branch -d feature`, which refuses if unmerged commits remain. 4. Tell teammates to `git fetch --prune`, or set `fetch.prune = true` so it happens for them automatically. ## What interviewers listen for The short answer is one command, so the substance is in the follow-through: that the colon form is the refspec model rather than a magic incantation, that the local branch survives, that other clones stay stale until they prune, and that the remote may legitimately refuse. Candidates who answer only with `--delete` and stop there usually have not thought about the refspec at all.