git workflow with main svn repository using git-svn

Question

I'm in a big team which uses SVN as the revision control.

I'm in a subgroup of the big team which try to use git for some integration test of the codes from this subgroup.

Following is what we want to do for dailay work.

1. A,B,C(people in the small group) do their coding work.
2. A,B,C check in the work to a git branch integration-test .
3. Rebase the latest change from SVN trunk to integration-test
4. Build image and do integration test.
5. Test pass, A,B,C check in their codes to 'SVN'
6. Goto step 1

The problem is: because our change has been committed into the git branch integration-test in step 2. and we committed the change to SVN in step 5. So, in step 3 of next round, the merge will have conflict for all the changes.

So, is there a good practice for this scenario?

Answer 1

A problem you will have is that git svn rebase actually rewrites the commit history of the git repository. This will cause conflicts with anyone pulling from that repo. The best solution is for everyone to git svn the svn repository on their own.

If you want to setup a remote repo so you can share branches, then everyone will just have to be aware that if the remote git branch is rebased to svn, they will have to force apply the new revision history to their local git repos.

Others can force their local repos to match the remote by using git pull --force . Though be warned, because that will invalidate any commits made after the alteration point. Example, say we have the following commit structure:

D----E  topic
      /
A----B----C----F  master

Then we use git pull --force to update our local repository, which then changes the sha1 of the commits starting at B . Our new structure will look like the following:

D----E  topic

A----G----H----I  master

Notice how commits D and E are now floating in wonder land? That's because the branch point now no longer matches up with what was B , but is now G .

To get around this problem you need to make sure that your local branch point originates from a commit that won't be altered by running git svn rebase . After force pulling the remote you can then git rebase your local branch onto update remote branch.

Say we make the mistake of creating a branch from a commit point that will result in the floating wonderland described above. Well, then you'll have to wave the git wonder wand before you initiate a git pull --force . Like so:

Oops. B is going to be overwritten in the pull .

D----E  topic
      /
A----B----C----F  master

Well, then we just need to git rebase A topic our changes on a commit that won't be altered.

D'---E'  topic
 /
A----B----C----F  master

Then once the changes have come in, we can git rebase G topic and get our changes back to where we know they go.

D'---E'  topic
      /
A----G----H----I  master

Hopefully this explains the pain of trying to run a central access git repo along side a svn repo.