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.

Implementation

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.

adduser git

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:

$HOME/.ssh/id_ecdsa.pub
$HOME/.ssh/id_ecdsa

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:

  • admin.name.pub
  • name1.surname1.pub
  • name2.surname2.pub
  • ci-sonar.pub
  • some-ci.pub
  • android.user.pub
  • some.body.a.pub
  • some.body.b.pub
  • some.body.c.pub

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:

git@<server-address>:dev/name1.surname1/whatever

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:

git@<server-address>:customer/customera/whatever

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.


[git]