关于使用git-svn repo的团队的工作流程的问题

Question

I've bee reading up on git and git-svn. I'm pretty new to git but I've been able to create some basic repos. However, I'm a bit confused on how the workflow would go for git-svn being used by a team. The goal is to convert svn to git for branching and sharing purposes, then commit back to the main svn repo when ready to push to production. Here are my questions:

Should each member of the team create a git repo from the svn repo? Would this approach work when merging back to svn / pulling from each other?

-or-

Should one git repo be created from svn, then that repo is pushed 'publicly' for team members to clone? Then would changes be pulled back to the original git repo for rebasing and pushing to svn?

-or-

Can we do the same as above except just pull changes from each other's working copy repo?

-or-

Am I adding too much complexity to the workflow and should just keep using svn, since it's not an option to just convert entirely to git?

Answer 1

Do developers ever have the need of a local repo while not being able to connect to the main repo? (ie: Coding on a plane on a laptop)

If no, then I'd avoid this headache altogether and just use SVN with dev-specific branches.

If however, you'd really like the distributed approach of git, I would go with your third option:

Should one git repo be created from svn, then that repo is pushed 'publicly' for team members to clone? Then would changes be pulled back to the original git repo for rebasing and pushing to svn?

With:

Can we do the same as above except just pull changes from each other's working copy repo?

That should work fine.

Answer 2

I do something along these lines all the time. Here, we've got an svn repository, but several people would rather use git. We just had one person create the git respository, and then we all shared that amongst ourselves (rather than everyone creating his own git-svn copy - the original import took over 30 hours). Now anybody who wants to can just work in git and git svn dcommit to push their changes back to the "real" svn repository.

Answer 3

Think of each user's git repository as a fancy Subversion client, particularly as one with which it's easy to share revisions without involving the central repository. Then everyone should do what seems best and right to them.

You could also think of the Subversion repository as a fancy git repository.

Should one git repo be created from svn, then that repo is pushed 'publicly' for team members to clone? Then would changes be pulled back to the original git repo for rebasing and pushing to svn?

I don't think that's necessary, because git svn clone works mostly the same as git clone to begin with.

The most important thing to do is to always do git svn rebase before doing git svn dcommit . If you're doing a lot of revision sharing between git repositories, it is probably a good idea to examine the changes you're going to push to Subversion before doing that git svn dcommit .

Answer 4

Git-svn easily supports what you want to do. I would recommend that each developer creates their own Git repository from the Subversion repository ( git svn clone ). Developers can pull from each other if they like, including both commits that have already been pushed up to Subversion and ones that have not.

The git-svn equivalent of svn update is git svn rebase , which effectively does a git rebase operation against the Subversion repository. Any commmits you might have ready to commit, that have already been committed by somebody else, are automatically skipped.