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? > >
