accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Gitflow
Date Fri, 11 Oct 2013 15:38:04 GMT

On 10/11/2013 11:23 AM, Benson Margulies wrote:
> On Fri, Oct 11, 2013 at 10:39 AM, Josh Elser <josh.elser@gmail.com> wrote:
>> Absolutely!
>>
>> The tl;dr of it as we have adopted is as follows:
>>
>> We have branches for each version currently supported: 1.4.5-SNAPSHOT,
>> 1.5.1-SNAPSHOT and 1.6.0-SNAPSHOT (which is just in master).
> So, comparing to the stock gitflow picture ... The stock gitflow
> picture has one 'master' branch that gets tags for the releases, but
> not the hotfixes, and one develop branch. Your description reads to me
> as an extension of that model to reflect multiple release-history
> branches. Do you have the git-flow-ish master/develop distinction for
> these, or is it as simple as your next sentence.
Nope, you're right -- we use a modified approach to it. The original 
git-flow diagram doesn't really support active development (not just 
bugfixes) on multiple versions concurrently well as-is. IMO, a lot of 
the really nice features of gitflow really come down to guidance on how 
to swing the git "hammer", plus providing a nice picture :P

>> For bugfixes or new features, apply the change in the "oldest" version fix
>> and merge into newer branches.
>
>
>
>> Use feature branches to isolate and share your long-running work.
>>
>> What's on your mind?
> Other than the above, we wonder, 'what use is the master branch in the
> canonical gitflow picture? :-)'
I like to think of master as a "good landing point", but I think this 
depends a bit on the team you're working with. If I pull a repo, I would 
expect that master would be in a good, usable and tested state. Some 
people would rather treat master as an unstable, active development 
branch. I think there are arguments for both and encourage you to try to 
think about your branch layout in such a way that mimics how you *want* 
to do development/releases, not how you have done it.

If no one really cares about being able to deploy the most recent 
version of your code right off of master, then, yeah, the master branch 
in the picture doesn't make much sense. If you're good about testing and 
tagging often, it makes master much less meaningful.
>
>>
>> On 10/11/2013 10:32 AM, Benson Margulies wrote:
>>> I have a little favor to ask. I read the discussion about git process
>>> with ignorant interest some months back, and now I am in the process
>>> of trying to use gitflow with a team myself, and feeling a bit
>>> puzzled. Would any of the folks who were providing guidance here be
>>> willing to entertain some questions from me?
>>


Mime
View raw message