In past projects I've worked on where we were more strictly gitflowy, master always tracked the most recommended production-worthy branch. This allowed automated deployment systems to just track master and always stay up to date and stable, without having to manually bump to new release tags or branches as numbers changed.
In practice, I don't know how valuable it actually was, but it was a nice idea. On Fri, Oct 11, 2013 at 11:23 AM, Benson Margulies <bimargul...@gmail.com>wrote: > On Fri, Oct 11, 2013 at 10:39 AM, Josh Elser <josh.el...@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. > > > > > 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? > > > > >
