Git, the version control system, has a subversion integration feature. In short, it allows you to use git to interact with a subversion repository: check out and commit code back to subversion.
It sounds like an excellent feature. My first thought was that I’ll be able to make a subversion checkout on one host, and use git to propagate my changes throughout all other host I work on. Finally, I thought I’d be able to merge changes back to where I did the subversion checkout, and commit my changes back to subversion.
However, there’s a problem with using multiple repositories, git merge and git svn. The most common way to move changes between git repositories is git push and git pull. In short, it does git fetch, and git merge (plus a bit of magic I’m not sure about). If you use git pull/push and try to commit back to subversion, you will sooner or later fall into the trap that I fell into some time ago. I’ve since worked out a relatively sane workflow which allows me to work with code on multiple hosts and send changes back to subversion with no horrible recurring code conflicts.
The executive summary is: Use “git fetch; git rebase origin/master” to propagate changes and format-patch + “git am” to propagate changes back to your root git repository (the one that was used to make the svn checkout).
host1> git svn clone http://example.com/foo foo
host2> git clone ssh://host:/home/joe/foo
host2> cd foo; edit files…
host2> git stage -p
host2> git commit
host2> git format-patch origin/master
host2> scp *.patch host1:
host1> cd foo
host1> git am ~/*.patch
host1> git svn dcommit
host1> some more work, commits, code incoming from subversion…
host1> git svn rebase
host2> cd foo
host2> git fetch
host2> git rebase origin/master
In this workflow, git pull and push are not used.
host1 → host2 [git rebase origin/master]
host2 → host1 [git format-patch; scp; git am]
You need to take care if you’re using things such as “git commit –amend” on host1 on commits that have been first made on another host (e.g. host2). Otherwise, this workflow does not create any recurring conflicts.
A side note: it’s perfectly safe to branch and merge within one git repository. The workflow described above deals with the problem of moving changes across multiple git repositories.