git svn workflow - feature branches and merge

Question

I am using git-svn with the following workflow now

git clone  #done once

subsequently when I work on a feature

Answer 1

SVN cannot handle non-linear history (it simply has no notation of it). So what you want to do is a rebase instead of a merge as it preserves linear history with SVN (this is indicated in on the git-svn man page here.

To elaborate, linear histories are trivial. They go in a straight line (A to B to C to D). Whereas non-linear histories can go from (A to B to C, B to D then C + D to E--in other words, they off sprout into branches).

Rebasing will give you a linear history. Remember that rebases should be done from your private local-only branches. For instances, if you have 2 branches: master and experimental. You would checkout experimental and do 'git rebase master' preferably with the -i flag. Doing it the other way around may result in undesirable side effects.

It is then you checkout master and merge in the changes from the experimental branch. Your history should remain linear.

Answer 2

You should look at this merge option:

git checkout master
git merge --squash featureZ

It will squash all commits on the branch into a single commit on the master branch. You will get an opportunity to edit the log message, which is initialized with a summary of what was done on the branch.

It has the disadvantage that the individual commits on the feature branch are not recorded. Furthermore, you should only do this once, and not do any more work on the branch, because it is not registered as a proper merge, and any subsequent merge might give undesired results.

Answer 3

The answer given by fake-code-monkey-rashid is correct. This is less of an answer and more of a simplification.

You can svn rebase/dcommit from any git branch. The only use master would have is if you had other local changes you needed to merge with the changes from featureZ.

git branch featureZ
git checkout featureZ
#bunch of changes
git commit
git svn rebase
# solve any conflicts
git svn dcommit

If you want to keep a clean master then you can either git svn rebase it or git merge featuresZ

Answer 4

Instead of git-svn, you may use SubGit. It's a server-side tool which automatically synchronizes Subversion and Git repositories.

You can use any Git workflow and any Git client available, no additional client tools needed.

Considering your scenario:

git branch featureZ
git checkout featureZ
# make edits for featureZ
git commit
git checkout master

You can proceed as follows:

1. Push feature branch entirely.

   git merge featureZ
   git push origin refs/heads/*
   

2. Rebase a feature branch on top of master/trunk.

   git rebase featureZ
   git push
   

3. Squash commits from a feature branch.

   git merge --squash featureZ
   git commit
   git push
   

As soon as you push changes, SubGit hooks translate your changes into Subversion revisions.

Some more details:

• SubGit in many ways is more superior than git-svn — better merge-tracking translation, EOLs & mime-type support, etc.
• SubGit needs local access to Subversion repository (it uses custom hooks);
• SubGit is a commercial product with some free options (open-source and academic projects, small teams).