mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pat Ferrel <...@occamsmachete.com>
Subject Proposal for changing Mahout's Git branching rules
Date Sat, 22 Apr 2017 17:06:45 GMT
I’ve been introduced to what is now being called git-flow, which at it’s simplest is just
a branching strategy with several key benefits. The most important part of it is that the
master branch is rock solid all the time because we use the “develop” branch for integrating
Jiras, PRs, features, etc. Any “rock solid” bit can be cherry-picked and put into master
or hot-fixes that fix a release but still require a source build. 

Key features of git-flow:
The master becomes stable and can be relied on to be stable. It is generally equal to the
last release with only stable or required exceptions.
Develop is where all the integration and potentially risky work happens. It is where most
PRs are targeted.
A release causes develop to be merged with master and so it maintains the stability of master.

The benefits of git-flow are more numerous but also seem scary because the explanation can
be complex. I’ve switched all my projects and Apache PredictionIO is where I was introduced
to this, and it is actually quite easy to manage and collaborate with this model. We just
need to take the plunge by creating a persistent branch in the Apache git repo called “develop”.
From then on all commits will go to “develop” and all PRs should be created against it.
Just after a release is a good time for this.

https://datasift.github.io/gitflow/IntroducingGitFlow.html <https://datasift.github.io/gitflow/IntroducingGitFlow.html>

What say you all? 
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message