git branch permissions

Question

Is it possible to set branch permissions using git bash? I would like to have much more strict permissions on the master branch, so that some people can use the development

Answer 1

If your developers team is a civilized bunch who only need a friendly reminder, you can reject a push using a pre-receive server-side hook:

#!/bin/bash

# Extract the user email (%ae) from the last commit (author email)
USER_EMAIL=$(git log -1 --format=format:%ae HEAD)

# Looping through all the pushed branches
while read oldrev newrev refname
do
    branch=$(git rev-parse --symbolic --abbrev-ref $refname)
    if [ "master" == "$branch" ] && [ "the_integrator@your_company.com" != $USER_EMAIL ]; then
        echo "Naughty naughty!"
        exit 1 # fail, i.e. reject push
    fi
done

Although users can easily fake their git email address, I would still make the hook file itself read only.

Refs:

1. How can I get push user information in server side git hook?
2. Writing a git post-receive hook to deal with a specific branch

Answer 2

Git does not have branch specific permissions. You can either make the whole repository read only to the people or create one private and one public repository and only push the development branch to the public on while keeping the master only in your private repository.

Edit: For branch specific permissions, you need a server-side authorization layer like Gitolite — obviously, this requires you to be managing your own Git server.

Answer 3

bitbucket supports branch restriction. See the link here : https://blog.bitbucket.org/2013/09/16/take-control-with-branch-restrictions/

Answer 4

A typical scenario where this might be needed is to restrict access to official (or release) branches to a subset of people on a team. A good strategy here might be to have two repos -- a primary repo that is more tightly access controlled, and another repo that everybody in the team has access to and is used to setup working branches. And perform pull from the working branches to the main repo, as needed. Of course, you can tweak this to fit your team structure and needs.

This can work especially well with services like github.