What do you mean by "unnecessarily branch"? At least for git it used to be "new branch for each discreate task". Atlassian tools even support this: you have "Create branch" option for JIRA task. We use it and are very happy with this. Take a task, create branch (which automatically moves the related JIRA task to "In progress"), when done—create pull request (task status once again is updated automatically), when merged kick off automatic build and deployment. It all would be a lot messier without branching.

I think it really depends on the atomicity of the said "tasks" and how often branches get merged back into the master branch. It's very easy for branches to get abused and merging long-standing branches in with the master branch is always expensive task that's bound to have scary issues.

In an organized enough team with a large enough project, tasks should be able to be carried through concurrently on a single branch for the most part.

> It's very easy for branches to get abused and merging long-standing branches in with the master branch is always expensive task that's bound to have scary issues.

You only get scary merge issues if you do not frequently pull in changes from your upstream branch! Daily works for me, and not once have I been let down when squash-merging back - even for large, multiweek changes. I'm always surprised to hear this is not common practice on HN.

Yes, this is a good point. Branching goes against "continuous integration" principle. It reminds me when back in the day every developer had his/her on copy and everything was put together at the end.

Branching is very useful, but you need to continuously merge, so you find conflicts as soon as they arise.

If branches live too long that's usually a symptom of a deeper team dysfunction. They haven't done a good job of breaking down large user stories into small, discrete user stories.