One moment it was there, holding weeks of precise work. The next, a single git reset had rewritten history and erased it from plain view. It wasn’t sabotage. It wasn’t a rookie mistake. It was the absence of guardrails—no ad hoc access control to stop a dangerous command from running in the wrong context.
Git is powerful because it gives you total control. It’s dangerous for the same reason. Without intentional permissions, enforcement by commit, branch, or even by command scope, you leave the door open for unreviewed force pushes, rewrites, and resets that can undo entire projects. And when these happen in a shared repository, recovery takes time, coordination, and sometimes luck.
Ad hoc access control is about precision. It’s the ability to define who can run what, where, and when. Not just repo-level permissions, but granular policies that apply to destructive commands like git reset --hard, git push --force, and git rebase on protected sequences. When done right, this control lives where the actions happen, intercepting unsafe operations before they touch vital history.
For teams, the challenge isn’t knowing these risks exist—it’s enforcing standards without slowing down development. Native Git permissions and popular hosting tools often stop at branch protection, but branch protection isn’t enough if other commands can quietly bypass it. That’s where ad hoc rules come in—rules that adapt to how your team actually works and allow overrides only under strict conditions.