Skip to content

Instantly share code, notes, and snippets.

@chaitanyagupta

chaitanyagupta/long-lived-feature-branches.md

Created August 30, 2021 20:08
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save chaitanyagupta/fe43d0802d0f2d0df4a8586866363a85 to your computer and use it in GitHub Desktop.
Save chaitanyagupta/fe43d0802d0f2d0df4a8586866363a85 to your computer and use it in GitHub Desktop.
Download ZIP
Why long lived feature branches are harmful
Raw
long-lived-feature-branches.md

You will find a lot of material online for why long lived feature branches are harmful. Intead of deferring to one of those articles, I wanted to highlight why I believe they are harmful, and why they are an unsustainable practice for most software projects.

In projects where long lived feature branches are the norm, the code in the feature branch is effectively silo'ed from development happening in other branches. This has two effects:

  1. you cannot test how code in the long lived branch plays with other code under development
  2. painful merge conflicts become a recurring event when the long lived branch gets merged into the mainline

To handle these issues, it is generally recommended to merge the mainline into your long lived feature branch on a regular basis. However, the catch is, if all feature development happens on long lived branches, there won't usually be anything new in the mainline apart from small fixes. Since all features sit in their own long lived branch, you cannot see how your branch will play with those other branches (since they are not in the mailine). Nor can you pre-empt any merge conflicts with those branches (since, again, they are not in the mainline).

The end result of this is - there can only ever be one long lived feature branch in any repo. The moment you have more than one, these issues become unavoidable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment