Branching is a great workaround for problems elsewhere in the system that we are unable or unwilling to fix.
- Maybe the code is highly unstable and we’re worried that one person making a change could cause other peoples code to break so we can branch to provide some isolation while we’re working.
- Maybe we’re unable or unwilling to collaborate with other people so we can branch and work by ourselves.
- Maybe we don’t trust other people on our team so we can force them to work on a branch and go through an explicit review step before their code gets back to the mainline.
- Maybe we just hired someone new and we don’t have time or interest to work with them to get them up to speed. We can put them on a branch and let them thrash around in the code on their own, in a way that doesn’t affect anyone else.
Alternatively, instead of looking for workarounds, what if we actually fixed the other problems in our system instead?
What if we improved the stability of the code? What if we began to truly collaborate? What if we took steps to start building trust within the team? What if we actively worked with new people to get them up to speed faster?
If we did those things then we might discover that we don’t need branches anymore. We might find that branches are just waste and that we’d be more effective if we all developed on the mainline, all the time1.
This is called Trunk Based Development and companies that are really effective, are already doing it.
See also:
-
There will always be exceptional situations where a branch is really the right answer. I’m talking about the common case here. There is no need for branches for typical new feature development. ↩