I have seen various people using Git on a daily basis from design agencies to software houses, all in slightly different ways. There are many reasons for using Git or even other version control systems especially where there are two or more people collaborating on any one project at the same time.
The importance of using version control also increases with the size of a project and makes it possible for developers to collaborate or work on separate features of a project and manage and test their changes accordingly. This comes in many flavours and can be thought of in terms of 'centralised' or 'distributed'. Some mainstream examples of version control systems include Centralised: Subversion (SVN), CVS, and Perforce, aswell as Distributed: Git, Mercurial etc. (see What is Verison Contol).
One of the benefits of Git is that it is a 'distributed' version control system. In essence it allows developers to be able to work virtually anywhere on their local computer or network, and be able to commit and manage there changes locally. When a developer is finished working on their new 'feature' they then have the option to push or merge their changes with a git server or repository that is publicly (or privately) available.
Git was devised and developed by none other that Linus Torvalds one of the driving forces of the Linux kernel that the majority of websites in the world currently run on today. The concept of Git seems to mirror that used in the natural world where the process of evolution can be seen to branch off in different directions. Similar to Linux, Git is open source and free software distributed under the terms of the GNU General Public License version 2.
So, why would I want to use git on my own projects? Well, there are other benefits, but the main reason I want to use it is it offers many benefits over my existing system, namely ftp. For example, with git, once I have set up the repository for my project on my git server, I can easily create different branches. So typically I could set up the following branches in order to manage the release cycle(s) of my project(s).:
Git makes setting up and managing branches for these fairly stright forward. In fact their are no limits to how many branches you can have at anyone time. It also allows you to create separate 'feature' branches or 'hot fix' branches that can be spun of say Development and worked on independently.
Show me the power
Git is quite powerful and also gives you great flexibilty. For example, using Git I should be able to make changes in development and then spin of a staging verison for testing which in turn can be branched of into a production branch for release. In theory I could even make my tweaks with production and then synchronise with a future release branch. In short it provides me with an intelligent and powerful yet reasonably lightweight way of managing my projects between environments through a series of relativly simple shell commands. This also opens the door to collaborating on projects with other developers, plus the ability to implement some Quality Control in the release process.
Setting up Git
Ok, now lets look then at how we can set Git up on a Centos 5 box that is publically accessible. The reason I want this to be publically available is that I will be able to access all my git projects from anywhere. I can and still will implement access control through the use of a shared public key or password. In my case where a key is not available, it offers the fallback of using a password for access control. Setting up git will therefore require ssh to be installed. This is something that in all likely hood is already installed on your webserver.
Setting up git on my CentOS 5.9 server required the following steps:
1. Install 'Extra Packages for Enterprise Linux'. These are required in order to install git using a package manager such as yum.
yum install git-core
useradd <username> passwd <username>
Enter password for users without a key
Enter password when prompted
Re-enter when prompted
scp ~/.ssh/id_rsa.pub firstname.lastname@example.org:[port]/home/git/.ssh/authorized_keys
sudo chown -R <username>:<username> /home/<username>/.ssh sudo chmod 700 !$ sudo chmod 600 /home/<username>/.ssh/*
Now you’ll be able to authenticate as the Git user via SSH. Test it out:
ssh -p  <username>@gitserver.com
git clone ssh://<username>@domain.com:<port>/<project name>
However this does not always seem to work for some reason. In my case I was able to configure ssh to connect to git for a specified host on a different port:
Add the following lines to your ~/.ssh/config:
Host myrepo User <username> Port <port number>Hostname <hostname.com>
6. Adjust firewall settings. I understand git use port 9418. Make sure that this is reachable through your firewall.
7. Finally you get to actually start using git. Lets start by logging into remotely and setting up your new repository.
If using the Git user, log in as them via ssh. Now we can create our repositories:
mkdir myrepo.git cd myrepo.git git --bare init
The last steps creates an empty repository. We’re assuming you already have a local repository that you just want to push to a remote server.
Don't forget to change your file pemissions to allow git to read and write.
sudo chmod -r <username>:<username> my_new_project.git
Repeat for each remote Git repository you want to setup.
set up local build
git remote add origin <username>@server.com:myrepo.git git push origin master
Additionaly if you have problems setting up this way you can also try git clone. In fact clone is also useful if you simply want to clone your environment at any time. For my purposes it is also useful for copying my code across to my webserver:
git clone ssh://<username>@mygitserver:portnumber/~/my_project.git .
I simply enter my git password that I set up earlier when prompted and then make sure that my file pemissions are correct and we are then ready to go.
For more detailed info on using git please see http://git-scm.com/book