Question

As we consider moving from SVN to git at work, a coworker has raised the concern that a malicious or accident-prone developer could use git rebase to delete remote history from our shared repo.

Edit: As pointed out in the answers, entire branches could also be deleted from the remote repo with git push origin :branch-name.

Is this a realistic problem? If so, what approach can we take to prevent it?

Answer 1

I tend to agree with your coworker that there is a problem here because:

• no matter how well you trust your committers, there is always a possibility of human error
• more onerous review processes (e.g. Gerrit) are not always appropriate
• restoring from backups can be slow and a PITA

Have you considered the receive.denyNonFastForwards and receive.denyDeletes config parameters? AFAICT these are available in Git 1.6 onwards.

From Pro Git:

If you rebase commits that you’ve already pushed and then try to push
again, or otherwise try to push a commit to a remote branch that
doesn’t contain the commit that the remote branch currently points to,
you’ll be denied. This is generally good policy; but in the case of
the rebase, you may determine that you know what you’re doing and can
force-update the remote branch with a -f flag to your push command.

To disable the ability to force-update remote branches to
non-fast-forward references, set receive.denyNonFastForwards

The other way you can do this is via server-side receive hooks, which I’ll cover in a bit. That approach lets you do more complex things like deny non-fast-forwards to a certain subset of users.

As the author mentions, this rule can also be enforced via a receive hook (which is described later in Pro Git).

These techniques should protect against accidental (or malicious) lost history in your shared repo.