在执行git-svn dcommit之前压缩或编辑一些提交？

Question

I am working on a project in a subversion repository with a strict check-in policy which includes: Every commit to the trunk has to be reviewed by another developer and this must be mentioned in the commit message.

While working with git-svn I am making many incremental git check-ins that aren't reviewed. Their git commit messages reflect this.

What's the best way in which to use git-svn but follow the rules for the svn repository? Should I just squash all commits into a single svn commit? Can I rewrite the commit messages for each revision with the reviewer information? Could I "manually" move each individual change to the git master branch and modify the commit message of each before doing a git-svn dcommit?

Answer 1

I work in a branch on git, then checkout master, git svn rebase and finally merge the branch into master.

At this point, git svn dcommit will put all the interim commits into svn one at a time with their original messages — not what's wanted! But if I use git commit --amend to change the merge's commit message from the standard merge message to something that fits our policy for svn commits, the dcommit will lump them all together as one under the new message. Win.

I've found that this doesn't seem to work if master hasn't changed over the lifetime of the branch — the commits just get fast-forwarded in, with no "merged branch" message — so it's best add the --no-ff flag to git merge .

Summary:

git checkout branch
<do work>
git checkout master
git svn rebase
git merge --no-ff branch
git commit --amend
<policy-compliant commit message>
git svn dcommit

Answer 2

You can interactively rebase your local branch against the Subversion tracking branch which provides you with an opportunity to squash and amend the commit.

Next time you dcommit, dcommit will replay your history one commit at a time and this is what will be commited to Subversion.

Assumptions:

1. Local branch is master
2. Master is checked out
3. Remote tracking branch is named git-svn
4. git-svn is up to date

What to do:

$ git rebase -i git-svn

Your default editor will open with a list of commits in master to rebase against git-svn. You can pick, edit or squash the commit (Mix and match if desired).

After making your selection, another temporary file will open displaying commit messages for each of the commits you're rewriting. This is where you amend the commit message.

Caveats:

You're rewriting the history of your repository, exercise caution. It might be worthwhile experimenting with this behaviour until feel confident.

Answer 3

Yes, you can rewrite the commit messages. Yes, you can just squash them all in to a single commit. This probably depends on the review process and how much you're doing at once.

"Manually" moving each change to the master branch wouldn't be especially different from rewriting your commit messages at some level, but many diverging branches and cherry-picks could come in handy.

Overall, the answer is "it depends" and "Git is flexible enough to do just about whatever you need".

Answer 4

This might be worth a try, I'm a relative newbie but this is what I'm doing for now:

Create a clone of the remote svn repository:

# clone svn repository
git svn clone ....

Create a normal git repository (clone of the clone):

# clone the clone :)
git clone /path/to/original/clone
git checkout -b working

You can now work in the second clone as though it were a normal git repository (essentially it is):

# commit changes, whatever you like
git ci
...

To push your changes back to the central SVN repository go back to the first clone and:

# pull and flatten changes
git pull --squash /path/to/working/clone

The --squash parameter means that all the commits that are pulled in are merged into one commit. That commit is not committed immediately so you can then:

git ci
git svn dcommit  

The last step then pushes everything as one single commit.

Edit - I wouldn't normally recommend using --squash in other circumstances but note that the working repository retains the full complete history (it's immune to the squash) but what you send upstream is squashed into a single clean commit which is what is needed in this case. I believe it to be a reasonable compromise.