It is difficult to envisage an application development without thinking about its life cycle: versioning – which allows to manage in parallel different versions and evolutions of a project – has become essential for the majority of developments.
When there is a need to maintain multiple versions of an application, it is important to define an effective and clear strategy, especially if development teams are large.
The “Feature Branch  ” method is an approach that consists in creating a new branch for each feature that will be developed. This allows each developer to work in isolation, without disturbing or being disturbed by changes that may take place on the common core. Then, when the functionality is ready, it can be integrated (make a merge) into the main branch. The main branch thus remains stable.
 Git Feature Branch Workflow is an overlay that allows you to apply this approach with Git.
If the above diagram is relatively simple, it can also be illustrated as a framework for a more consistent development:
However, if Feature takes a long time to develop, it will be difficult to detect integration problems quickly, which is contrary to good continuous integration practices: the longer the developments are done in isolation, the more work to obtain a stable version, which passes continuous integration tests, will potentially be heavy. Isn’t this the opposite of the philosophy of continuous integration, whose foundation is to test the code as frequently as possible, in order to get feedback on the quality of developments as soon as possible?
Another approach, called “Trunk Based”, mainly prevents hair from being pulled out during the merges. The principle is simple: everyone develops and submits their changes on a single branch, the Trunk. When there is a need to release, you can manually select certain portions of code (cherry-pick) to integrate them. Release branches are never reinstated on the main trunk. Commitments are made in a short and frequent way, in small steps.
We notice here that this type of workflow is totally compatible with the spirit of a continuous integration project: when all developers make regular commits several times a day on the common core, it facilitates integration tests. If something doesn’t work, the team is notified very quickly. And rollback, or refactoring, will not be as expensive as after several days or even several weeks of isolated development.
For example, we can mention Google, Facebook, Microsoft (Office teams) and Amazon, as companies that base their developments on this type of approach.
Finally, if you wish to explore the subject, you should know that other approaches are possible to bypass the issues presented here, while maintaining parallel developments. We can mention in particular the branches by abstraction, the concept of Feature Toogle, or more simply the creation of branches with a very short lifespan.