Some historic background (from my point of view):
Back in the days of svn, mainline development was the most feasible way of writing code in a (distributed) team. Branching (and merging) was not so easy and often made things worse. Working on the mainline was a real pain in the ass: you don't want to commit stuff that could break the build, so your commit grows and grows until all the bits and pieces are there to fully increment the code and reach a buildable state including your feature.
With git many teams switched to a feature branch development, where every feature got its own branch, where you can commit often and early (since it only breaks your local build and does not affect others) and where you merge the branch once the feature is ready to release.
Martin Fowlers article made me realize that feature branch development has its downsides as well. If you work with a bunch of colleagues on one product and you work on that product 8h a day, merge conflicts will be quite common. When you have a branch and work on it for a couple of days, the merge becomes a bigger risk with every minute. But since I cannot tell the story as good as Martin Fowler, read his article.