Force push to main branch rewrote shared history — enable branch protection

[HaleTom]

Summary

A force push to the main branch was detected on 2026-06-15. The original commit 97aefc0 was replaced by ab53d06 via git commit --amend followed by a force push. Both commits share the same author date and message ("Update to latest release"), with nearly identical diff stats (+225,419/-2,986 vs +225,420/-2,987), confirming the second is an amended version of the first.

Compare URL: https://github.com/XiaomiMiMo/MiMo-Code/compare/97aefc09964cd51be9de4c905f6a242e1e8e7c57..ab53d0619905496b351e4be37f14b727d58f21a3

Why this is a problem

Force-pushing to a shared branch on a public repository causes concrete, lasting damage:

1. PR reopen invariant breaks. GitHub locks closed PRs when the head SHA is no longer a descendant of the stored head. After a force push, closed PRs become permanently unreopenable — even the repo owner cannot reopen them. (isaacs/github#361)

2. Review comments are orphaned. Inline review comments are anchored to specific diff hunks in the old commit. After a force push replaces that commit, those comments detach from context and become invisible or broken in the PR timeline.

3. Forks and clones diverge. Anyone who cloned or forked the repo before the force push now has a divergent history. A normal git pull will fail or produce duplicate commits, forcing every contributor to manually reset their local branch.

With ~250 open PRs and community contributors, these risks are not hypothetical for this repo.

Suggested fix

GitHub has a built-in setting that prevents force pushes entirely:

1. Go to Settings → Branches → Branch protection rules
2. Add a rule for branch pattern main
3. Enable "Do not allow force pushes"
4. Optionally also enable "Do not allow deletions"

This blocks git push --force and --force-with-lease on the main branch for everyone, eliminating the risk entirely. It's available on all GitHub plans, including free public repos.

If you need to correct a commit

Instead of amending and force-pushing:

• Push a new commit. If the change is substantive, a new commit is the correct approach.
• For commit message fixes, edit the PR title and body on GitHub instead — the commit message in history rarely matters on a main branch.
• For rebase-based workflows, always merge rather than rebase when working on shared branches.

Force pushes are fine on personal feature branches that nobody else tracks. On main — especially on a public repo — they should be prevented by policy.