Best Practices

Safe force-push protocol

When history rewrite is necessary, use explicit communication, freeze windows, and `--force-with-lease` to reduce overwrite risk.

Who This Is For
  • Individuals or teams who want more predictable Git habits
  • Maintainers setting collaboration expectations
Prerequisites
  • At least one real collaboration loop
  • Basic command familiarity without a stable routine yet
Common Risks
  • Treating guidance as absolute law without context
  • Memorizing process without understanding team boundaries

Force-push should be governed, not improvised.

Minimal protocol

  1. restrict allowed branches
  2. announce temporary push freeze
  3. default to --force-with-lease
  4. share post-push recovery guidance
Safe Force-push ProtocolSafe force-push is not about never using it, but using it under strict preconditions.
Mandatory Preconditions
Confirm no one based on current branchCreate backupUse --force-with-lease
Safe Outcome
Does not overwrite others' workRecoverableTeam can sync
--force-with-lease is the safe version of force-push; it checks whether remote matches expectations.

Recommended sequence

git fetch origin
git log --oneline --graph --decorate -20
git push --force-with-lease origin <branch>

Why lease matters

--force-with-lease prevents overwriting remote commits you have not seen.

Avoid force-push on shared mainline whenever possible

The collaboration recovery cost is often much higher than the history-cleanliness benefit.

Good follow-up reads

  1. shared history boundaries
  2. assess force-push impact
  3. review and safe push