At my previous job we were mostly working like this and I still think it is the better way. I would sometimes create 10 commits or so a day, all of them very small. This way everybody gets the latest code much earlier.<p>Feature branches discourage refactoring because if the work that is off master is bigger merge conflicts can easily get much hairier<p>Small commits also forces one to have a good automated tests because one is not going to test everything manually after every very small commit. It ties in very nicely with the TDD cycle.<p>Not all work can be done this way so sometimes one needs a feature branch but most of the time it is not needed. In many cases feature switches are a good alternative, if needed.
Some interesting arguments are presented in this article but there are a couple of pretty important issues this workflow totally elides. First of all, where are code reviews? If you're committing directly to master, does that mean every commit has to get reviewed before it can be merged? So in fact you are creating a new branch for every commit and then merging it into master (presumably amending to address review comments). So now you are back at square one. Secondly, how do people work concurrently without constantly pulling/merging? I suppose you could argue it's better to resolve small conflicts frequently than to address them all at once, but surely there are times when a developer needs to be able to work unfettered.<p>Overall I like the idea of working incrementally and ensuring that every commit adds value. I'm just not sure about the specific git workflow presented here.
My previous job does the opposite. We create a branch on for a release, then everyone works on main. Whenever a feature is done, we merge to the release branch, run tests on it and release the software. Worked very well for a long time. I guess it makes agile more difficult?