Having read seven or eight posts about the “patch”-style, kernel.org style git workflow, I feel like this article by Drew explains it the straight-forwardliest.
That is pretty much how I do it too. Unless I’m in an organization with a different flow, of course. When in Rome… Both for my own stuff, and for the typical drive-by bazaar-contributions I do, this work well.
I don’t like calling it “branchless”, though, since just like Drew:
Sometimes I do use branches, though, when I know that a workstream is going to be a lot of work — it involves lots of large-scale refactoring, or will take several weeks to complete. This isolates it from my normal workflow on small-to-medium patches, acknowledging that the large workstream is going to be more prone to conflicts. By addressing these separately, I don’t waste my time fixing up the error-prone branch all the time while I’m working on my smaller workstreams.
One example of that for me is when I did the massive update of match-generics, which was one of the difficultest things I’ve ever written (ironic since the original version was just a one-hour hack wrapper for foof’s match-lambda). I kept the “rewrite” in its own branch until it was done, so I could still do maintenance fixes for the original. I knew the “rewrite” would take a while.
Once it was done, I could say goodbye to the old version.
This debate is pretty over now that there are tools that lets you get the best of your preferred workflow regardless. For example, there is notmuch-import-patch that turns a branch (from a pull-request or the like) into email so you can review and reply to it.