Build your own GIT server
Git in context
Most developers have nowaday migrated to Git from arcane, older legacy systems, and this is for good. We use it because we know that there our code is (mostly) safe.
There is a lot of actually very good providers out there that will help you and set up a server for you, on their machines. There is Gitea, there is GitHub, you just do your job, push to them and let them backup your own code.
For most people this is just fine, I can’t understand that well for companies tough. Maybe you do, and then again, it is fine. If you feel like you’re not, you can justa have your own Git server, because it is simple, it is simple to backup, it is simpler if that’s just what you need: a GIT server. Marketing is pushing hard GUIs on us, but that’s nothing to do with GIT: you want your code to be safe, you want to be able to access it from anywhere, you don’t want to be typing your password around.
This is how you get it.
You need a server online with a user. It can be physical or a VPS, it could also be a non-root unix account, if the administrator is kind enough to install the gitolite binary for you.
For the root part, you have to install the gitolite binary, I guess on some systems you’re just fine like this:
# apt-get install gitolite
Once gitolite is available, you might want a clean git user (call it what you want) for the purpose.
and then you should generate on your local machine an ssh keypair to connect to the machine, like this:
ssh-keygen -t ecdsa
at the end of the generation, you’ll have the following two files:
You will need to move the public key on the git server in order to go on with the installation, i.e.:
scp $HOME/.ssh/id_ecdsa.pub git@<your-server>:/home/git
Now we’re ready to start creating the gitolite setup on the server:
gitolite setup -pk id_ecdsa.pub [...] git clone $HOME/repositories/gitolite-admin.git vi gitolite-admin/conf/gitolite.conf
and put in the file gitolite.conf something like that:
@administrators = admin.name @developers = dev1 name1.surname1 name2.surname2 @ci = ci-sonar some-ci @mobile = paolo.android @customera = some.body.a @customerb = some.body.b @customerc = some.body.c repo gitolite-admin RW+ = @administrators repo dev/CREATOR/[a-zA-Z].* C = @developers R = @ci R = @mobile RW+ = @developers RW+ = CREATOR RW = WRITERS R = READERS repo customer/customera/[a-zA-Z].* C = @administrators R = @ci @customera RW+ = @developers RW+ = CREATOR RW = WRITERS R = READERS repo customer/customerb/[a-zA-Z].* C = @administrators R = @ci @customerb RW+ = @developers RW+ = CREATOR RW = WRITERS R = READERS
The peculiarity of gitolite is that all the configuration is contained in a GIT repository, you should be able to check it out, and change the settings. It will become effective once you push it back to the central repository. To be more precise, this gitolite-admin project will contain both the setup and the client keys to connect to the development repositories.
The setup above defines users, grouped by names:
@administrators = admin.name @developers = name1.surname1 name2.surname2 @ci = ci-sonar some-ci @mobile = android.user @customera = some.body.a @customerb = some.body.b @customerc = some.body.c
For each of the users, you’ll need a public, key, for example the directory keydir should contain:
A detail about the possible permissions:
C, to allow repository creation R, to allow read operations only RW, to allow fast-forward push of a branch, or create new branch/tag RW+, to allow pretty much anything -- fast-forward, rewind or delete branches or tags - (the minus sign), to deny access.
In addition, the setup allows individuals to create repos of their own such as:
simply by issuing the command:
git clone git@<server-address>:dev/name1.surname1/whatever
then all the developers with a key in @customerc will be able to use repos like:
only members of the group @administrators will be able to create it initially with
git clone git@<server-address>:customer/customera/whatever
they’ll be able to clone it and start to work, push against it once it has been created.