Consider the following scenario:
You work on a project for a customer that is handled in a Subversion Repository.
The work you get comes in form of some tickets. Tickets may affect different parts
of the project, but they could also affect the same parts of the project. Testing of your work
is done by a different person. For some reasons its wanted that the fix for each ticket
is committed in only one commit in the subversion repository and only after it has been
tested. Commits for two tickets changing the same files should not be mixed.
Now: How do you avoid a mess when working with several patches that possibly affect the same files?
The answer is: git with git-svn. Currently my workflow looks the following:
- Create a branch for each ticket
- Make my changes for the ticket in this branch
- Create a patch from the changes in this branch and supply the tester with it
- Wait for feedback and eventually repeat steps 2-4
- When testing is finished, run git rebase -i master in the branch, now squash each commit into one commit, build a proper commit message from the template git provides.
- Switch to master branch and merge the changes from the branch.
- Rebase master against the latest svn (git svn rebase) and dcommit
That workflow works good for me. It gives me the possibility to do micro-commits as much as I want and still only commit a well-defined, well-tested commit into the projects SVN.
Just some minor drawbacks I haven’t yet solved (you know, git /can/ do everything, but that is actually a problem in itself):
- Its a bit annoying that I need to use git rebase -i and change n-1 lines for a number of n commits, so that they are squashed. It would be handy to say: Squash all commits, that happened in this branch, into one.
- Creating the diff for the tester requires me to do git log, search for the last commit before my first commit in that branch and use it with git diff to create a patch. I had a quick look at git-rev-parse and felt that is overwhelming complex to do find out how to do it better. To many possibilites. git is complex.
For now I cannot tell how good merging works, as soon as conflicts arise. But I guess git can do well, although there is the possibility that it could get complex again.
Nevertheless, its probably not a credit to git, but instead to DVCSes in common, but anyway. I like it.