mercredi 11 janvier 2012

Compiled info : how to use Git as a Subversion client

Initial info from http://www.viget.com/extend/effectively-using-git-with-subversion/
Clinton R. Nixon, Former Staffer, April 18, 20089
Like many organizations using Rails, we have caught the git wave, and are in a state of transition between git and SubversionOur open-source work is stored in git repositories, but our client work is still stored in Subversion repositories, and probably will be for some time. While git is amazing, Subversion still has its good qualities, and makes an excellent centralized repository, especially with its ecosystem of user-friendly tools.
The integration between git and Subversion (git-svn) is so well done that several of us have been using git as our interface to all our Subversion repositories. Doing this is fairly simple, but there are some interesting tricks, and so I thought I would share a day in the Viget life with git-svn.

GETTING YOUR REPOSITORY SET UP

Checking out a Subversion repository is as simple as can be:
git svn clone -s http://example.com/my_subversion_repo local_dir
The -s is there to signify that my Subversion repository has a standard layout (trunk/branches/, and tags/.) If your repository doesn’t have a standard layout, you can leave that off.
As you would expect, this leaves you with a git repository under local_dir. It should map to the trunk of your Subversion repository, with a few exceptions. First, any empty directories under Subversion won’t show up here: git doesn’t track empty directories, as it tracks file contents, not files themselves. Also, files you were ignoring via svn:ignore are not ignored in this git repository. To ignore them again, run the following command in the root of your repository:
git svn show-ignore > .gitignore 
You may see this same command as git-svn show-ignore >> .git/info/exclude elsewhere, and that is a valid way to get the same outcome. The difference is that with the former method, you are adding a file in your repository that you can then track. Even though we will be committing back to Subversion, I like tracking .gitignore. As you may have noticed, running git-svn show-ignore is slow, and by committing .gitignore back to the repository, others using git-svn won’t have to run this again.

MAKING BRANCHES

One of the best reasons to use git is its lightweight local branches. These are not the same as Subversion branches: they reside locally and can be created, destroyed, and merged easily. When working on a project, you’ll probably want to create a branch every time you work on a new feature. It’s very simple to do so: run the command git branch new_branch_name master. “master” is the branch you are forking off a new branch from. If you want to fork from the current branch, you don’t have to say so. You can just as easily type git branch new_branch_name. To move to this new branch, you run git checkout new_branch_name. To make things easier, all of these steps can be combined, like so:
git checkout -b new_branch_name [old_branch_name] 
Again, you do not have to include the old branch name if you do not want to.
To see all the branches in your repository, you can execute git branch. You might wonder why your Subversion branches do not show up. They exist as remote branches, not local branches, but you can still get to them. Execute git branch -a to see local and remote branches, which should show you your Subversion branches and tags.

 

UPDATING FROM AND COMMITTING BACK TO SUBVERSION

Before committing back to Subversion, you will want to update to apply any new changes in the repository to your local Git repo.
git svn rebase 
This will download all new changesets from Subversion, apply them to the last checkout from Subversion, and then re-apply your local changes on top of that.
When you’re ready to commit back to Subversion, execute:
git svn dcommit 

There are a lot more commands and options in git to learn, but these should be sufficient for most day-to-day usage of git as a front-end to your Subversion repository. After using it for the last month, I cannot imagine going back.

USING REMOTE BRANCHES



25
down voteaccepted
Muchas gracias to Bart's Blog for this handy reference for svn branches in git. Apparently all I needed was to specify a remote branch when creating the git branch, e.g.,
git checkout -b git-topic-branch-foo foo
where foo is the name of the remote branch.