As it stands, Git seems to be taking over the world of code repositories, especially in open source. And why wouldn’t it? It’s a fantastic tool to work on projects collaboratively and remotely. But there are some cases where the very nature of Git’s “everyone has a repo” can be a downside. You lose certain features you used to have when dealing with Subversion (or to a lesser extent CVS)
But thankfully, Git and SVN can work together as a “power couple” of code management. You gain the remote nature of git, local commits and the ability to edit the past but maintain pre/post commit hooks and maintain a central repository to better manage your code.
Now some people can argue that anything done with SVN you can do with Git, and that might be true. But the means in which you do so or the complexity might be vastly different. For instance, we have very expansive post and pre commit hooks which perform tasks on all commits to our repository. Some of those hooks wouldn’t work properly in Git, for example, due to the capacity to edit commits in the past. The sequential nature of SVN and the finality of a commit is an important part of our workflows.
But enough of that. Let’s get into using git and svn together.
Git works on the basis of “cloning” repositories. When you checkout from a Git repo, you’re actually getting your own copy of the entire repository, all the commits, everything. You can then commit to your own local repository with changes. Once your code is ready to be shared with the original repository, you “push” your commits back up.
This is different from subversion. All your commits are done against the original repository. When you checkout code, you get a snapshot of the code as it currently exists at that particular revision.
Checking out code from Subversion using Git
The syntax for “checking out” code from SVN using git is very simple. But you aren’t just checking out code. What git is doing is creating a new git repository on your machine, then it scans the SVN repository for all the commits your specified folder. Then it recreates the entire history of commits to the SVN server locally as git commits.
git svn clone repository_name
By default, git will create a folder locally named the same as the last entry in your <repository> location. For instance, if your repository location is “https://svn.coldfrontlabs.ca/projects/branches/7.x/modules/hsts-7.x-1.x” the folder will be called “hsts-7.x-1.x”
Now you have a new git repo with the latest code from your repo. You can start using it as any other git repository.
Commits and pushing changes back to SVN
Each commit you make to your local git repo will be reflected in the SVN repository when you decide to send all your changes back. Keep that in mind if you have any post-commit scripts that may block a commit. If you do, and a commit in the past is blocked, you won’t be able to commit any changes until you go back and fix your commit in git. I won’t get into that here, but if you Google around you should find out how (I may also post on how to do this in the future).
To push your changes back, you use the “dcommit” command
git svn dcommit
Getting updates from SVN
As you work locally, others may have committed changes to SVN. To get those updates, you can “rebase”. This happens automatically after you run “dcommit”. But you can trigger is manually if you want:
git svn rebase
That about does it, pretty simple isn’t it?