My git-svn workflow

I recently gave a lightning talk on git-svn at Barcamp Manila, and I thought some people might be interested in my day-to-day workflow when I work on projects.

When I get started on a project here at work, I usually first do a clone of the upstream tree, whatever that might be. I run:

git-svn clone --stdlayout https://svn.orangeandbronze.com/project

which checks out a copy of the SVN repository of project; this might take a while, so I usually go out for coffee or move on to other tasks while it completes. Sometimes, however, I don't want the whole history, so I do a partial clone:

git-svn clone --stdlayout -r HEAD https://svn.orangeandbronze.com/project

This then does only a checkout of HEAD, without history.

When I begin work for the day, I cd to the project's directory in a terminal, and do a status check to see what I've been up to recently, just to refresh my memory:

git status
git diff HEAD | less
git log | less

This gives me a) the status of my current work tree and the branch I'm working on, b) the changes since the last git commit I made, and c) notes from the log history. Sometimes, I'll be lazy and just pull up gitk for the tree, since it gives me pretty much everything above:

gitk --all

The gitk(1) command above allows me to visualize the commit history of the project, which is a boon when trying to nail down when something changed.

Once I know where I am on the tree, so to speak, I do a checkout of master, and I pull any changes from upstream SVN:

git checkout master
git-svn rebase

I usually checkout a branch when working on a particular feature or item. If I'm starting work on that feature, I do:

git checkout -b feature-name

However, usually I have already started on something, and I want to go back to that branch:

git checkout feature-name

This allows me to sandbox different work (bugfixes vs. features). I avoid touching the master branch, and instead work in other branches. Note that these branches are not visible on the SVN side; they're local to my git tree.

If master has changed (i.e. I've pulled in new changes from upstream SVN), I usually want to rebase my work on top of that:

git rebase master

I then bang on the code, making frequent commits for every small atomic unit of work completed. Once done, I review the code (in gitk(1) or by checking the git logs), and see what needs to be pushed. I also take this time to edit the commit history (which I'll explain in another post). When I'm ready to push upstream, I do another pull from upstream SVN (just so I'm sure my code is built on top of HEAD), and rebase. I also run unit tests to make sure I didn't break anything. When I now know everything's peachy and ready to be published, I do a push to upstream SVN via dcommit:

run tests...
git-svn dcommit
git checkout master
git rebase remotes/trunk

The last two lines simply fast-forward master to whatever the current SVN HEAD is. At this point in time, I'm ready to work on another task/feature/bugfix.

Previously: Source Available: My hacks to fsp-h