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:
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.
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:
Download and install GIT for your OS
Create a new GIT repository based on the url of your SVN repository:
git svn init git-repo
Go into the just created git-repo folder and download the source
git svn fetch
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:
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:
Assuming '/var/git/' as the central repository place, make a new repository 'project-X'
git --bare init
Enable the post-update hook (needed to update the server info, DO NOT FORGET!)
mv post-update.sample post-update
chmod +x post-update
Do an initial server info update
sudo -u apache git update-server-info
Check the access rights (apache should have read and write access)
Configure the apache virtual host
Options ExecCGI FollowSymLinks Indexes
# Deny everyything here
Deny from all
AuthName "git repository"
Allow from all
Require group project-X-read
Require group project-X-write
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:
Install git for your OS
Because our repository is protected, we need to create an entry in our $HOME/.netrc file:
After the initial installation, there two ways of getting files in the central repository:
Add the files to your local repository and push your repository to the central repository
Clone the central repository
To add locally and push, take the following steps:
Create local repository
Add files and commit them to the repository
git add .
git commit –m “My initial commit message”
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.
git clone http://git.yourdomain.com/project-X
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.
The start of a project at Triquanta consists of these steps:
Create the Drupal code base using our custom makefile
Setup a new Drupal site locally based on the Triquanta installation profile
Create a new (bare) central git repository for the project
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
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
The fun url for this post: http://xkcd.com/624/