我做错了吗？ 将SVN更改从trunk更改为git分支。 使用merge --squash

Question

We use branches to do our work and keep trunk pristine for the most part. Before merging my changes from my branch into trunk, I want to make sure that I've got the latest changes from svn/trunk into my local branch. It's taken me a bit to figure it out but here's the workflow I've come up with, and I'd like to know if there's a better way of doing it. (In this example I'm the only one on this branch, so there's no need to git svn rebase for changes to this branch)

git svn fetch
git co -b feature_branch svn/kastner/feature_branch
....work....commit...work...commit
git svn fetch
git merge svn/trunk --squash
git commit -m 'forward merge of svn/trunk'
git svn dcommit

The reasons I'm doing it this way:

• git merge without squash will add a git-svn-id pointing to trunk, so dcommit would push there
• rebasing to svn/trunk would take this branch totally off the tracks

Answer 1

What you're doing here is that you merge changes from svn/trunk to your git feature branch, and then dcommit these changes to svn equivalent of your feature branch. This means you have the branch both in git and svn, which doesn't make too much sense for me if you're working on it alone.

If you haven't yet merged stuff from trunk to this branch the way you describe above, rebasing the branch agains svn/trunk should work just fine. Then you should be able to keep it in git only, and when it's time to merge it in trunk, svn dcommit will push all your changes there, preserving the exact commits. (Which should be the best for keeping your history.)

To sum up, this is what I'm mostly using:

git svn fetch
git checkout -b my_branch svn/trunk
...work...commit...work...commit...
git svn fetch && git rebase svn/trunk
...see if it still works
git svn dcommit # commits all of this to svn trunk

Answer 2

The company where I work also uses Subversion for source control. I'm using a different approach: I'm committing very often to my local Git repository but don't want to swamp the Subversion server with my commits as I have several local branches with up to 2000 commits per branch. Submitting that to Subversion would probably take the better part of a working day. :)

# git svn fetch
# git checkout -b some-feature remotes/trunk
# (work, work, work, commit, commit, commit)
# git svn fetch
# git rebase remotes/trunk
# git checkout master
# git merge remotes/trunk    # updates to latest trunk
# git merge --squash some-feature
# git svn dcommit

This way my co-workers see my results as a single (though rather large) commit, the Subversion server does not have too much work with it, and I still have my complete line of development locally.