nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Kurc <trk...@gmail.com>
Subject Re: [DISCUSS] git branching model
Date Tue, 16 Feb 2016 13:34:19 GMT
While I like gitflow, I can't say I like any of the plugins that are used.
I have worked on some other projects (unfortunately not open source) that
use a gitflow inspired workflow, without ever using a plugin. Nice side
effect is that I believe this got me better at using git, and generally we
all got better at managing merge pain.

On merge problems, I think the reason we're operating the way we are now is
to avoid merge mayhem. I think the initial bar for a patch is "can be
merged into master", and we have our friend Travis to make this even easier
to know upfront. This greatly simplifies things. If a bugfix is "patch
needs to be able to apply onto the current release in progress, master, and
several other versions we're supporting, with possibly drastically
different code", well then things get interesting.



On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <bimargulies@gmail.com>
wrote:

> The issue tracker
>
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> might also prove useful in evaluating it.
>
> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> <bimargulies@gmail.com> wrote:
> > I tried to use the bitbucket gitflow plugin. It worked great, until it
> > didn't. It would get into terrible, inexplicable, merge problems. No
> > one seemed to be maintaining it.
> >
> > There's a new offering in this dept:
> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> >
> > On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <adam@adamtaft.com> wrote:
> >> One of the harder things with gitflow is using it in combination with
> >> maven.  It's ideal that the tags and releases are tracking closely with
> the
> >> maven pom.xml version.  gitflow, on its own, doesn't keep the pom
> version
> >> updated with the git release names.
> >>
> >> Because of the general importance of keeping releases and tags
> synchronized
> >> with the pom version, I think whatever we do, it needs to be approached
> >> with tools that are available through maven rather than from git.  The
> >> git-flow plugin (referenced by Thad) doesn't directly help deal with
> this
> >> synchronization, since it's a git tool, not a maven tool.
> >>
> >> I've been using, with reasonable success, the jgitflow [1] plugin, which
> >> does a reasonable job of following the gitflow model for a maven
> project.
> >> I don't recommend this plugin for NIFI, because it insists that the
> master
> >> branch is strictly used for published release tags (as per the strict
> >> gitflow workflow).  I just mention this, in reference to how some
> plugins
> >> are tackling the gitflow and maven synchronization issue.
> >>
> >> [1] http://jgitflow.bitbucket.org/
> >>
> >>
> >> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <thadguidry@gmail.com>
> wrote:
> >>
> >>> Your on the right track / idea with Git-flow.  Your Master become
> primary
> >>> development of next release (with feature branches off of it).. while
> you
> >>> continue to have release branches that can have hot fix branches off of
> >>> them.  (don't use Master as your release branch ! - bad practice ! )
> >>>
> >>> Here is the Git-flow cheat sheet to make it easy for everyone to
> >>> understand... just scroll it down to gain the understanding. Its really
> >>> that easy.
> >>>
> >>> http://danielkummer.github.io/git-flow-cheatsheet/
> >>>
> >>> Most large projects have moved into using git-flow ... and tools like
> >>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either built
> in or
> >>> plugin available now.  If you want to live on the command line, then
> that
> >>> is handled easily by the instructions in the above link.
> >>>
> >>> Thad
> >>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> >>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message