What's the ideal git branching strategy for this product development?
===

Say I want to add a set of related, but independent, features to Twitter's (magically open source) iPhone app. While in the app, you can hit "Home Automation" and be presented with a screenful of buttons for controlling features in your home: Lights; Television; Temperature; Shades; and Music.

What is the ideal branching model in Git for developing this suite of features?

Here are some assumptions:

 - One person (the same person) will be developing all of the features.
 - Twitter encourages rebasing as its integration model.
 - All the features share some base code.

And here are my **nice-to-haves** for the model, although I'd love to hear all the model options:

 - It should be easy for code reviewers to review each feature independently at the end. In other words, someone reviewing the Lights code shouldn't have to deal with any changes made while implementing Television.
 
 - Each feature should have nice, clean history during development. When looking at foo.m while working on Lights, I should only see changes made to implement Lights, not changes made to implement Television.

 - I can still compile and test Lights even if I've left Television in a messy/broken state.

One **requirement** for the model is that I need to be able to generate testing builds on a regular basis that have all the features integrated, just as they'll be presented to users. In other words, when I run my test build, I see a Home Automation screen containing every feature.

My original instinct here was to set up the branches like this:

    Twitter
        \
         Automation
            \
             Lights
            \
             Television
            \
             Temperature
            \
             ...
 
In other words, I'd branch from Twitter to create the "Automation" branch, which contains the shared code that all the home automation features use, including stub code for the overview UI from which you access the features (i.e. the "screenful of buttons" referenced above). And then I'd create a series of branches from Automation, one for each feature. 

However, in this model, I'm having trouble understanding how I would produce my fully integrated testing builds in this world. I imagine I would need to create some other branch that regularly merges the Lights/Television/etc branches together. But there will be obvious conflicts in this merge. 

For instance, imagine that the shared UI code in the Automation branch has a function `num_buttons_to_render` that returns the number of buttons to render in the Home Automation UI. The Automation branch would return 0 here, since it doesn't implement any of the features itself. Each child branch (Lights, Television, etc) would return 1, since they're only implementing their own respective workflows and don't care about the other features. But the testing branch would want to return 5 here, since it wants to render all 5 automation features (Lights, Television, Temperature, Shades and Music). So I'd want to fix that conflict in the testing branch once and then continue to integrate subsequent changes from all the feature branches over time. But it's not even clear to me that I can do that, since all the feature branches are using a rebase model as dictated by Twitter's development standards.

I'm a git noob, so I hope I'm making some sense here. If not, I'll be here to proactively answer any follow up questions. Thanks so much for your help!