A way to restrict Git branch access?

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: https://stackoverflow.com/questions/4114417/how-to-write-a-git-hook-to-restrict-writing-to-branch.

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.

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

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

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.

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.

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

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

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 rewirting history
4. Prevent changes without a pull request

Enter user that is an exception;

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.

If you use bitbucket - there are branch-permissions for handling that. https://confluence.atlassian.com/bitbucket/branch-permissions-385912271.html