I don't want to kill this thread. It is good to discuss specific tooling/procedures. But I do want to get some consensus discussion around Tony's original intent (as I read it). So kicked off a discussion back at that level.
On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <[email protected]> wrote: > 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 <[email protected]> > 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 >> <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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> >> >>> >>
