Cool, I'll make a new dev branch now. Dev, develop, any preference?
On Sat, Apr 22, 2017 at 10:30 AM, Pat Ferrel <p...@occamsmachete.com> wrote: > It hasn't been often but I’ve been bit by it and had to ask users of a > dependent project to checkout a specific commit, nasty. > > The main affect would be to automation efforts that are currently wip. > > On Apr 22, 2017, at 10:25 AM, Andrew Musselman <andrew.mussel...@gmail.com> > wrote: > > I've worked in shops where that was the standard flow, in hg or git, and it > worked great. I'm in favor of it especially as we add contributors and make > it easier for people to submit new work. > > Have we had that many times when master got messed up? I don't recall more > than a few, but in any case the master/dev branch approach is solid. > > On Sat, Apr 22, 2017 at 10:06 AM, Pat Ferrel <p...@occamsmachete.com> > wrote: > > > 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? > >
