[geezerjay]

> I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI.

You've just described a naive implementation of the Git branching model described in the article which fails to meet some basic real-world requirements experienced on all software development projects. It matches the policy of merging changes from the development branch onto the master branch but lacking any support for very basic aspects of software development such as code auditing, versioning, and continuous integration.

It's silly to let everyone work off master if master is supposed to remain stable. If master is supposed to host stable versions, someone needs to be responsible for keeping it stable. If someone is assigned the task of ensuring the master branch is kept stable then he needs to control what gets into master and what doesn't. If someone needs to control what gets into master then other developers need to commit their changes to some other branch.

Add parallel releases and couple of levels of these real-world everyday aspects of software development and you get exactly the branching model described by Vincent Driessen in his blog post.

[chris_wot]

Agreed - you can have compiling code that passes all tests but which still needs someone to review. Or a feature that you are working on that you want to merge in later.