Some historic background (from my point of view):
Back in the days of svn, mainline development was the most feasible way of writing code in a (distributed) team. Branching (and merging) was not so easy and often made things worse. Working on the mainline was a real pain in the ass: you don't want to commit stuff that could break the build, so your commit grows and grows until all the bits and pieces are there to fully increment the code and reach a buildable state including your feature.
With git many teams switched to a feature branch development, where every feature got its own branch, where you can commit often and early (since it only breaks your local build and does not affect others) and where you merge the branch once the feature is ready to release.
Martin Fowlers article made me realize that feature branch development has its downsides as well. If you work with a bunch of colleagues on one product and you work on that product 8h a day, merge conflicts will be quite common. When you have a branch and work on it for a couple of days, the merge becomes a bigger risk with every minute. But since I cannot tell the story as good as Martin Fowler, read his article.
2 comments:
Having worked on several long-term (6-12 month) feature branches for GNOME modules, the technique I use is to work off a fixed set of commits on a PRIVATE branch - one commit per source file or source directory or some other logical partitioning.
Then I constantly refine these commits as my feature progresses through interactive git rebasing. So if I modify some file A, I commit the changes with a "fixup A" comment, then later do "git rebase -i" and merge the "fixup A" commit into the main commit for file A using a "fixup" command.
Also I periodically rebase my feature branch against the latest changes in "master", which is made much less painful by sticking to a fixed set of commits which represents the current state of my feature. (I'm not interested in keeping a complete history of my own private feature development.)
When the feature reaches a milestone, I snapshot my work by pushing my private branch up to git.gnome.org, usually after tearing down my previous public snapshot branch, or I suppose you could also number the public branch names. Then I announce to the project's mailing list that I've done so.
Different projects have different norms, but this works well for me and adheres to GNOME's git policies.
Followup:
I just found out how the guys over at github are working. they have another interesting angle, similar to the process we use in GNOME.
http://scottchacon.com/2011/08/31/github-flow.html
I think this also justifies to review every piece of code. If github can do it, we can as well! It improves code quality and everyone in the team can learn something during review, either as reviewer or reviewed :D
Post a Comment