From subversion to git

Why

At Triquanta we are preparing the transition from subversion to git. We choose git first of all because Drupal is changing to git as well. But the main reason is that we wanted to be able to branch more easily and that we wanted a decentralized system. All the benefits and a comparison with subversion are explained in the following link:

https://git.wiki.kernel.org/index.php/GitSvnComparison

About git

If you want to use git, it's important that you understand the basics of git. Instead of explaining this in this blog post, it's better to refer to sources that do a great job in explaining the concepts. The git documentation page is a good starting point. I like the 'git tutorial talk', although it's quite long (2 hours): http://git-scm.com/documentation.

How

Using git with a subversion repository

If you use subversion, a good way to start using git is to use git for subversion. With git-svn it is possible to create a local git repository based on a subversion repository. Locally you can have the benefits of git, and you can still commit your updates to the subversion repository.

A good starting point in using git-svn can be found in a blog post: http://www.xavena.eu/goodbye-svn-ill-git-you.

Using git for svn takes roughly the following steps:

  1. Download and install GIT for your OS

  2. Create a new GIT repository based on the url of your SVN repository:

git svn init git-repo

  1. Go into the just created git-repo folder and download the source

git svn fetch 

  1. Take notice of the fact that the previous command fetches all revisions and that for each revision a duplicate file is created. More info about this issue can be found in the previously mentioned link. These duplicate files should be removed:

git repack

Setup a central repository with apache

The next step in incorporating git in the work process is to switch the central repository to git. At Triquanta we use subversion in combination with apache. We wanted the same mechanism for git. The actual setup of git sharing via http we used is described by Patrick Debois in his blog post on sharing the git repository: http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git-repository/#apachehttp.

If you want to share the repository in a different way, this blog post is very usefull as well.

To make the transition to git even more seemless, we use the subversion authfile for authentication, so all users which have access to subversion will automatically have access to git as well.

Although the steps to take are well described in the Blog post of Patrich Debois, I will give a summary here.

On the server level, perform the folowing steps:

  1. Assuming '/var/git/' as the central repository place, make a new repository 'project-X'

cd /var/git

mkdir project-X

cd project-X

git --bare init

  1. Enable the post-update hook (needed to update the server info, DO NOT FORGET!)

cd /var/git/project-X/hooks

mv post-update.sample post-update

chmod +x post-update

  1. Do an initial server info update

cd /var/git/project-X

sudo -u apache git update-server-info 

  1. Check the access rights (apache should have read and write access)

  2. Configure the apache virtual host


ServerName git.yourdomain.com
DocumentRoot /var/git

DAV On
Options ExecCGI FollowSymLinks Indexes
# Deny everyything here
Deny from all
AuthType Basic
AuthName "git repository"
AuthUserFile
AuthGroupFile /var/git/htgroup.git


Allow from all
Order allow,deny

Require group project-X-read


Require group project-X-write

 

  1. In case of problems, check the original blog post where number of possible errors are explained.

Install and configure git on working stations

Installing git on the workstations of every team member is pretty straightforward. For windows and mac this consist of downloading and running the installer from http://git-scm.com/. For linux install is easy using yum or apt-get (yum install git / apt-get install git-core), or installing it by means of the software center.

After git is installed, some configuration has to be done to start a new git repository and connect it to the central repository. A simple blog post about setting up both the central repository and the local repository can be found on a blog post by Jamie Hill: http://thelucid.com/2008/12/02/git-setting-up-a-remote-repository-and-doing-an-initial-push/.

The steps to take in case of using git with apache:

  1. Install git for your OS

  2. Because our repository is protected, we need to create an entry in our $HOME/.netrc file:

vi $HOME/.netrc
machine git.yourdomain.com
login
password

After the initial installation, there two ways of getting files in the central repository:

  1. Add the files to your local repository and push your repository to the central repository

  2. Clone the central repository

To add locally and push, take the following steps:

  1. Create local repository

mkdir project-X

cd project-X

git init 

  1. Add files and commit them to the repository

cd project-X

git add .

git commit –m “My initial commit message” 

  1. Add the central repository to the local repository

git remote add origin http://git.yourdomain.com/project-X

git push origin master

Cloning the central repository is maybe easier, but if you want to create a repository and push it later, cloning will not work.

cd working-directory

git clone http://git.yourdomain.com/project-X

Workflow

Once git is installed on all workstations and there is a central repository, a workflow has to be defined. This workflow consists of guidelines when to branch, what to commit to the central repository and what to release.

Project creation

The start of a project at Triquanta consists of these steps:

  1. Create the Drupal code base using our custom makefile

  2. Setup a new Drupal site locally based on the Triquanta installation profile

  3. Create a new (bare) central git repository for the project

  4. Push the local repository to the central repository

Project development and release

After the new project is created, we adhere strictly to a well described git workflow. Because we were new to git, we decided not to invent a workflow ourself, but instead use an already proven workflow and make tiny adjustments when needed.

We used the workflow Vincent Driessen describes in his blog post: http://nvie.com/posts/a-successful-git-branching-model/.

The main point in this workflow is to use 5 branch types:

  • 1 Master branch

  • 1 Develop branch

  • Release branches

  • Feature branches

  • Hotfix branches

These branches can be mapped on a DTAP (Development, Test, Acceptance, Production) environment:

  • Master branch (tagged): Production

  • Release and hotfix branches: Acceptance

  • Develop branch: Test

  • Feature branches: Development

Fun url

The fun url for this post: http://xkcd.com/624/