According to the manual, git dcommit
“will create a revision in SVN for each commit in git.” But is there a way to avoid multiple Subversion revisions? That is,
The command git rebase -i
can do this, and more. This command is extremely powerful, so it's good to make friends with it.
The syntax is: git rebase -i <commit ID>
. This brings up your text editor, with options (and instructions) for modifying all the commits up to (not including) the given ID.
For example, to modify the previous 5 commits, you can do this:
git rebase -i HEAD~5
Or if your SVN branch is called "svn/trunk", then this syntax is good too:
git rebase -i svn/trunk
Then a text editor window will pop up. To squash everything, change the first word of every line after the first from "pick" to "squash" (If this sounds confusing- it will make more sense when you see it). Then save and close the editor. You'll then have a chance to edit the commit message for the squashed commit.
Among the other things you can do with git rebase -i
, are reordering commits, squashing commits in different ways, and removing commits.
I use this command constantly; it's a killer feature of Git.
If you work on a branch in git, you can git-merge --squash, which does that within git. You could then push that one squashed commit to SVN.
Of course, lots of small commits are good, so why would you want to squash them?
Ryan Tomayko wrote a bit about git rebase -i
, which he said:
…[it's] a bit like git commit --amend hopped up on acid and holding a chainsaw – completely insane and quite dangerous but capable of exposing entirely new states of mind. Here you can edit, squash, reorder, tease apart, and annotate existing commits in a way that’s easier and more intuitive than it ought to be.
I have a tendency to commit often in git, but don't necessarily want to dcommit every commit to svn, and squashing all my work makes just as little sense. I'm trying it now to reorder and squash a few together into more logical commit units now.