This tutorial collects information for users of git as subversion client, using git-svn. 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.
Create a .gitignore file on the toplevel to replicate svn's ignore properties.
Git automatically tracks contents and therefor automatically detects all changes done with file browsers, programming tools etc.
To see what is going to be committed one can choose the following options.
gitk git-svn..
Undo (backout, revert) changes and commits is done with standard git commands.
... hack, hack, hack ...
... hack, hack, hack ...
... hack on quick fix ...
... continue hack, hack, hack ...
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.
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').
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.
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.
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.
An introduction to git-svn for Subversion/SVK users and deserters by Sam Vilain describes how to import from and work with Subversion repositories and SVK mirrors. Also describes why would one want to choose Git over Subversion.
git(-svn) in 30 minutes on mikas blog, not only about git-svn.
