On Fri, Oct 11, 2013 at 10:39 AM, Josh Elser <[EMAIL PROTECTED]> wrote:
> 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.
> 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? :-)'
> 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?