I guess it's a combination:
a) Granular commits are an essential basis of good version control. Big, bloated commits (maybe even combining code from multiple, different topics) will sooner or later bite you.
b) Integrating often. I think you can be successful with long-lived branches, but you need to have more discipline and not forget to re-integrate from time to time. Integrating late will naturally raise the risk of conflicts - because, simply, more changes accumulate.
Comments
I guess it's a combination: a) Granular commits are an essential basis of good version control. Big, bloated commits (maybe even combining code from multiple, different topics) will sooner or later bite you. b) Integrating often. I think you can be successful with long-lived branches, but you need to have more discipline and not forget to re-integrate from time to time. Integrating late will naturally raise the risk of conflicts - because, simply, more changes accumulate.
Why have long lived branches at all?
A lot of teams have, for example, a "development" branch next to "master" through the whole project - and are doing fine.
It's a matter of taste and agreement within the team, I'd say.