The Problem with Feature Branches
Tags: devops, programming, discuss, productivity
Published: 2022-06-20 07:07:26


As more companies strive to deliver software faster it becomes clear what legacy processes are slowing them down, one of these is Feature Branching.

The use of Feature Branches separates work, increases the size of code changes, and prevents Continuous Integration. You may need to reconsider the use of feature branches if you:


- Keep getting stuck with large merge conflicts;
- Are racing other developers to merge code; or
- Are not committing to your main branch in git.


## Why are they Incompatible?

**Feature Branching** is the process of creating a branch per feature and is used in Gitflow [https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow). The process of using a feature branch is:


1. Create a Feature Branch for a new feature.
2. Make changes until the feature is complete.
3. Merge the feature branch into the main branch.


![Feature Branching](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3b7ge06san7iyjnjfon7.png)

**Continuous Integration** is the process of merging all developers’ code changes frequently [https://www.thoughtworks.com/continuous-integration](https://www.thoughtworks.com/continuous-integration). It can be followed by committing changes to a single branch. This process is:

1. Make a code change.
2. Commit the change to the main branch.


![Continuous Integration](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kd9vigc0595ioedcxclv.png)

**These two processes are incompatible** due to the difference in change duration. Continuous Integration is expected to be done at least daily, whilst a “Feature” is usually expected to take many days and sometimes weeks to complete.

On one hand, if you were to create Feature Branches daily then the developer’s work to constantly create branches and merge them is a waste.

![Feature Branch Waste](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xa31i9l4lnkt65gy8crx.png)

On the other, if you were to leave Feature Branches separate for multiple days then you cannot follow Continuous Integration.

This is why Feature Branches are not compatible with Continuous Integration.

So …

## What is the Alternative?

**Trunk Based Development** is the process of using only a single version of the code. All developers can follow this process by not using branches.

To embrace Continuous Integration and take steps toward Continuous Delivery the Feature Branch habit must be stopped.

Next time you `git checkout -b feature-xyz` consider breaking that habit and allowing yourself to deliver better software faster by Continuously Integrating your code instead.

If you would like to discuss this further please contact me on **Twitter** [@BenTorvo](https://twitter.com/BenTorvo) or **Email** [ben@torvo.com.au](https://torvo.com.au/)

## FAQ
**Q. What are branches for if not used in the regular development lifecycle?**

A. Branches can be used for “untrusted contributors” that want to suggest changes to the code base.

**Q. How can you make changes without breaking the whole codebase?**

A. One recommendation is to use Feature Flags to allow half-implemented features to be accessible when required or only by authorized users.