Git server with username and password authentication

Question

I would like to set a Git server and let my developers login using username and password in order to commit and make changes to the projects. I need also to manage developer access to projects (I think I should use gitolite for this).

How can I do that?

I am used to Subversion which is easy because you can set username and password for each developer, which can easily access the repository without having the generate an SSH key and put it on the server.

Answer 1

On Unix/Linux, just create a new directory on your server for your git project (naming convention is that folder names should end with .git). Then initialize the directory with:

git init --bare

Now you have an empty git main repo. Users can clone this repo from your server with:

git clone username@hostname:/path/to/git/folder

(password will be asked for)

Use Unix/Linux user administration tool to manage your developer access.

Answer 2

If you consider "How do programs like gitolite work?", gitolite is just an authorization layer, meaning a script which:

• takes as input a git command and a user id
• gives as output an ok or denied (if ok, calls the git command)

So gitolite itself won't allow a login with username/password (or ssh for that matter).

Only the listener you put in front of git/gitolite will ask for said username/password and will check its account validity.
Or you can use an sshd listener if you want to work with public/private key, but the idea is the same.

See "Using LDAP as auth method to manage git repositories": if you put an Apache or NGiNX, those web servers can query an LDAP server and ask/check those credentials.
That is the authentication step.

Then you would need to link them to gitolite (not git) for the authorization step,
like I do in this Apache configuration file

ScriptAlias /hgit/ @H@/sbin/gitolite-shell/    # <=== calls gitolite.
SetEnv GIT_HTTP_BACKEND "@H@/usr/local/apps/git/libexec/git-core/git-http-backend"

gitolite will need GIT_HTTP_BACKEND in order to call git properly.

Note that, as I explained in "Distributed Version Control Systems and the Enterprise - a Good mix?", git alone doesn't care and doesn't deal with authentication/authorization.
Hence the listener you put in front of it.