1

Is there an easy way to configure our git repo in a way that would only allow a pre defined set of users to push into master branch on origin ?

I have found certain tools that require payment for such a task, but was wondering whether this was supported in git by default, without the need for a git server tool.

Any comments and directions would be welcome.

Pumpkin
  • 1,993
  • 3
  • 26
  • 32
  • you could use your linux or windows user permissions to the directory of you origin – Chris Maes Mar 03 '15 at 11:37
  • gitlab is a free git server which is very nice. you can take a look at this answer: http://stackoverflow.com/a/22906383/2082964 – Chris Maes Mar 03 '15 at 11:39
  • possible duplicate of [git branch permissions](http://stackoverflow.com/questions/13248246/git-branch-permissions) – Chris Maes Mar 03 '15 at 11:40
  • Is it possible to set branch permissions using git bash? is not a duplicate of what I'm asking. An answer to my question would require guidance regarding how I can write a pre-recieve hook on server side to accept a set of hard coded users which I'm supposed to get by stdin. – Pumpkin Mar 03 '15 at 15:10
  • There is probably a way; but will take you time, why reinvent the wheel if with gitlab you can have everything in a very fast way? – Chris Maes Mar 03 '15 at 16:03
  • We already have a git server, changing it requires a battle with bureaucracy that is not feasible, and our discussion is starting to get off topic. – Pumpkin Mar 04 '15 at 08:25

2 Answers2

1

A simple solution would be to write a custom hook to listen each update and have a custom authentication solution.

Within the .git file there is a hook directory, which contains example implementations for custom hooks. Deleting the .sample suffix would simply make that hook become operational ( the hook examples there have callback registrations by default ).

Update hook would be triggered after each push, exiting 1 would simply disallow for that push to be applied. Something on the lines of :

refname="$1"
oldrev="$2"
newrev="$3"

author="$(git log $newrev -1)"

# user names on the white list
whitelist=( 'Admin1' 'Admin2' 'Admin3'  )

# branches to be controlled
master="refs/heads/master"
test="refs/heads/test"

if [[ "$refname" == "$master" || "$refname" == "$test" ]]
then
                for name in "${whitelist[@]}"
                do
                                echo $name
                                if [[ "$author" == *"$name"* ]] 
                                then
                                                exit 0
                                fi
                done
else
                exit 0
fi

echo "Master or test branch is not within your reach ! Contact your supervisor ! "
exit 1

I strongly advice you to write your own script according to your authentication policy. The above script is just to give an idea and is easily hackable.

Pumpkin
  • 1,993
  • 3
  • 26
  • 32
0

Git does not have any permission system of its own. You will have to use something else to manage them like GitLab or gitolite. You can also build your own using git hooks.

orkoden
  • 18,946
  • 4
  • 59
  • 50
  • Thx for your reply, however I need more details regarding how I can write a pre-recieve hook. We do auth by basic http. I don't see how I am ever going to recieve stdin arguements from server side that carries the auth information. – Pumpkin Mar 03 '15 at 15:06
  • That being said the tools you mentioned desire payment in our case, and I can not consider them as a feasible solution even if they didn't require payment, seeing as how there are other options. – Pumpkin Mar 03 '15 at 15:07
  • You can install GitLab Community Edition and gitolite on your own servers without paying anything. If you really want to roll your own, start by [reading the docs](http://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols). – orkoden Mar 03 '15 at 15:39
  • Once again, we already have a git server. Changing it would require a lot of effort, not just on technical manner but at bureaucratic level. Therefore a simple hook script would be a much better solution in our case. Any directions towards there would be welcome. – Pumpkin Mar 04 '15 at 08:27