The use of branches within a version control system is a risk management technique. They are commonly used to minimise the risk of unanticipated side-effects when releasing critical changes to production, or to minimise the disruption to developer productivity when making changes to the base product. But branching is not the only means of managing risk and that is what this talk addresses – the forces that drive the use of branches, what are their problems, and what are the alternatives.
Branching during the evolution of a software product, either its over-use or complete avoidance, is just as susceptible to the malaise of the "cargo cult" as many other areas of development. The choice is not always made based on an informed decision with a careful weighing up of the pros and cons and their alternatives, but purely by following what practices the "cool" companies are (seen to be) using.
What is often misunderstood is how the same risks that historically have been mitigated through the use of branches might now be handled via the use of other, non-version-control related practices to ensure stability and productivity remains high in the face of continued change. Whilst there is still a time and a place for the use of branches we will discover when that might be, but equally spend as much time exploring the complimentary practices that help us to avoid their pitfalls.