Best way to fork SVN project with Git

I have forked an SVN project using Git because I needed to add features that they didn’t want. But at the same time, I wanted to be able to continue pulling in features or fixes that they added to the upstream version down into my fork (where they don’t conflict). So, I have my Git project with the following branches:

  • master – the branch I actually build and deploy from
  • feature_*** – feature branches where I work or have worked on new things, which I then merge to master when complete
  • vendor-svn – my local-only git-svn branch that allows me to “git svn rebase” from their svn repo
  • vendor – my local branch that i merge vendor-svn into. then i push this (vendor) branch to the public git repo (github)

So, my flow is something like this:

git checkout vendor-svn
git svn rebase
git checkout vendor
git merge vendor-svn
git push origin vendor

Now, the question comes here: I need to review each commit that they made (preferably individually since at this point I’m about twenty commits behind them) before merging them into master. I know that I could run git checkout master; git merge vendor, but this would pull in all changes and commit them, without me being able to see if they conflict with what I need.

So, what’s the best way to do this? Git seems like a great tool for handling forks of projects since you can pull and push from multiple repos – I’m just not experienced with it enough to know the best way of doing this.

Here’s the original SVN project I’m talking about:

My fork is at

  • Is there a command to list SVN conflicts?
  • How do you fix an SVN 409 Conflict Error
  • Restore deleted file from repository
  • How does bug tracker/version control integration work with typical git workflows?
  • How do I fix a repository with one broken revision?
  • Maintaining a set of small changes not to be committed to SCM
  • SVN project structure
  • Is it acceptable/good to store binaries in SVN?
  • One Solution collect form web for “Best way to fork SVN project with Git”

    It seems like you should just create a branch off of master for your testing:

    git checkout -b testing master
    git merge vendor-svn
    # test...
    git checkout master
    git merge testing

    Or, if you want to test individual commits, you could merge them all individually at once:

    git checkout -b testing master
    git log --pretty=%H testing..version-svn | while read commit; do git merge $commit || break; done
    # now go check out and test each merge that was created

    Or one at a time:

    git checkout -b testing master
    git merge $(git log --pretty=%H testing..version-svn | tail -n 1)
    # now test the result, and if you're okay...
    # run the merge command again to merge the next commit
    git merge $(git log --pretty=%H testing..version-svn | tail -n 1)
    # and so on

    You’ll probably like the latter better, since you can test that commit before bothering to merge the next one. The history will be ugly, so you’d obviously want to go back and redo it all as one merge later.

    Either way be sure and set rerere.enabled to true so that git will remember how you’ve resolved conflicts, and when you go back and redo the merge straight into master, you won’t have to resolve them over again!

    Git Baby is a git and github fan, let's start git clone.