Setting up Git on CentOS 5 server

I’m currently setting up Git for our company. The reason is that Git is better than X. This post is all about how to get Git setup on CentOS 5. There are other posts on this topic, of course, but this one is better!

• Two minute intro to Git
• Installing Git on CentOS 5
• Creating and sharing a repository
• Tortoise; the familiar client for Windows
• Git hub
• Finding out more – useful links

Two minute intro to Git

I’ve come from an SVN background; you checkout a copy of a central repository, make some changes and commit. Git is a slightly different beast in that it is a distributed Source Control Management system. What this means is that you have your own local repository where you can happily commit changes (whether online or offline). To share your changes with others, you can then push your changes to another repository (either their repository or some central repository if you’d prefer). Similarly, to work on someone else’s code, you can create your own cloned version of their repository and then pull updates as required.

The reason I’m switching to Git is all about branching – I find this a real pain in SVN. If you’re not convinced you can click here to find out Git is better than your current SCM.

Installing Git on CentOS 5

Installing Git on CentOS 5 is easy if you make use of the EPEL (Extra Packages for Enterprise Linux) repository. You’ll know if you’ve got this installed if the following fails:

yum install git

To setup EPEL all you need to do is create a file /etc/yum.repos.d/epel.repo and then paste in the following:

[epel]
name=Extra Packages for Enterprise Linux 5 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL

[epel-debuginfo]
name=Extra Packages for Enterprise Linux 5 - $basearch - Debug
#baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch/debug
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-debug-5&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL
gpgcheck=1

[epel-source]
name=Extra Packages for Enterprise Linux 5 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/5/SRPMS
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-source-5&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL
gpgcheck=1

Now you can install using:

yum install git git-daemon

Creating and sharing a repository

Creating a repository is easy! Simply create a folder and type git init.

mkdir newrepo
cd newrepo
git init

Once created, we can copy/create our files (think svn import) and then do:

git add .
git commit

Once you’ve created a repository, you’ll probably want to share it. This means that other people can pull and push changes. There are a number of ways of accomplishing this (this blog post lists 8 possibilities). My usual method for sharing SVN repositories is via Apache; Git supports this as well. I think one of the simplest solutions is to use the Git Deamon. To allow others to pull and push you can share your Git repository using the following command:

git daemon --reuseaddr --base-path=/path/to/repos --export-all --verbose --enable=receive-pack

This command will share all repositories found within the folder /path/to/repos (so we would have created our “newrepo” folder within this location). Once shared you can clone the repository using the git resource locator syntax:

git clone git://remote.computer.hostname/newrepo

Or you can just use the IP address if you’d prefer.

You should now have a repository setup on a CentOS 5 server which you can clone and then pull/push updates.

Tortoise; the familiar client for Windows

When I’ve used Mercurial in the past (another distributed SCM), I’ve actually found the command line tools significantly easier to use than the GUI (Tortoise). However there is a level of familiarity that a TortoiseSVN-like frontend provides.

TortoiseGit has all the features you’d be used to from using TortoiseSVN plus Pull, Push and all the other Git-specific stuff.

Git hub

It’s worth making a quick mention of Git Hub. According to the website, “GitHub is the easiest (and prettiest) way to participate in that collaboration: fork projects, send pull requests, monitor development, all with ease.”.

Git Hub provides a handy way of visualising a Git project (listing commits, branches and pretty-printed code). It avoids the need to setup your own central Git repository and mess about setting the server up. A lot of projects seem to be moving this way, for example Symfony.

Finding out more – useful links

http://whygitisbetterthanx.com/

Some well thought out and concise arguments as to why Git is better than other SCM systems.

http://gitready.com/

Excellent site – “learn git one commit at a time”. Lots of help and advice clearly laid out.

http://git.or.cz/course/svn.html

Crash course for SVN users – really good comparison of SVN commands and the equivalent GIT commands.

http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git-repository/

8 ways to share your git repository – file share, Git daemon, plain SSH server, SSH server git-shell, Gitosis, Apache http + gitweb, github.

Tags: git, github, scm, svn

This entry was posted on Friday, January 29th, 2010 at 4:42 pm and is filed under Architecture. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.