On 01/09/11 11:06 -0400, Chris Lalancette wrote:
On 09/01/11 - 11:02:35AM, Chris Alfonso wrote:
> Feature branches have been very useful for other projects I've
> been working on. Rather than having one bleeding edge branch to take
> all the latest and greatest features, feature branches provide a
> couple benefits over one "next" branch. For instance, if there are
> multiple commiters that need to collaborate on a feature that isn't
> ready to introduce to the larger audience, or if the patch set is
> under development for a longer period of time git allows you to do
> continual rebasing, and patch sets that are related can be set aside
> if needed then come back to them later, without having to rebase
> interactive and put everything back together in order.
Don't get me wrong, I'm not arguing against feature branches. I think they
are super useful and we should be using them all of the time. The part that
I am not convinced about is "master is always deployable". We tried that,
and it didn't work. The problem is that people who want stability grab the
packages from the last stable release. The people who want to develop grab
the latest development head from git. There is no audience for this in-between
"always deployable" branch.
Ah I understand what you're saying and I agree. The feature branches
are just staging areas for pull requests (or the seldom developer that
wants to try their feature out with some other feature because they
are going to be part of the same release). The only real audience of
the the in-between/feature-branches are the people on the other end of
the pull requests.
Thanks,
Chris