Okay develop it is; I'll cut a develop branch from master right now. As we go, if people forget and push to master, we can merge those changes into develop.
In addition, I'm making a 'website' branch for all work on the new version of the site. On Sat, Apr 22, 2017 at 10:36 AM, Pat Ferrel <p...@occamsmachete.com> wrote: > There are tools to implement git-flow that I haven’t used and may have > some standardization built in but I think “develop” is typical and safe. > > > On Apr 22, 2017, at 10:33 AM, Andrew Musselman <andrew.mussel...@gmail.com> > wrote: > > 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? > > > > > >
