Sometimes, You Just Need to Slow Down

the team merges the task branch back into the active development line so that the new functionality is available for the next release.

Creating a branch has the advantage of isolating the new feature work from the main line work, allowing those working on the task branch to control when to accept changes from the active development line, and allowing those working on the main line to work in blissfull ignorance of the change occuring on the task branch.

Even with the benefits of isolation that branching provides, branching has a bad reputation in some circles. It's considered difficult, and branching sometimes leads to duplication of effort when there is a requirement for a change on both the main development stream and the task branch. In most cases, given modern tools, branching (creating a branch) isn't all that bad. What is problematic about branching is merging changes between branches.

While some tools are better than others, merging still requires an understanding of the intention of the person making the change on both codelines to decide what the right end result is.  If the team on the task branch is really doing major restructuring of the code, some changes from the mainline would not make sense to integrate into the branch -- for example, a change to a Java class in the main line might be difficult to reproduce in the task branch if the class  disappeared as a result of the refactoring.  There are approaches to minimize the risks of a large merge. The Task Branch Pattern recommends that you merge the integrate changes from the main line into the task branch frequently. This eases the difficultly of merging because the amount of code change is less the more frequently you integrate, and the odds of understanding the intent behind the changes on each code line are higher because the activities are more fresh in everyone's memory. Frequent integration does not address the difficulties that will happen as time passes, the codelines diverge, and the odds of understanding how mainline changes fit into a task branch where a major refactoring is going on become less.

When you have development streams that are truly parallel, branches provide the level of isolation needed for parallel work to go on in a stable fashion. A Release Line [SCMPatterns], which is a branch created to support a released product version, is a perfect example of when branching is the right answer for a team. On the release line, there are stricter rules about what can change, and the focus of the release line is on stability, perhaps at the cost of a slower rate of change. Some changes to the release line may need to be effected in the ongoing development stream. Some may not.

Branching, by its nature, increases isolation, and whenever you work on a branch, you are putting off the time when you integrate the changes into the main line. Integration deferred is integration denied in some sense. Sometimes the isolation makes sense, mostly to keep the mainline stable, but if your default way of increasing stability is to branch, your gains may be short-lived, as once you integrate the changes among branches, you may see problems that no one on the team can fully understand the causes of.

A Lean Alternative - "Branching without Branching"
An alternative to a task branch is to work on the active development line and introduce changes incrementally while maintaining a working system. This has the risk of introducing breakage to the codeline if the work is not done carefully, but there are ways to