With Git, There are no hard and fast rules on when you can/need to create a branch. You can have your own technical, managerial, or even organizational reasons to do so. Following are a few to give you an idea:
- A branch in development of software applications is often used for self learning/experimental purposes where the developer needs to try a piece of logic on the code without disturbing the actual released version of the application
- Situations like having a separate branch of source code for each customer who requires a separate set of improvements to your present package
- And the classic one – few people in the team might be working on the bug fixes of the released version, whereas the others might be working on the next phase/release
- For few workflows, you can even have separate branches for people providing their inputs, which are finally integrated to produce a release candidate
Following are flow diagrams for few workflows to help us understand the utilization of branching:
- Branching for a bug fix can have a structure as shown the following diagram:
This explains that when you are working on P2 and find a bug in P1, you need not drop your work, but switch to P1, fix it, and return back to P2.
- Branching for each promotion is as shown in the following diagram:
This explains how the same set of files can be managed across different phases/promotions. Here, P1 from development has been sent to the testing team (a branch called testing will be given to the testing team) and the bugs found are reported and fixed in the development branch (v1.1 and v1.2) and merged with the testing branch. This is then branched as production or release, which end users can access.
- Branching for each component development is as shown in the following diagram:
Here every development task/component build is a new independent branch, which when completed is merged into the main development branch.