Branching is a great way to manage changes in a collaborative software development environment. Today, almost every team working on complex software projects uses branches. So why is branching such a big deal, and when is it most useful?
Collaborating in a complex environment
In an environment where multiple team members (and sometimes, even several teams) are working on a single software product, using a shared code base is sure to lead to chaos. Remember the days before Google Docs, when dozens of people would work on the same Word doc? That file would be exchanged back and forth, and very often, you’d see an otherwise calm team member smacking the desk in a fit of rage when their changes would be reverted because someone made edits to a previous version.
In the case of software code, the situation is even worse: you can’t reasonably expect all those developers to build 100% correct code all the time. And even so, when developing a new product variant or adding a new feature to your product, there’s some chance that the new feature might break some of the existing, working code, so integrating code is another sensitive point.
Related reading: Strategies for Efficient Product Line Engineering
Branching, in a nutshell, enables you to maintain a main line of development (called a master branch or development trunk), and diverge multiple development branches off that main trunk to experiment. While branching has been around for a while, it was Git that really made it an easy, everyday practice.
How branching works
Before Git, developers would be wary of creating new branches because of its almost prohibitive resources and time costs. In Git, however, branching is a whole different business: you can very easily create new, lightweight development branches, and switch between them just as simply. For software developers working with Git, branching (and merging) is a daily activity.
When a developer creates a new branch, they essentially copy the code from the main trunk, and continue to make any edits to that codebase on their own branch that is isolated from the master branch. Once they’re done, they merge the content of their individual branch back to master – or, lacking the necessary permissions, request that their code is merged. This way, the user reviewing all merge requests has a chance to make sure that these commits won’t break anything.
It’s easy to see the value of branching in software development: it allows several users to share and work on the same source code at the same time. Some can be fixing bugs, others will be working on new features, yet others may be thinking about some experimental project they want to test. Using branches, they can all work on the same code, at the same time.
Branching in ALM
So branching in the context of building source code is nothing new, really. But when it comes to managing the entire software development project, branches present a new problem.
If you’re managing projects manually (e.g. using issue trackers, Excel sheets, and the like), do you just duplicate all items to stay on top of all the changes in all your branches? How do you maintain traceability? And if you’re using Application Lifecycle Management, how can your team manage branches within the tool?
codeBeamer ALM’s answer to this problem is its own branching functionality that was inspired by Git. With codeBeamer, you can maintain consistency between source code and project (ALM) artifacts, making sure that there’s no discrepancy between your source repository and the way it’s represented in your ALM platform.
Using codeBeamer, you can very easily create branches starting with your requirements, ensuring the same level of transparency and traceability on your branches that is guaranteed on your master trunk. Branches can be easily compared to see all the differences. Just like in Git, your developers can easily request the merging of their branches to the master trunk, so that project managers can simply review the changes they made before a commit is made.
Adding to the usefulness of branches, you can easily create baselines in codeBeamer ALM. Baselining your branches lets you essentially travel back in time, making sure that no changes on any of your branches go unnoticed and untraced.
In essence, codeBeamer ALM’s branching functionality provides the same support for collaboration and traceability on your lifecycle artifacts that Git’s branching brings to source code. Their combination is a powerful tool for efficient software development, and supports product line engineering to help the development of multiple product variants.