1

I am interested to know if its possible to disable force pushing for certain main branches that all developers use(example: dev, master). Developers can do force pushing on their private branches.

Kiran
  • 56,921
  • 15
  • 176
  • 161
  • Assuming you have access to the hosting server, it should be possible to set up a hook on the server side to detect and reject force pushes (they do exactly that here at work). I don't know the exact details though, hence why I'm not answering. – Chris Hayes Feb 17 '15 at 19:00
  • @ChrisHayes: thanks for the quick answer. Just to be clear...you mean the place where you work they have this setup like this?...if yes, I am happy to know that its possible to do! – Kiran Feb 17 '15 at 19:01
  • Yup, that's what I mean. You get a nasty message explaining to you why you shouldn't do force pushes. :) – Chris Hayes Feb 17 '15 at 19:02
  • 1
    There are a number of packages that support this (Gitosis, Gitolite, etc.). – Andrew C Feb 17 '15 at 19:03
  • @AndrewC please, not Gitosis... let it go. It's been deader than dead for the past 5 years at least. Gitolite is the name of the game when it comes to managing ACL. And it is still alive and kicking: http://stackoverflow.com/a/10888358/6309 – VonC Feb 17 '15 at 20:18
  • I'd say, if a developer routinely (= more than once a year) force pushes to a git repository, he has absolutely no understanding of `git` and shouldn't have push rights in the first place. A sane developer will *never* force push anything without prior intensive discussion with the lead developer of the project (who will likely ensure that the step is properly announced to all that it may concern). Failure to seek this discussion first justifies denial of push rights in my eyes. – cmaster - reinstate monica Feb 17 '15 at 20:53

1 Answers1

3

Yes, if you have access to the server that hosts the repo you're pushing to (remember that you can technically push anywhere; there's no way to universally disable pushing because of Git's distributed nature).

In the repo you want to reject pushes from, you would simply return 0 from the pre-push hook. For an example of a pre-push hook, see the sample provided with a Git installation:

https://github.com/git/git/blob/master/templates/hooks--pre-push.sample

An alternate technique is to require your users to use a custom wrapper that enforces local policy; there's actually a lot to recommend this technique, as it allows you to enforce other local policy in a much more flexible manner. The downside, of course, is that it's easy to get around.

The approach you take depends on your requirements, of course. If your'e trying to protect against potential abuse (vandalism or unauthorized use), a wrapper will do no good. Most people are not in that position, however (normally authorized users are trusted), and a wrapper is an attractive alternative. An example of the kind of things that we restrict with our local wrapper is adding large images or videos to web repos: we have a CDN replication mechanism for those. It's easy to forget, though, and add an image for testing purposes, and before long, repos get large and ponderous.

As someone who's written (and gotten value from) Git wrappers, my advice is not to try to "improve" the Git interface. Most users want to use Git just as they always have (not some "flavor" of Git). To that end, wrappers usually just provide extra restrictions, disallowing certain types of commits, pushes, etc. But the interface remains unchanged from the regular Git interface.

Ethan Brown
  • 26,892
  • 4
  • 80
  • 92
  • 2
    +1. For the last pargraph: as with web validation, sometimes the best approach is to do both. Use the wrapper to do flexible local validation and give quick feedback, and enforce these validations on the server so users can't do an end run around your rules. Whether it's worth the effort is an exercise left to the reader. – Chris Hayes Feb 17 '15 at 19:08