In many companies, branching and merging are done to retain flexibility when releasing a new version and being able to pick changes for that version only at the last moment. This flexibility comes at the cost of having to merge or integrate your changes at some point. This cost is not only the time it takes but also the risks that a merge operation introduces. Merging the changes from two different branches that contain perfectly working software might still produce non-working code.

For this reason, you might consider switching to trunk-based development. In trunk-based development, you are no longer using branching for picking changes that go into a version. Instead, every developer on the team continuously works from the same branch (often the master) and only creates a short-lived branch for preparing one single change, which is then merged into the master branch.

When you adopt this, you will need another way to determine which changes will and won't yet be available to your users when releasing a new version of your software. You can do this by using branching by abstraction.