将本地Git存储库与主Subversion存储库一起使用

Question

I have heard that it is possible to have a local Git repository on a developer machine, while keeping a master copy of the source code stored in a svn repository.

A good use case would be that you have a central svn repository that each developer works with. One developer goes offline occasionally and would like to track changes he/she makes while offline. When the developer is back online and has access to svn, their working copy modifications could be checked into svn. I'm fine with losing the history of changes that happened locally with Git, when the files are checked into svn.

Can someone outline how best to pull this off? Are there any pitfalls to working like this?

Answer 1

You could use something like this tutorial as a starting point. I also read this tutorial .

There are several pitfalls to this mode of working. The most important one is that you cannot be using svn version 1.5 mergeinfo and expect this to survive through git. This is a major drawback if you're using the (arguably fairly decent) svn 1.5 merge functionality.

The man page for git-svn also contains some notes under the "caveats" that section that you should understand. Once I understood all the caveats I understood the benefits of using this setup to be less than the actual cost for my specific case. So I used my energy to convince the project to switch to git instead, something I just succeded in.

Answer 2

Say your SVN repo is at svn+ssh://username@svn_server/svn/your_repo
and your SVN repository has a "proper" layout (trunk, branches, tags) Here's workflow I've been using for few months now:
1. ' mkdir your_repo '
2. ' cd your_repo '
3. ' git svn clone -s svn+ssh://username@svn_server/svn/your_repo . ' (mind the dot)
4. [wait a while depending on the size of your repository :)]
now your GIT 'master' tracks the SVN trunk
you can also make a tracking branch like you'd normally do with git if you're working on some branch
5. the traditional hack hack hack
6. update your clone with ' git svn fetch && git svn rebase '
7. "push" your changes to svn with ' git svn dcommit '

More good stuff
Define following handy aliases in your .gitconfig:
1. Alias ' spull ' which stands for svn-pull like this: ' spull = !git svn fetch && git svn rebase '
2. Alias ' spush ' which stands for svn-push like this: ' spush = !git svn dcommit '
These aliases turn the workflow in to pure effectiveness: clone / hack hack / spull / spush -> profit

svn:externals
I couldn't find a good solution for this in the internet, so made one myself :)
http://github.com/sushdm/git_svn_externals it's not yet perfect, but it should definetely make life a lot easier.

Works for me perfectly well, hope it helps you.

Answer 3

One solution I would try is:

1. Checkout from central repo using SVN
2. git init to create local repo
3. add .svn to .gitignore
4. git add * to add all files to local repo
5. Do all your intermediate branches/commits/reverts in git.
6. When you're done, commit back to the central repo using SVN.

Answer 4

I think the better use case for git-svn is if you are forced to work with a central svn repository, but you would like to personally work with git. Or perhaps most people on the team feel more comfortable working with svn at the moment. Using git-svn you will not lose the history of commits made in the local git repository.

If you are setting up a new repository from scratch and / or have the freedom to choose, I would choose one or the other. git-svn works well but you will always be fighting the 'impedance mis-match' between the two systems.

If it is simply a centralized model you are looking to implement then a public git repository could be used as a central repository. See the Git User's Manual section on setting up a shared repository .