The approach discussed on the article seems to take into account only one possibility: you deploy master in prod, and it's always considered correct.
That works for small projects, but in my experience, when you have a bunch of people (let's say 20) pushing code to a repo, you need several levels of "correctness"
- branches: Work in progress.
- develop: Code ready to share with others. It can break the build (merge conflicts, etc) and it won't be the end of the world.
- master: This shouldn't be broken. It needs to point to a commit that has already been proven not break the build/pass all the required tests.
As always, you need to find a balance with these things and adapt to the peculiarities of your code base and team. I really see them as suggestions...
- branches: Work in progress.
- develop: Code ready to share with others. It can break the build (merge conflicts, etc) and it won't be the end of the world.
- master: This shouldn't be broken. It needs to point to a commit that has already been proven not break the build/pass all the required tests.
As always, you need to find a balance with these things and adapt to the peculiarities of your code base and team. I really see them as suggestions...