Please note: The blog moved to this new location – you’ve been redirected. I’ve lost the comments in the migration proccess :( – your feedback is appreciated, I’ll still include your comments and hints if the process fails for you!
Time to rewrite one of the most requested articles in this blog. Getting up a git server on MacOS X Lion real fast. One thing which is new and which is totally awesome: git is part of the Xcode 4.0 toolchain – so there is no reason to install any toolchain like MacPorts or homebrew to get up a git server. Just install/upgrade your developer tools to Xcode 4.0 and git will be available on your machine! Please note – I’ll update this article from time to time, see the change log below the article to reflect latest changes.
Let’s look into the different steps which are needed:
- General information
- Install/Update everything
- Set up a bare git repository for sharing
- Set up your Apache server for sharing
Everything which is about a path to a command, a command or a reference is written in italic letters such as:which, ls. Commands which have to been entered inside the Terminal.app will be written in a code style face. Notice the $ in front of the command. This sign will be an indicator what I typed and where the output starts. Sometimes the command line tends to get longer. In Unix it’s totally fine to break these lines using the \ sign. If are doing the steps manually, just leave the \ sign and put everything in ONE line.
Feedback by some users:
There are some differences between MacOS X Lion client and MacOS X Lion server. The main difference between those two version is the document root of the the apache web server. On MacOS X client the default path to the document root is: /Library/WebServer/Documents/.
On MacOS X server the document root is located at: /Library/Server/Web/Data/Sites/Default.
I will describe everything for the client version. If you are running the server version, make sure to use the correct directory for your version of MacOS X Lion. So just exchange the path from client version to server version and you should be fine. I’ll provide detailed information for a more general setup at a later time.
This is the easy part – everything has already been installed if you updated to Xcode 4.0 The Apache web server is part of the MacOS X OS anyway. If you want to check that you have a working git, just open the Terminal.app and run the which command. This will print the the path to the git binary. If this step doesn’t print you anything you failed the update of the Xcode toolchain. Usually the output looks like this:
$ which git /usr/bin/git
Time to move on with the configuration.
Set up a bare git repository for sharing
Please note: if you are already working with an existing repo you want to share – have a look at this article (Publishing your existing git repo).
In order to share a repository with the apache web server we need to setup a bare repository. Let’s dive into a few parts of the development processes. Usually you start coding and after a short time you realize, that you should store things in version control – or you start with version control from scratch. It doesn’t matter which is the right way – we just want to get started quickly.
Let’s change to the terminal app and create a bare repo!
Change the working path to the web server document root and create an empty directory named myproject.git inside it. Change into the directory, run git init –bare to set up a bare repo. We’ll have to use the sudo command as we are not allowed to write inside the web server document root by default. It’s only a sequence of short steps.
Here are the steps inside the Terminal.app window:
$ cd /Library/WebServer/Documents/ $ sudo mkdir -p repo/myproject.git Password:
* Please note – it’s your user password which is requested! *
$ cd repo/myproject.git/ $ sudo git init --bare Initialized empty Git repository in /Library/WebServer/Documents/repo/myproject.git/
Voila, our first repo has been setup! However, it’s not very useful for now. The web server is still turned off, the only way to access it is by using a direct path on the filesystem.
We now prepare the git repo to be shared by the web server and – to be updated by the web server. We’ll start with the commands inside the git repo and work our way to the web server configuration. When we want the web server to behave to commits and clones correctly we need to enable the post-update hook. This hook runs a certain git command every time someone updates or pushes code to the repo. After that we’ll allow the web server to read and write the repo files. Right now, the web server can only read them.
The Terminal.app it still open and we are still located inside the directory of our git repo – good. The first command shows the working path – it should be our project.
$ pwd /Library/WebServer/Documents/repo/myproject.git $ sudo mv hooks/post-update.sample \ hooks/post-update $ sudo chown -R _www:_www \ /Library/WebServer/Documents/repo/myproject.git $ sudo -u _www hooks/post-update
The last step was running the enabled post-update hook. This hook sets some references about revisions in our (still) empty repository. We now have a fully enabled git repository which is ready to be served by a web server. Yay! Let’s now move on to the steps for configuring the web server.
Set up your Apache server for sharing
The scenario for our repo is quite simple. We want to setup two different groups for our repository. One group is able to read the repository – aka to clone it. The second group is able to write to our repository, hence to commit changes back to it.
So – what’s our job now: Create a password file for the web server, create a group file for the web server, configure the web server.
The password file contains user and passwords and will be created using the htpasswd command. The syntax is simple. We need to supply an additional command flag for the first user in order to create the file first.
$ sudo htpasswd -c \ /etc/apache2/other/htpasswd-git rhaen Password: New password: Re-type new password: Adding password for user rhaen
It looks a bit confusing. The first password prompt was for the sudo command, the second and third were for the htpasswd command. If you go straight to the tutorial it might not be necessary to enter the sudo password as it is being cached for a while.
Now we created a htpasswd-git file with one user – named rhaen in it. Just add isolde as second user.
$ sudo htpasswd \ /etc/apache2/other/htpasswd-git isolde New password: Re-type new password: Adding password for user isolde
The group file is a plain text file which contains groups and the users in. I like to use the editor vi, however, just use any text editor you like. Make sure to save the file as plain text. The contents of the text file will look like this:
myproject-reader: rhaen isolde myproject-writer: rhaen
I removed the “.git” suffix from the project for better readability. We refer to the group name inside the configuration of the web server. Also note that the user isolde is only in the group of readers. Save this file to your desktop with the name htgroup-git and move it to the web server config directory.
$ sudo mv ~/Desktop/htgroup-git \ /etc/apache2/other/
Now to the final step: the configuration of the web server. Use your favorite text editor and copy/paste the following configuration snippet listed below, download it and open it in an editor. Here is just an example image what it looks like.
A screenshot of the configuration file gitrepo.conf
The image shows the configuration at it’s glance. The download link is here. Save this file as gitrepo.conf on your desktop. Before we enable this file, let’s have a closer look in it. The first directory part disallows all kinds of access to the directory named repo and below. That’s the reason why our git repo will be protected. It also configures the apache web server which password and which group file is the right one.
The second directory is the configuration about our project. It separates the user in reader and writer and requires the certain group for it.
As we are using DAV for the git push we need to enable a lock directory. OS X has a default one which is configured but it doesn’t exist. Let’s create one – we have already enabled it in our configuration file on the first line.
$ sudo mkdir -p /var/www/DavLock $ sudo chown _www:_www /var/www/DavLock
Let’s move this file to the correct place and restart the web server.
$ sudo mv ~/Desktop/gitrepo.conf \ /etc/apache2/other/
There you go!
Feedback
from a user:
Something which is very important for the correct function of the web server is to enable “web sharing” in your system preferences. Go “System Preferences” – Sharing – and click the checkbox web sharing. After that run the following command:
$ sudo apachectl restart
Now it’s time to test everything! Open your web browser and try to access
http://localhost/repo
You should get an error. Fine! (This results from the deny all rule). Change to the terminal and try to clone the repo:
$ git clone http://rhaen@localhost/repo/myproject.git Cloning into myproject... Password: warning: You appear to have cloned an empty repository.
YES! You know have a fully working git repo with clone and even push support ready! Add some code into it and push the changes! Enjoy!
If you see the following error: $ git clone http://<username>@localhost/repo/myproject.git fatal: could not create work tree dir 'myproject'.: Permission denied
You try to clone into a directory which is not writable for you. Please try to clone on your MacOS X desktop – this should always work. Change to the desktop:
$ cd ~/Desktop
and clone again.
This is just a tutorial to get started and it won’t solve everything. Give me feedback what worked for you – I’ll monitor my mails carefully and try to help you. Thanks for all the feedback so far! A lot of feedback has been provided so far, thanks to everyone who contributed so far. Here is a small change log what happened:
- 2011-07-29 updated article – included information about the web-sharing control panel
- 2011-08-07 updated, added MacOS X Lion server information
- 2011-08-11 updated, added DAV lock directive (feedback from user)
- 2011-08-27 updated, moved blog to a new location, included feedback about cloning errors
- 2011-09-04 updated, added anchors, changed post-update
