On 10/11/2013 11:23 AM, Benson Margulies 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.
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?
