From Git SCM Wiki
Revision as of 10:39, 29 December 2012 by ThurnerRupert (Talk | contribs)

Jump to: navigation, search


This tutorial collects information for users of git as subversion client, using git-svn. Please consider reading GitSvnCrashCourse, and the git-svn cheatsheet. As Git is distributed, commits (aka change sets) are referenced by hashes instead of svn's serial version numbers. Git tracks contents, not files or directories. Consider to use a real svn client to rename directories, as git-svn produces a lot of renames in svn, instead of one like the original. git-svn is not a good tool to convert from svn to git, see here for better options.


checkout / clone, log, configure basics

git svn clone -r 400:HEAD folder # choose a recent commit
git log -5
git status
git svn info
git config --list

Create a .gitignore file on the toplevel to replicate svn's ignore properties.

echo "folder/or/file/to/ignore" > .gitignore

Make sure to remove directories from the svn tree if there are no files left in it. This is important for a directory move to have no left-overs:

git config --global svn.rmdir=true


commit to local Git

Git automatically tracks contents and therefor automatically detects all changes done with file browsers, programming tools etc.

git diff
git add --all
git diff --cached
git commit -m "whatebber"

commit to remote SVN

To see what is going to be committed one can choose the following options.

gitk git-svn..
git log remotes/git-svn.. --oneline
git svn dcommit --dry-run

To really commit

git svn dcommit

undo changes

Undo (backout, revert) changes and commits is done with standard git commands.

Things already committed to svn can be reverted:

git revert <hash>
git svn dcommit

Things in the working tree can be reset (reverted) to what is checked in:

git reset --hard

Also, single files can be reset to a previous version. one caret means one version back:

git checkout HEAD^ -- singlefile
git commit --amend

basic workflow, check out, fix, check in to svn

git svn clone -r 400:HEAD
... hack, hack, hack ...
git add .
git commit -m "qick fix"
git dcommit

workflow with quickly setting away your main work and do a quick fix

git svn clone -r 400:HEAD
git checkout -b bugfix-id-123
... hack, hack, hack ...
git stash "main work, save it for the moment"
git stash list
... hack on quick fix ...
git commit -m "qick fix"
git dcommit
git stash pop
... continue hack, hack, hack ...

workflow with local fix/feature branch

git svn clone
git checkout -b bugfix-id-123
<hack, hack, hack>
git add --all
git commit -m "fixed issue 123"
git checkout master
git svn rebase
git merge bugfix-id-123
git svn dcommit


How to use git branches with git svn

git-svn(1) allows you to use git as an interface to a Subversion repository. However, there are a number of caveats when doing this because Subversion's branching model is less powerful. git-merge(1) should not be used on the branch you intend to git svn dcommit from because the merge object cannot be expressed in a useful form to the Subversion repository when committing. This essentially makes it impossible to usefully use git branches for local development - yet the branching/merging mechanism is one of the most powerful features that git provides.

There are two ways to get around the git merge problem and so be able to use git branches for (local) development. For the following, assume you've branched and the commit genealogy looks like:

     C--E--F branch
A--B--D master

The first merge solution is to replicate the changes you made on your branch to master using git-cherry-pick(1) (or alternatively git-format-patch(1) and git-am(1)). However, it can be rather laborious determining the list of required commits (C,E,F) and iteratively re-applying them to master (C', E', F').

     C--E--F branch
A--B--D--C'--E'--F' master

Whilst this does allow you to develop multiple projects simultaneously and independently, this work-around isn't much friendlier than just working directly on master in the first place.

The second solution takes advantage of git-rebase(1) and git-branch(1). When you want to merge your changes back to master you rebase your branch with respect to master HEAD (i.e. what the Subversion repository looks like):

git checkout <branch>
git rebase master

Your branch now looks like master plus the extra changes you made on the branch:

        C"--E"--F" branch
A--B--D master

In fact, it's what you'd ideally like to git svn dcommit now (or later) but it's stuck on the wrong branch. So now we tell git that we'd like to pretend that the branching never happened and that branch is what master should really look like:

git branch -M master

The -M specifies that we want to do a forced rename of the branch (forced because master already exists):

A--B--D--C"--E"--F" master

Note that this destroys the development branch in the process* so this should only be done when you've finished development on the branch. However, there's nothing stopping you from re-branching again:

git checkout -b <branch>
                   o branch
A--B--D--C"--E"--F" master
  • Technically we destroyed the old master branch but since branch can no longer be referred to by name it appears as though that is the object that was destroyed.

An Alternate Method Using `git-svn rebase`

If you have a branch like above, you can often perform a git-svn rebase on the branch directly. Instead of rebasing to master, this rebases the branch directly onto the latest remote revision in subversion. Then you can git-svn dcommit in the branch. Finally, check out master and do another git-svn rebase to bring it up to date. This will merge in the changes from the branch as well as any new changes in subversion. Note that with this method, the branch sticks around, but afterwards gitk will show that it marks the same history as master -- until you commit to it again or delete it, anyway.

Some links

Personal tools