1

The goal: Use Git+SSH for multiple independent developers to deploy code to production web server, without need for any subsequent developer intervention on server. Don't want to run FTP, don't want to give SSH access to shell accounts, don't want to manage user accounts (apart from gitolite).

Disclaimer: I'm new to git.

Git and gitolite are installed on web server and running nicely over SSH. Nginx docroot directories are in /srv.

I originally envisaged that gitolite would create repos that contained actual files, and that I could simply create symbolic links from the git repos to /srv.

But no, it seems gitolite stores "bare" repos in /home/git/repositories which don't contain readable code (working directories).

I have tested that it is possible to clone & pull repos locally from /home/git to /srv using commands like "git pull git@localhost:somerepo" (if user running command has appropriate key) and "git pull /home/git/repositories/somerepo" (avoid networking + SSH altogether).

So, it seems that after code updates are pushed to the server, a hook (or hack) could pull/merge updated repos from /home/git to /srv and restart the server.

Is this approach sane, have I missed some basic feature or functionality of git/gitolite, or is there a much better git-based solution out there? rsync is the another possibility I may explore if git proves unworkable.

1 Answers1

0

Gitolite is an authorization layer. Nothing more, nothing less.

Through VREFS (Virtuals refs), you can add as many post-update hooks to those bare repos managed by Gitolite, in order to checkout (and deploy) said bare repo.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250