I started developing this site on a locally hosted machine with just a local git repository. This worked great but wasn’t suitable when I wanted to deploy it. I’m new to git but I very useful when I was developing, so I wanted to find a way to continue using it to help me manage my code. If you’re not a bit familiar with git this is probably not the right place to start. (For that, I suggest reading this free Pro Git book or just playing with a test repo you can tinker with safely.)
My ideal setup and process for development seemed simple but I found it very difficult to set up and get working the way I wanted it, so I hope this post helps someone in a similar situation. Here’s what I wanted:
- A primary ToWatchList site which wouldn’t get changed unless I specifically pulled a version of my site from my git repository.
- A secondary development site where I could tinker and hack at stuff without breaking anything for my normal users hosted under a subdomain of my main site.
- A secure git repository that would still be fully accessible from any computer I chose to work from.
- Integration with the new git version control features of Coda 2 which I’m greatly enjoying using.
Seems simple but it turned out to be a bigger pain to set up that it should have been.
Here are the problems I had:
- My VPS hosting provider Linode (that’s an affiliate link, I highly recommend them, thanks) has excellent documentation with instructions on how to set up many common hosting features. However their info on git was a little out of date, primarily because they recommended using gitosis as a git server though it has been deprecated by the community (and removed from Ubuntu 12.04 Server repositories) in favor of gitolite.
- Actually installing gitolite can be a confusing process until you really wrap your head around what it’s doing and how it works.
- Coda 2 has only the most minimal documentation on how to use it with git. I had to try several setups before I was even able to get it working correctly.
Let’s work through those issues. As I said before, I’m using Ubuntu server but the info should be equally applicable to other distros.
First: You should use gitolite not gitosis. That’s why I’m writing this guide. Alternatively, you can probably host your code on github but I wanted to run my own server, so we’ll be following that path.
Second: gitolite is confusing for two related because it’s install process is clunky if you’re installing it from the provided repositories (something I try to do whenever possible) and because it’s mostly controlled via git rather than many config files.
Rachel Aurand has written an nice procedure that I’m going to crib off of here to get things started with the install (remember these steps are for Ubuntu 12.04 but should be similar on other distros).
First make sure you have the regular git software installed:
sudo apt-get install git-core
You should probably also set a few global settings for git like this:
git config --global user.name "Your Name"
git config --global user.email firstname.lastname@example.org
There are lots of other config tweaks you can make that will make things more pleasant when using git, here’s a great interactive tutorial (that requires a free sign-up) and another nice guide to get you started. Also, this post has some good starting settings. In particular, I recommend setting
repack.usedeltabaseoffset, along with disabling
core.legacyheaders as shown below but there’s lots more good tweaks.
git config --global help.autocorrect true
git config --global color.ui auto
git config --global repack.usedeltabaseoffset true
git config --global core.legacyheaders false
Next you’re going to need a ssh public/private key for each machine or user you would like to access git repo from, including the machine you’re hosting your repos from if you’d like to access them locally. Here’s the basic command for generating them:
ssh-keygen -t rsa -C "name@computer"
You can accept the defaults from that command in most cases. If you do, the .pub files you’ll need will be located under
~/.ssh/id_rsa.pub. Name copies these .pub files so you’ll remember each user/machine they’re associated with and upload/move them to the
/tmp directory of your repository server.
Now go ahead and gitolite on your server:
sudo apt-get install gitolite
Because it doesn’t have great setup scripts, that install might complain or warn about not having the right user account set up, no worries, let’s do that now. Create a user to “run” gitolite with on your server:
sudo adduser \
--shell /bin/bash \
--gecos 'git version control' \
--home /home/git \
Now switch to the newly created user, and set the path, and move to its home directory:
sudo su git
echo "PATH=$HOME/bin:$PATH" > ~/.bashrc
No we need to run the gitolite setup command with the public key you copied to the tmp directory for the machine you’re running the repository on:
If it shows you any config files during this step, simply exit them without editing. This setup script creates two repositories: gitolite-admin.git and testing.git repo along with some config files for gitolite-admin. First let’s clone the gitolite-admin repo to the account on the repository server where we generated the Check to see that everything works by cloning the repo on the machine with the public/private key.
git clone git@:gitolite-admin
You can now edit the config file under
./gitolite-admin/conf/ and add any other .pub key files you generated to
./gitolite-admin/keydir/. Syntax for the conf files is super simple but here’s the documentation for adding repos as well as some notes about using keys, which, remember, represent users.
Once you’ve set stuff up to your liking you should be able to add/update all the new files and modifications and push them back to the server for updates with these commands from within the
git add .
git commit -a -m "Initial Setup"
At this point you should probably clone the testing and gitolite-admin repositories to any other machines you plan on developing on to get a feel for how things work, particularly if you’re not an experienced git user. Once you’re comfortable it’s time to set things up for your development subdomain, which I’ll handle in Part 2.