Software deployment with Git and SVN via SSH

Since the launch of the SSH access to our Linux shared hosting environment, you have the Git and SVN binaries at your disposal. Not only do they allow you to perform version control, but they also allow to pull data. In other words, you can deploy from a source control repository.

If you work using tags and branches, you can send a specific version of your software to our environment. And you can do this even if you are still in the midst of developing your application in another branch of your repository.

There are two possible strategies you can use:

• Export the data of your branch so only the files on your package are stored
• Extract the branch of your project and thus also store server and revision information

Subversion

Subversion, also known as SVN, is a very traditional way of performing version control. The basic strategy is that there is a single central server where all the code is stored in its different versions. All deployment is performed from that central server. In the meantime, Subversion has become an Apache top-level project. On the official website, you can read more on the way SVN works.

We only provide an SVN client on our environment, not a server. The idea is that you connect with your Subversion server from our hosting.

Examples:

To export an SVN branch to your package, you can e.g. use the following command:

svn export http://your.svn.server/repo/trunk/ .

The abovementioned command will connect to your SVN server (which runs on “your.svn.server”) and address the repository “repo”. In this case, the “trunk” branch of this repository is pulled.

You can also extract a branch. This is how you do it:

svn co http://your.svn.server/repo/trunk/ .

The files of this branch will also end up on your package, but a “.svn” map will also be created in order to store the revision information. Via an “svn up” command, you can pull possible changes automatically. Besides, you can also send back changes via the “svn commit” command.

Git

Even though Git is quite old and used to be mostly used as a version control tool for maintenance of the Linux kernel, it has currently become a standard. As opposed to Subversion, there can be more than one server involved with Git. Git works in a distributed manner and repositories can be synchronized in both directions. You can find more information on how this works on the official website of Git.

You can also create a new Git repository on your package and store possible changes, which you can synchronize with other repositories. Despite the fact that this is an interesting way to work, we use a pull strategy for deployments rather than a push strategy.

Examples:

To pull a Git repository, you can use the following command:

git clone --depth=1 git://github.com/username/repo.git .

The abovementioned command will establish a connection with your Git server (in this case, github.com) and address the repository “repo”. This repository runs within your account, here represented by “username”.

The “Git clone” command is the equivalent of “svn co”. In other words: information on versions is also retrieved and stored in the “.git” folder. This way, you can contribute to this repository and forward modifications.

If you want to limit yourself to exporting data, you can remove the “.git” folder after the “git clone”. This is how you do it:

rm –rf .git

If you want to kill two birds with one stone, you can combine both commands as follows:

git clone --depth=1 git://github.com/username/repo.git . && rm –rf .git

The “--depth=1” parameter limits the amount of version information retrieved. If you do not want to limit this, then do not use this parameter.