Version control introduces the concept of branches — isolated working environments for developers to make and test changes. With multiple developers working in parallel on new features, it can be easy for branches to proliferate in the repository. This should be avoided as it:
increases the chance of long-running branches hitting merge conflicts when they are released
makes it harder for developers to find the correct starting point for new features
slows down repository access and management.
Keep branches small and short-lived
Branches should be used to represent a single deliverable request from the business, such as a new feature, user story, or bug fix. Include the minimum viable number of changes in any one branch and nothing more.
Branches should be deployed as soon as their development work is ready for testing and release. The longer a branch exists without getting merged, the greater the risk for merge conflicts and deployment challenges.
There are two approaches to managing branches created during development.
Deleting branches on merge
Branches are deleted from the central repository as soon as they are merged into master. This keeps your repository simple and easy to maintain. If a bug or change is discovered during testing, the branch can either be reverted through your version control system, or new commits pushed from the local developer environments.
This works well for smaller changes that are released more frequently, and is the process the Gearset team uses for our internal development.
Deleting branches on deployment
Branches are deleted upon deployment to production. This makes it easier to make changes to a feature while it goes through testing, but care should be taken to delete the branch after the final release, to avoid redundant branches cluttering up the repository.
This approach works well for larger, more complex releases, which may be on a slower release cadence.