[ryanbrunner]

I think from the perspective of the central repository, this is a sane approach. Locally though, you should still be routinely using (short-lived) feature branches. Working directly off master on your local machine can make things annoying / complicated when you need to move away from your work for a moment (say to fix a bug) and don't have a good representation of "what's currently on production".

Also, I think this approach necessitates that you have some form of continuous deployment, or strong assurances that master is almost always on production. If, for example, you have a fixed 2-week cycle for production releases, "just work off master" will be a source of pain when you inevitably have to fix a bug on production without rolling out the other commits that are there for the "next release". That might not be an optimal way of developing, but it's about more than just how you use git - it's really more of a delivery question.

[bbatha]

Depending on the frequency of your deploys you can simply add release branches or tags to the “work on master” model. Any decent deployment system can deploy from an arbitrary arbitrary ref, plus release history in your git log is very useful. The point here is to eliminate long lived feature branches that require their own maintenance.

[geezerjay]

> Depending on the frequency of your deploys you can simply add release branches or tags to the “work on master” model.

...and then you get the git workflow described in the blog post.

It only takes a single regression to learn the importance of separating the development branch from the main branch.

[skrebbel]

A hotfix branch fixes this. You can still do trunk based development for the rest, and cherry pick the bugfixes into such a hotfix branch (branches off from the latest commit that was released).

[TheRealWatson]

Fair enough but at that point you're creating a branching model, which is what the original comment advocated against.

[skrebbel]

No it didn't. You're seeing things black and white just to win an argument. It advocated against feature branches, git flow and all that. Occasional never-merged-back hotfix branches really don't undermine the core point.