Adminstration Questions


I’m going to summarize how our organization has been managing GitHub with an eye on avoiding mishaps and so on. Then I’d like to ask if there are better ways to do this (we now have GitHub enterprise).

We have repos “owned” by the organization and we have developers (myself included) who fork these repos.

Developers push and force-push to their forks as they work on projects.

Then they create PRs to move commits onto the organization repo.

A problem here is that I (a senior engineer) work as a developer but also have authority to merge PRs (modify the organization repos).

So if I was not careful I could - by accident - do a force-push to the organization repo causing serious problems.

To avoid this we - seniors - have two GitHub accounts, one we use for working as developers and another reserved for logging into GitHub and merging PRs etc, this account is only used for this kind of stuff and I actually use Opera browser for this where this browser knows only about my other account that has admin control over the repo.

If I access GitHub through Chrome or via SmartGit (are preferred GUI) then it knows nothing of the other account and knows only about my ordinary developer account.

This pretty much how we’ve worked but are there better options with enterprise?

As I said the goal is to prevent a developer accidentally doing a force-push or other update to an organization repo even if that developer is the person responsible for merging PRs.


PS is there anything like an ability to “elevate” to admin rights (if I have these defined for me) so that unless I explicitly do that my rights are limited to being able to update only my fork of an organization’s repo?

Hi korporal! :wave:

It sounds like what you want is to have protected branches set up in the repos owned directly by the org:

That way you can forbid force pushes from anyone, including repo admins. That might be a more convenient solution than juggling multiple accounts?

I’d be interested to hear of other peoples’ strategies to handle this, too!


I just discovered roles “Triage” and “Maintainer” and sadly neither of these offers what is needed.

It seems GitHub have tied together the concepts of pushing to a repo with merging a pull request.

A “Maintainer” can merge PR’s but when I experimented with a direct push to the repo (not my fork) it worked.

The way we work is that every project has a branch in the main repo and developers push to their forks and peridocially create PRs to merge the project branch in their fork with the project branch in the main repo.

Our approach has been to make it close to impossible for anything to get into a main repo other than by a PR, this completely eliminates any risk of any branch getting messed up by a force push or untimely push.

How about separating pull request merge permission from push permission? This is totally under GitHub’s control since pull requests are not part of Git.

Protected branches might seem promising but it is not, it offers no ability to distinguish between merging pull requests and simply pushing to a branch. This was the case four years ago and is still the case today.

Org permissions is something we’re iterating on rapidly at the moment, and I know the long term plan is to allow people to define custom roles. I’m not sure that separating the ability to merge from the ability to push to a repo is on the table though.

We’re always working to improve GitHub, and we consider every suggestion we receive, so perhaps you’d like to submit a feature request through our official product feedback form so that our product team can see that you’d like the ability to define custom roles in this way?