My git-svn workflow with Tower

Most of the codebases I work on are in Subversion, yet I like working with Git for the sheer joy of it. Below, you will find a short overview of my basic workflow. I do a lot from the command line, but not everything. For most operations Mac Git client Tower is the best solution you can find.

In short

For the impatient reader, my workflow looks a little like this.

  • One time only: clone repository. git svn clone http://host.com/repository -Ttrunk -bbranches -ttags mylocalcopy
  • Rebase: get all remote changes in. git stash; git svn rebase; git stash pop
  • Create awesome features, committing frequently with Tower.
  • DCommit: push changes back to Subversion. git stash; git svn dcommit; git stash pop

In a little more detail

Checking out

Git works with a local history, which makes it quite distinct from Subversion. Also, Git assumes that you have a working trunk, with optional branches and tags; this means your repository should at least have a trunk directory.

Assuming your trunk is at http://host.com/repository, you can clone a remote Subversion repository to your system using git svn clone http://host.com/repository -Ttrunk -bbranches -ttags mylocalcopy

This will copy over all revisions of the repository to your own system, placing a Git repository in your mylocalcopy directory. Since it goes through all revisions, this can take a while for repositories with a lot of commits. If Git somehow stops, and your local copy is still empty, go into the local repository directory, and execute git svn fetch.

Updating and committing

With your local working copy, you can use Tower to create your commits.

If your want to merge your copy with the remote Subversion repository, it's best to only do that after you have (locally) committed all changes. Then, use git svn rebase If you need to have some local uncommitted changes, use git stash; git svn rebase; git stash pop

Pushing your changes to the remote Subversion repository is roughly like rebasing. Again, it's best to only do that with a 'clean working copy', that is, having committed all changes to your own Git repository. git svn dcommit Again, if you must, you can pad this command with git stash and git stash pop.

Remember that, when you commit, all your commits will get the timestamp of the dcommit.

How do I use Git with Subversion?

I have noticed that in Git, there are at least six ways to do anything you want. I have settled on a simplified way of doing things, and I know I am missing out on some awesomeness.

  • I rarely use feature branches. I only use them when I am really working on two things at the same time, but not for every feature that comes along.
  • When I do use feature branches, I tend to dcommit from the feature branch, instead of merging to my trunk first.
  • Intellij's Git integration is pretty good, and it works together nicely with external tools. In Eclipse, I don't use any integration, but rely on command line tools and Tower only.
  • For Eclipse-based projects, I use Git to keep track of the full working directory, instead of tracking individual Eclipse projects. This usually means that I clone some repository at the level above the Eclipse projects, and import the projects into Eclipse using the 'Import existing project' feature.