Like so many things, it depends. You have to consider risk, to the data, to the user experience, to the other work going on. Changing some text or a button, add

Like so many things, it depends. You have to consider risk, to the data, to the user experience, to the other work going on. Changing some text or a button, adding a new report, sure, push to master and deploy. Low risk. Other kinds of changes might corrupt the database, confuse users, expose the application to a security vulnerability, or bring the business to a halt. As another commenter said you can roll back a bad deployment, but that only matters if the bad deployment didn’t break things. You can pull a knife out of your leg but that doesn’t roll back the damage. Thinking in absolutes, calling a cautious workflow “cancer,” doesn’t help developers make good decisions. For a change that might cause significant or irreparable damage I want a feature branch, a pull request, and reviews.