search

aboutcode-org / scancode-toolkit

:mag: ScanCode detects licenses, copyrights, dependencies by "scanning code" ... to discover and inventory open source and third-party packages used in your code. Sponsored by NLnet project https://nlnet.nl/project/vulnerabilitydatabase, the Google Summer of Code, Azure credits, nexB and others generous sponsors!
https://github.com/aboutcode-org/scancode-toolkit/releases/
2.07k stars 536 forks source link

Simplify branching model #2203

Open pombredanne opened 4 years ago

pombredanne commented 4 years ago

We de-facto use the gitflow branching model at https://nvie.com/posts/a-successful-git-branching-model/ BUT the "master/develop" branches are making double duty and serve not purpose. In practice all the code merged in develop is immediately usable in production. Therefore I suggest we switch to a simpler branching model which is the de facto model we use today:

  1. one single default branch called "main" where only merges are done
  2. features are pushed in other branches and merged when fully ready in "main"
  3. now and then we tag and cut a formal release from "main"
  4. exceptionally and likely never we can branch from a tag to backport a hotfix just there
steven-esser commented 4 years ago

:+1: I am all for this change

mjherzog commented 4 years ago

I am not any expert in this area. The assertion that "all code merged in develop is immediately usable in production" seems highly optimistic over any longer period of time. I think that we need to get back into a cadence of more frequent minor releases.