A way to restrict Git branch access?

Question

I have four branches in my git repository, which is managed using GitHub:

• Production
• Staging
• Master
• [person's name]-development

Is there a way to restrict write access to only a single branch ([person's name]-development)? How would I do this?

For reference, a similar question: How to write a git hook to restrict writing to branch?.

Selectee

I know this question is outdated. But have a look at help.github.com/articles/about-branch-restrictions – Hubble

Answer 1

When using GitHub, your best option would be for each developer to have their own fork of the master repository. Everybody pushes to their own repository and somebody with push access to the master repository handles pulling from each developer's repository. This is how most open source projects work.

If using your own Git server, it should be possible to use hooks to prevent users from pushing to wrong branches.

Caudillo

For information on using hooks, check out #4114917 Probably not a good idea? – Knelt

Answer 2

GitHub added the functionality to restrict which users can push to a branch for Organizations earlier this year.

Romina

Answer 3

Note: Protected branches and required status checks (September 3, 2015) won't exactly allow a single branch ("[person's name]-development"), but it getting clone.

The branch will be protected:

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

Mitchmitchael

It should be possible to add a "check" that basically checks whether the commit came from an authorized user. You might not be able to figure that out based on the commit itself (since anyone can fake the email), but you can, for example, have an app where authorized users can whitelist commit hashes before pushing. – Recrudescence

Another option: Make an app that allows incoming pushes to be reviewed and automatically rejected if no one authorized confirms them within a certain time period. – Recrudescence

@Recrudescence your first comment is what gitolite is covering (gitolite.com/gitolite/gitolite.html#overview, https://mcmap.net/q/13380/-gitosis-vs-gitolite-closed) – Mitchmitchael

Gitolite is a git hosting system; it's meant to replace a service like GitHub. It can handle permissions but only for the git repos it hosts. Therefore it can't be used to maintain push access control on GitHub. – Recrudescence

@Recrudescence I agree. I just mention gitolite in relation of the "authorization" feature, not in relation with GitHub. – Mitchmitchael

I see, but it's not clear why Gitolite is relevant here; I was answering the original question of how to make GitHub do this feature. If you want to suggest that they switch to Gitolite instead, you should probably make it a new answer, since that's what it is -- it will be more visible too! – Recrudescence

@Recrudescence Do you know of any GitHub Apps that allow incoming pushes to be reviewed and automatically rejected if no one authorizes them? I am specifically looking for an App that allows incoming pushes by default, but disallows pushes when the an authorized user "flips a switch" to turn off pushing temporarily. – Seigniory

Answer 4

You might want to check out GitLab and its "protected branch" feature. I think it's pretty much exactly what you are looking for. See Keeping your code protected.

Mert

Answer 5

Esko suggested great solution suitable for open-source projects. However it requires that every member of a collaborators team has a paid account on GitHub, which is not always true.

VonC pointed out that there's another solution which involves only one paid GitHub account. And I'm going to provide some tutorial how to implement VonC's solution.

Let's suppose that we have two private repositories: test-test and test-production. The first repo is for development and every member of a team has access to it. The second repo is for automatic deployment of code and therefore strong access restrictions are applied to it.

Setup for developers is pretty simple and staightforward: git clone https://github.com/<username>/test-test, do their work and push it back.

Setup for collaborators is a bit more complicated:

1. Pull branches from the development repo git clone https://github.com/<username>/test-test

2. Add remote repository git remote add production-repo https://github.com/<username>/test-production.git

3. Fetch data from new repo git fetch production-repo

4. Create new local branch for production code and switch to it git checkout -b local-production

5. Tell git to link local and remote branches git branch -u production-repo/production

6. Download contents of the remote production branch to the local one git pull

7. Sort out possible conflicts and that's it!

Now everything that is pushed from the local-production branch will get into the test-production repo and the other branches will be pushed to the test-test repo.

Ok, that's cool, but what about more granular ([person's name]-development) access? - You may ask. The answer is: you can create repos similar to test-test for every developer and use the same pattern for setting them up. The downside of this approach is that collaborators will have to clone each of test-test-[person's name]-development repos.

VonC also suggested to fork the production repo and to make pull requests to it - why not to do like that? Firstly, because you can't fork a private repo without having paid GitHub account. Secondly, to allow someone to fork a private repo, you give him full access to it, so he can push to it directly. And a developer can make a mistake, push to the production repo launching GitHub service hooks and screwing things up. And if you use several outsource developers, this will likely happen.

Also I'd like to warn you about a bugfeature in the official GitHub app for Windows. The branches with an upstream different from the origin will get into origin. So use the command line for pushing.

All these things sound little bit overcomplicated. But it is always like that if you don't want to pay for simplicity.

Rech

I think you can absolutely fork a private repo with a non-paid account, and it remains private. – Stinkweed

Thanks for this tip, Jorge. I found it quite interesting as I feared the non-paid fork would be public. Just verified via paid and non-paid GitHub accounts and you are spot on. BTW, the fork can't be made public even after the fact. – Casing

Answer 6

As with GitLab, so does BitBucket.org have a branch restriction feature.

http://blog.bitbucket.org/2013/09/16/take-control-with-branch-restrictions/

Beestings

Answer 7

In Bitbucket version (Bitbucket v4.9.1) You can restrict changes by:

1. Branch name
2. Branch name pattern
3. Branch name modelling

Following actions can by restricted:

1. Prevent all changes
2. Prevent deletion
3. Prevent rewriting history
4. Prevent changes without a pull request

Enter user that is an exception;

Heartfelt

Answer 8

Not practically. Git branches aren't really distinct from one another in the way that you're probably thinking they are.

What you probably want to do here is use a separate repository for each user's development branch.

Miocene