I don’t think this article gives advice to not use master for development but rather what it means is:
1. master must only have stable, tested, and production (not production “ready”) code and nothing else
2. If something in production breaks the hotfix should go into master and strive to achieve step 1
In fact this is really a good model. Keeps development streamlined and disciplined.
This has nothing to do with breaking the idea of having sane git defaults. In fact it’s a sane utilisation of defaults.
Non default branching is a necessity anyway. Default branch usually means just a master branch and committing directly into master, I believe, would lead to disaster. If one has to create branches it should be done for lifestyle steps below production.
1. master must only have stable, tested, and production (not production “ready”) code and nothing else
2. If something in production breaks the hotfix should go into master and strive to achieve step 1
In fact this is really a good model. Keeps development streamlined and disciplined.
This has nothing to do with breaking the idea of having sane git defaults. In fact it’s a sane utilisation of defaults.
Non default branching is a necessity anyway. Default branch usually means just a master branch and committing directly into master, I believe, would lead to disaster. If one has to create branches it should be done for lifestyle steps below production.