Safe force-push protocol

What you will learn

• Understand the core purpose of Safe force-push protocol
• Master the basic usage and common options of Safe force-push protocol
• When history rewrite is necessary, use explicit communication, freeze windows, and --force-with-lease to reduce overwrite risk.
• Understand key concepts: Minimal protocol
• Know when to use this feature and when to avoid it

Force-push should be governed, not improvised.

Start with a problem

Your team has developed some Git habits over time, but you're not sure if they are optimal — or you've just been through an incident caused by a Git mistake and want to avoid repeating it.

Minimal protocol

1. restrict allowed branches
2. announce temporary push freeze
3. default to --force-with-lease
4. share post-push recovery guidance

Mandatory Preconditions

Confirm no one based on current branchCreate backupUse --force-with-lease

→force-push protocol

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

Try it yourself

1. Practice the safe-force-push-protocol command in a test repository and observe state changes before and after
2. Experiment with different options and compare the output differences
3. Simulate a real scenario where you would need to use this, and walk through the full process

Further reading

Keep going on the same topic:

• Safe Cherry-picks
• Security best practices with Git
• Shared History Boundaries