A long running branch is usually a feature branch that is worked on over a long period of time. Just committing everything to master is asking for trouble.
IMO working on long running branches is asking for trouble. Specifically, it discourages refactoring, as it's impossible for any one developer to grasp how any change would affect his colleagues.
If everyone works in master, you try it, run the tests, and if they're green, you know it works for everybody. You don't risk breaking feature branch X that did a refactoring in a different direction in an overlapping area.
Of course, this implies that you adhere to a CD/CI philosophy. Code always compiles, all test always pass. If your process involves code being uncompilable, unintegrable or test breaking for substantial periods of time, you'll need branching.
Which is why you have configuration switches to turn them on and off. The tests ensure that they don't mess with existing features, the switch makes sure the users can't see them.
So you end up with a bunch of commits in a random order relating to different things.
Lets say person A and person B are working on two features both committing to master.
Person A commits some work to master and pushes to origin. Person B commits some work and pushes to origin. Repeat this a few times, now you want to scrap the feature person A is working on. How do you cleanly handle this?
If everyone works in master, you try it, run the tests, and if they're green, you know it works for everybody. You don't risk breaking feature branch X that did a refactoring in a different direction in an overlapping area.
Of course, this implies that you adhere to a CD/CI philosophy. Code always compiles, all test always pass. If your process involves code being uncompilable, unintegrable or test breaking for substantial periods of time, you'll need branching.