How to protect "master" in github?

Asked 30/4, 2012 at 9:53 Answered 26/2, 2018 at 11:32

I have a few contributors in my github project. I want to allow only one of them to "push" to master. And this guy is not me (the owner of the repository). Is it possible to do?

Gaiser answered 30/4, 2012 at 9:53 Comment(6)

Is it a private project? If it's not, they don't need to be collaborators necessarily - they can fork and use pull requests exclusively (which enforces a level of pseudo-code review to merge changes) – Rubberize 22/5, 2012 at 14:14

This functionality is not supported by github, but if you are looking for similar solutions: Assembla Repositories support this: blog.assembla.com/assemblablog/tabid/12618/bid/96330/… DIY - self-hosting git: git-scm.com/book/ch7-4.html DIY - self-hosting mercurial: mercurial.selenic.com/wiki/AclExtension – Keiko 21/3, 2013 at 10:47

possible duplicate of A way to restrict Git branch access? – Sequence 3/6, 2014 at 11:32

Sept. 2015: it looks like that feature is coming in GitHub: see my answer below – Biff 3/9, 2015 at 19:29

Seems like it is (more or less) possible now; github.com/blog/2137-protected-branches-improvements. Push access for a specific branch can be restricted to certain users now. Admins will be able to push regardless of this setting however. – Bedford 30/4, 2016 at 19:22

Back then, when this question was posted, GitHub didn't allow you to specify access privileges on a branch level. You can only do it on a repository level. So what you are requesting wasn't possible.

If you want to work around this limitation, I personally see two options:

you could use some kind of commit hooks, etc. to at least inform someone that something wrong happened
If you really need this tight control, you could use two repositories, one only holding your "master" branch. You would then need to make sure that only your "guy" gets write access to the master repository

I think it is easier to solve that with some organisation. In my team, we never push anything directly to master, but instead always create pull requests. That ensures that at least someone takes a look before code gets merged and you could also define a policy that only your "guy" is allowed to merge pull requests.

Update

GitHub now announced that they will roll-out a new feature called protected branches. This feature has been present in other git distributions like Atlassian Stash for years. It will allow you to protect some branches from pushes. However, it still doesn't allow complete ACL-based protection of individual branches. So you might want to check this feature out in case you don't want to rely on an organizational solution as outline above.

Jewry answered 22/5, 2012 at 13:53 Comment(6)

"we never push anything directly to master" - because you can't or because you agreed not to? – Gaiser 22/5, 2012 at 14:23

Because we agreed to not do it. Sometimes it is easier to find a soft solution instead of a technical. – Jewry 22/5, 2012 at 19:55

Btw I think that this is a general issue in git/github workflow! Most people contributing try to commit into master first, in all projects i've seen... – Pehlevi 2/7, 2013 at 12:25

If you run into those problems, you might also want to take a look into other hosting services/tools such as Atlassian Stash. They provide branch-based permissions. – Jewry 10/11, 2013 at 20:41

Assembla has a good set of features to make different git workflows and code review processes. In Assembla you can protect any branch and give write permissions to certain users. One nice feature is "Enforce code review"; when someone push to master, it remains untouched and a new branch is created instead with the code changes, then automatically creates a merge request from the new branch to the master, so other team member can review/approve the changes. – Marvelous 12/6, 2014 at 19:18

We safeguard against accidental pushes to master with hooks + protection on CI side: dimaip.github.io/2015/06/03/protecting-github-branch – Af 2/6, 2015 at 22:10

Note: Protected branches and required status checks (September 3, 2015) will allow you to protect a branch

against forced pushed
against deletion
against merged changes until required status checks pass

Since March 2016, as commented by Sander below, you have User and team restrictions

Sometimes merges to a protected branch are best left to a release manager or a team of people responsible for the stability of that particular branch. Organizations can now specify which members and teams are able to push to a protected branch.

Biff answered 3/9, 2015 at 19:26 Comment(4)

pity, you still can't restrict branch access to certain members....Would love that feature for the master branch. – Dryad 5/9, 2015 at 17:23

I agree, or at the very least be able to restrict merging to administrators only for protected branches. – Ballentine 8/9, 2015 at 11:49

@PratikBothra github.com/blog/2137-protected-branches-improvements Seems like it is possible now. :) – Bedford 30/4, 2016 at 19:18

@Bedford I agree. I have edited the answer accordingly. – Biff 30/4, 2016 at 19:21

This is exactly what forking was designed for. You would have the main repository protected, and you would allow read permissions on that repository for all contributors. Those contributors would fork the repo, and would push their changes to their personal copies of the main repo. When they are ready to introduce code into the main repository, they would submit a pull request into the main repo. In this case, owners of the main project could complete the pull request.

Glasswort answered 9/2, 2015 at 2:32 Comment(1)

The problem with the forking/PR workflow is that a member who has "write" privileges on the main repo could still push to it. – Latent 11/6, 2015 at 14:11

We can now use "CODEOWNERS" file to Require review from Code Owners to valid a pull request. We can set different permissions based on their GitHub account.

see here and here

Bula answered 26/2, 2018 at 11:32 Comment(0)

Recommended topics

Hot tags