Code branching isn't required even for complex multi project environments (thoughtworks.com)

Not required? How many things -are- required? I'm guessing the number is near zero.

Talk to me about pros and cons, not requirements.

The video puts down "Feature Branching" which is a very specific kind of "Code Branching."

I've seen Feature Branching work for some shops, but it can also create problems -- the more complex version control strategy you use the more likely you're going to make mistakes implementing it.

The "standard model" for branching that's most commonly used is to do most development in HEAD and make branches for releases. If you spin version 1.1 of your product, you should make a 1.1 branch, which starts with, say, version 1.1.0. If you find a terrible bug in 1.1.0, you can go back to 1.1, develop the 1.1.1 version, and then you can merge the bug fixes back into head.

The "standard model" minimizes the number of merges that need to be made while assisting maintenance of deployed software. Other branching models do worthwhile things, but the ratio of merging/benefits is invariably worse.

I've adopted the following branching model: http://nvie.com/posts/a-successful-git-branching-model/

Works like a charm for us.

It doesn't mean we don't update production as often as possible but we sure sometime need to push hot fixes to production quickly while working in parallel on new features. I would say branching is a necessary evil.

For git, code branching is really really easy (even without some tool/model like gitflow).

To me, it's like reading "Onions, not required even for complex multi-course meals". Why would you avoid that!

This guy doesn't seem to understand that you can merge your main branch into your feature branch constantly if you want.

This makes all of his points invalid.