nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Taft <>
Subject Re: [DISCUSS] git branching model
Date Mon, 15 Feb 2016 16:41:31 GMT
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.


On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <> 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.
> 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 <>

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