src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
Step 1: Install Git. You'll have to do this ON BOTH YOUR SERVER AND LOCAL MACHINE. If you're running a different OS for your client find and check out instructions for installing git on that OS instead. See this link for OS X if you don't have Mac Ports.
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install git-core
Step 2: Set up the server. We'll have to do some work on the server. We're going to use Gitosis which needs python and a python setup tool to get running. Grabbing the python setup tool in Debian/Ubuntu will grab all the requirements if you don't already have them:
sudo apt-get install python-setuptools
Step 3: Gitosis. Now it's time to get Gitosis. For the most part I followed the instructions on scie.nti.st, so full credit and many thanks to them. Once you're done with my instructions, I recommend you go visit them and read more details on adding users and some other advanced topics.
From your home directory on your server, create a new directory called src, and from there grab the gitosis code.
mkdir ~/src
cd ~/src
git clone git://eagain.net/gitosis.git
Install it using the python setup tool we grabbed earlier.
cd gitosis
sudo python setup.py install
Step 4: Setup some security. We're next going to add a new user called git. This is the guy that will do all the heavy lifting for us!
sudo adduser \
--system \
--shell /bin/sh \
--gecos 'git version control' \
--group \
--disabled-password \
--home /home/git \
git
IMPORTANT: If you have locked down ssh, don't forget to go into your /etc/ssh/ssh_config file and add git to the list of Allowed Users that can login. That list of users is separated by a space not a comma.
I always encourage the use of public/private key exchange and in the case of gitosis it looks to be required. Generate a key if you haven't already. See instructions for public/private key here. I'm going to assume that from this point on you can access your server from your local machine using a public key exchange!
Next, copy your id_rsa.pub file over to your server somewhere (in our example we're using /tmp) and then run this command:
sudo -H -u git gitosis-init < /tmp/id_rsa.pub
You'll see output like this:
Initialized empty Git repository in ./
Initialized empty Git repository in ./
Others have reported seeing that 3 times but when I did it on Ubuntu Hardy Heron I only saw it twice.
Step 5: Minor permissions tweak. Just in case, let's make sure permissions are set correctly:
sudo chmod 755 /home/git/repositories/gitosis-admin.git/hooks/post-update
We're now done with the server config! From your local machine, test it out with this:
git clone git@YOUR_SERVER:gitosis-admin.git
If all went well you have a gitosis-admin directory with a gitosis.conf file and keydir directory. We're basically setup now. We just need to create a new repository and push it to the server.
Step 6: Configure gitosis for a new rails project. Use your favorite editor to create a new block under the gitosis one. It should look like this:
[group myrailsapp]
members = vince@urbanpuddle
writable = myrailsapp
A couple of things to watch out in the above block. First, make sure your name matches what's in your public key (that is, open your id_rsa.pub file and see that what the name says. Mine says vince@urbanpuddle so that's what I have above. Yours will be different.) Second, make sure you spell writable correctly!
Once you're done, commit and push the changes up to the server.
git commit -a -m "created a new repository!"
git push
What we've basically done in this step is configured gitosis to accept a new repository. We then submitted that new configuration to the server using Git itself. Genius!
Step 7: Put your local code under version control. Now that the myrailsapp project is waiting for us on the server let's go put it under version control on our local machine.
cd myrailsapp
git init
As you may have heard, most of the goodness with git is in a special hidden .git directory at the root of your project. That's pretty cool since it means removing your project from version control is as simple as erasing that directory. Way easier than subversion.. especially if something goes wrong..
If you're a Rails developer you may want to blacklist some things from being under version control. Open up a text editor and create a file called .gitignore in the root of your project directory. Fill it up with this goodness:
.DS_Store
log/*.log
tmp/**/*
config/database.yml
db/*.sqlite3
Thanks to Ryan Bates for the above. If you haven't checked out Railscasts 96 you should do that as well. There's good info on creating empty files in a few empty directories to make sure they're under version control.
Step 7.5: Designate the server as a remote repository. An interim step here is to remote add the files to the server we set up previously. Honestly I'm not sure what's going on here under the covers but it's necessary..
git remote add origin git@YOUR_SERVER:myrailsapp.git
Step 8: Add files and commit! Let's add everything to git, (note the trailing dot) and then push your initial commit to the server.
git add .
git commit -a -m "initial import"
git push origin master:refs/heads/master
Once that's done you're done! You can grab your code from any place that has public key access to your server using this command.
git clone git@YOUR_SERVER:myrailsapp.git
Again, please please go check out this post which was the inspiration for 90% of what you just read. They did a great job and go into more detail in some spots than I did. You'll also likely find questions and answers to any errors you encounter on the way there.
Also, as promised here are some resources:
Last thing, if you're on Debian or Ubuntu and follow the Peepcode, keep in mind you'll need to separately install gitk.
sudo apt-get install gitk
I've been messing around with Sunspot in Rails lately. One of the issues that I ran into is that the index is stored in the application root's solr directory. That's usually not a big deal, but if you use capistrano, then you know that you end up with a new application directory with each deploy. So how do you handle that?
I love free software. But, there is something to be said for paid support. When it comes to email, sometimes a robust mail server is just what the doctor ordered. 
There are lots of great instructions out there for using Git so you may not be interested in another one. Mine is no doubt imperfect as well, but I didn't find a front-to-back tutorial for getting rolling with Git on your own centralized server. I ended up cobbling information together from a bunch of sources (which I will list below). Mostly for my own benefit, I'm posting what I learned here. Feel free to ignore or read on as you desire.. By the end of it we'll have installed Git on a server, created a repository on that server, and checked in code from our local machine.
Click 
Follow me on twitter