Git SVN和合并分支

Question

I am working on a svn project with two branches, lets call them

trunk
branches/foo

My idea is to clone the whole svn repository (telling git which folder are trunk, tags and branches), do the merge in git and then copy my merge to a svn working copy and commit the changes from svn.

In this workflow, will I be able to use gits merging power or will that only work for branches created with git itself?

Answer 1

Create alias for checkout command:

git config alias.co checkout

Make sure that you local branches are up to date:

git co master    # checkout branch that tracks subversion's trunk
git svn rebase 
git co local/foo # checkout branch that tracks subversion's branches/foo
                 # It assumes that  the branch is created with the command:
                 # `git co -b local/foo remotes/foo`
                 # And the repo was created with:
                 # `git svn clone --stdlayout SVN_REPO_URL`
git svn rebase 

Merge branches:

# create new local branch based on `master`
git co master
git co -b merging_branch_foo 
# merge, resolve conflicts, etc (pure git)
git merge local/foo  

# rebase `merging_branch_foo` to linearize history for subversion
git rebase master # or `rebase -i`

# merge `merging_branch_foo` into `master`
git co master
git merge merging_branch_foo # --squash to create single commit

# commit changes to svn
git svn dcommit

# (optionally) delete `merging_branch_foo`
git branch -D merging_branch_foo

Answer 2

There is a way to perform merging with git but committing (upstream) with Subversion that is complicated to set up, but is powerful (and much easier than merging with Subversion!) in practice. First, read Derick Bailey's git+svn overview , because you will need to set up the git and SVN ignore files as he instructs.

Note that this doesn't use the standard git-svn package, but replicates a lot of what that does, manually. If you're already using git-svn, don't use this method. Also, it's only worth using this method if you'll be repeatedly merging from the branch to the trunk (and especially if cherry-picking from the trunk to the branch) because that takes advantage of git's history when performing additional merges.

Then, the basic steps are as follows:

1. SVN Checkout /trunk/ to a working copy folder; I'll assume it's C:\\trunk .
2. git init a git repository in that folder; set up .gitignore ; git add -A ; git commit (see git+svn above).
3. Create a git clone of the repository (in a different folder): git clone C:\\trunk foo . I'll assume this clone is in C:\\foo .
4. Delete everything in C:\\foo except the .git subfolder, then SVN Checkout /branches/foo in C:\\foo .
5. In C:\\foo, run git add -A; git commit git add -A; git commit to save the changes on the branch to the git repository. This creates the initial git history that diverges from the history in C:\\trunk.

We now have two folders that are both git repositories and Subversion working copies; additionally, git thinks the folders are clones of the same repository.

Perform work in the C:\\trunk and C:\\foo folders (or just svn update to get others' work). Periodically, run git add -A; git commit git add -A; git commit to save changes to your git repositories.

Now you want to merge the foo branch back into trunk. In C:\\trunk, run git pull C:\\foo . This pulls in and merges all the changes from the C:\\foo folder, which is your git repository tracking the /branches/foo Subversion branch. If necessary, resolve any conflicts and finish the git commit.

You can now commit the changes in C:\\trunk to Subversion without having to use Subversion to perform the merge.

Answer 3

I would recommend you to use SmartGit for your SVN project. It has very good support for both cherry-picking merges and full merges, properly modifying svn:mergeinfo.