====== Integration with Subversion ======

I also use Git as a front-end to SVN repositories. At the most basic level, using Git as a front-end to SVN involves:

<code>
git svn clone http://svn.repo.com/svn/project/trunk project
</code>

To get updates from SVN:
<code>
git svn rebase
</code>

To push changes to SVN:
<code>
git svn dcommit
</code>

You should **ALWAYS** update from SVN or pushing changes back to SVN will fail.

==== Typical Work Flow ====

However, if that was all there was to it, there would be no reason to use Git instead of Subversion. I think that the best part of Git branching and merging. You can create as many local branches as you like with ''git branch branch_name'' or ''git checkout -b branch_name''. You can code within these local branches as much as you want and you can merge one or more of them together. I recommend that you never "work" in the master branch other than to sync your repository with remote repositories.

One thing that you always need to do prior to merging branches into the master branch is to rebase your master branch. Rebase means to replay the commits of the named branch on top of the branch that your are currently in. It creates new commits that while they contain the same content, each commit has a different SHA1.

<code lang=bash>
(master)$ git svn rebase
(master)$ git checkout -b bug81
code, code, code, ... done
(bug81)$ git checkout master
(master)$ git svn rebase        # Always rebase from SVN...
(master)$ git checkout bug81
(bug81)$ git rebase master      # Rebase changes from SVN to the bug81 branch
(bug81)$ git checkout master
(master)$ git merge --ff bug81  # Merge changes that "originated" in the bug81 branch
(master)$ git svn dcommit       # Send changes to SVN...
(master)$ git branch -D bug81   # delete the branch it is not needed anymore (Optional)
</code>