gitflow is a model for developing and shipping software using Git. Add-on SDK uses Git, and it too has a model, which is similar to gitflow in some ways and different in others. Here’s a comparison of the two and some thoughts on why they vary.
First, some similarities: both models use multiple branches, including an ongoing branch for general development and another ongoing branch that is always ready for release (their names vary, but that’s a trivial difference). Both also permit development on temporary feature (topic) branches and utilize a branch for stabilization of the codebase leading up to a release. And both accommodate the occasional hotfix release in similar ways.
(Aside: gitflow appears to encourage feature branches, but I tend to agree with Martin Fowler through Paul Julius that continuously integrating with a central development branch is preferable.)
Second, some differences: the SDK uses a single ongoing stabilization branch, while gitflow uses multiple short-lived stabilization branches, one per release. And in the SDK, stabilization fixes land on the development branch and then get cherry-picked to the stabilization branch; whereas in gitflow, stabilization fixes land on the stabilization branch and then get merged to the development branch.
(Also, the SDK releases on a regular time/quality-driven “train” schedule similar to Firefox’s, while gitflow may anticipate an irregular feature/quality-driven release schedule, although it can be applied to projects with train schedules, like BrowserID.)
A benefit of gitflow’s approach to stabilization is that its change graph includes only distinct changes, whereas cherry-picking adds duplicate, semi-associated changes to the SDK’s graph. However, a downside of gitflow’s approach is that developers must attend to where they land changes, whereas SDK developers always land changes on its development branch, and its release manager takes on the chore of getting those changes onto the stabilization branch.
(It isn’t clear what happens in gitflow if a change lands on the development branch while a release is being stabilized and afterward is identified as being wanted for the release. Perhaps it gets cherry-picked?)
Overall, these models seem fairly similar, and it wouldn’t be too hard to make the SDK’s be essentially gitflow. We would just need to stipulate that developers land stabilization fixes on the stabilization branch, and the release manager’s job would then be to merge that branch back to the development branch periodically instead of cherry-picking in the other direction.
However, it isn’t clear to me that such a change would be preferable. What do you think?
I think each project should use whatever makes sense for it. Treating any particularly model as dogma, including gitflow, doesn't help anyone.
While gitflow also has tools to help with their process, I tend to avoid them – if you understand git the tools don't offer a huge benefit and if you don't understand git well enough you should learn!
All that said though, I expect the requirements for the SDK are very similar to what other Mozilla projects will want to use. Therefore it might make sense to document a "mozilla best practices for working with git" – let's call it "MoFlow" – with no tools, just an overview of the process, then people can keep their heads down and keep doing that they are great at! This is pretty much the approach being takes with the Open Web Apps and F1 work – it looks like gitflow from 1000 feet, but in practice we are just cherry-picking the parts of gitflow that make sense to us.
MoFlow – love it!
The webdev teams have been moving away from git flow as far as I can tell (I'm most familiar with AMO). AMO started close to git flow but eventually drowned in too much process and not enough getting things done. Like you mention, merge commits just take up space – if it's a single commit you're merging in, you've just doubled the commit messages you get to sort through.
AMO is still in the process of continuous deployment (you can imagine the hurdles with our infrastructure split) but both teams have been working hard on it and we're getting closer.
http://scottchacon.com/2011/08/31/github-flow.html is pretty close to the eventual goal which feels more focused on pushing code and less on dealing with your VCS.
Like he mentions at the bottom though, if you're not doing rapid releases, it might not be helpful. I don't think calling something "Mozilla best practices" is justified though as it'll differ team by team.
I expect that any changes for a stabilization branch should be tested on that branch as part of developing the change, but maybe it matters how much skew there are between the stabilization and development branches.
It can be hard to track what branch you are working on. I use a colorized command prompt that displays the git branch in the prompt, which has really saved me some trouble. That, and git stash if for some reason I start a change without realizing the branch.
For me, gitflow was just a way to understand the "branch for every feature and set up dev, release/stabilization branches". I have since stopped using the gitflow tools and just do the branching and merging manually.
Overall, I agree with the general sentiment that imposing a single system on every group within the mozilla community is counter productive. I also think it is not useful to impose a complicated process in an early stage experiment with only a couple active developers. That said, in this particular case, the differences between SDK and gitflow seem trivial.
A couple thoughts/clarifications:
Feature branches: In BrowserID we aren't so crazy about every change going into dev requiring a feature branch. My general rule is that if the change fits in a single commit, don't bother with branches. Further, feature branches in my mind are ideally as short lived as possible.
Stabilization fixes: A question raised above was how does gitflow handle stabilization fixes? What we tend to do in BrowserID is to make the fix on the currently rolling "train" or release branch. Subsequently you can merge (or cherry pick if you prefer) back into the development branch. The rationale for this is that merging is a bug vector, and it is better to incur this risk on a branch that hasn't yet been through QA, as opposed to one that has been through.
Where shall commits land: In the post myk posits that gitflow is more complicated in terms of where you land commits. One thing that I like about gitflow is that I feel like the complexity is well placed. Casual contributors need only know that they branch and contribute to the dev branch. More active acting "release managers" must also know that a production hotfix goes into a hotfix branch off of production code, and a stabilization fix goes into the rolling train, and both of these events are coordinated with QA.
So finally, with BrowserID I've been very happy with our (subtle) flavor of gitflow. I think if feature branches are used pragmatically (not all the time), and merge commits have good informational value (rather than just leaving them with a useless default message), you get a history that is more readable and useful than by cherry picking.
One think that I'm curious about with the github flow is I wouldn't know how to integrate formal QA into that flow. It seems like this method may trade a little bit of stability for an improved pace.