Git Branching and Feature Flags

Use feature flags and smaller pull requests to release code safely in any git branching model

Git has changed how software engineering teams work since 2008, mainly with the start of GitHub. Before a Distributed Version Control System (DVCS) like Git, CVS and SVN were the central VCS choices for development teams.

Picture of a tree with a lot of branches
Picture of a tree with a lot of branches

Git branching models

There are at least three main git branching models. The first popular git branching model is Git-flow. A simpler version is the GitHub flow (or Simplified Git-flow), which has only one perpetual branch. The most simple but much more difficult to do practically is Trunk-based Development, where all the software engineers push to the main (master) branch. Let’s look at how these three git branching models work.

Git-flow

Git-flow has 3 perpetual branches, Master (main), Develop, and Release. Whenever a new software engineer wants to start work on a new task, they branch out the feature branch from the Develop branch. Pull requests are sent to the “Develop” branch. Multiple pull requests could be merged to Develop before deploying, and when it is time to release, a “Release” branch is created.

Diagram of Git-flow model
Diagram of Git-flow model

GitHub Flow

In GitHub flow (Simplified Git-flow or Feature Branching Model), there is only one perpetual branch — Master (main). To start working on a new task the software engineer will take a new branch out from Master. They will do the commits, push the commits to run tests or any other CI builds on the new branch.

Diagram of GitHub Flow model
Diagram of GitHub Flow model

Trunk-based Development

Ever thought about what would happen if all the software engineers in a team push their code to the Master (main) branch? It is called Trunk-based Development. You might think this is a crazy idea but it is not, it’s being used by teams utilizing dependable automated tests, feature flags, and other techniques like pair programming where code is reviewed as soon as it is written. This model does not brush off the idea of code reviews. Like shift-left security reviews are moved to the code writing phase. In other models, the software engineer writes the code, commits and pushes the code, then opens a pull request which paves way for someone to review the code changes async.

Diagram of Trunk-based Development model
Diagram of Trunk-based Development model

Advantages of smaller changes

Ask yourself a question, would you be happy and comfortable to do a code review on code changes of 2 lines on a single file or 700 lines spread across 50 files. Without a doubt, the first one. As the change is small it is easier to comprehend, and given the blast radius is so small the risk for deployment and release is almost non-existent.

  • It accelerates feedback
  • Small changes are reviewed faster which increases efficiency
  • Smaller pull requests are low risk

Use feature flags to keep pull requests small and release features gradually

Even if there is a small feature to develop, it is advisable to have multiple pull requests to get it working rather than a huge pull request that has all the changes in one go. If these changes are some new files or classes with proper unit tests, it is much easier to open pull requests with these isolated files. As soon as the glue code is in place and these new files or even functions are accessible from the user interface, the best way to make them accessible but gated with conditions is by using feature flags.

Other techniques to keep pull requests small

Feature flags are surely a great way to keep pull requests small and leverage all its advantages. There are other techniques as well that enable creating smaller changes that are low risk and aid high productivity. One of these techniques is enabler code last. For instance in most web applications as long as the code is not wired up with a route (URI via a controller) it cannot be reached from outside by the customers. If the software engineers can open multiple pull requests with high test code coverage to other parts except for the route (or controller) these code segments can be deployed but they will never be “released” or executed even though available.

Conclusion

Regardless of which Git branching model our teams follow, smaller changes (or pull requests) are key to releasing software safely and having a high level of productivity. With a mix of feature flags and other techniques we can release software safely to our valued customers once it is tested step by step in multiple iterations by the team and the whole organization on production. Use the right mix of smaller pull requests and feature flags to reach software release zen.

Ship features with confidence. Flagsmith lets you manage features flags and remote config across web, mobile and server side applications.