How Feature Flags Can Complement and Enhance Git Branching Strategies

How Feature Flags Can Complement and Enhance Git Branching Strategies

Git is a really powerful and important tool in modern software development. It is a version control system that allows developers to manage code and collaborate on projects. However, as software development evolves and the scale of projects leveraging Git continues to grow, different strategies have emerged to make collaboration more efficient for software development teams.

What are Feature Flags?

Feature flags are tools used in software development to control, test and monitor the release of new features. They are switches included in codebases to turn features on or off without having to redeploy code. Examples of popular feature flagging services are LaunchDarkly, Split and Flagship.

This article will delve into a general overview of Git branching workflows and how feature flags can complement them.

What is Git?

Git was created by Linus Torvalds in 2005 during the open-source development of the Linux kernel. It keeps track of all the changes made to files in a project over time.

Let’s assume you want to use Git to manage your project. You would do so by:

  • creating a new Git repository for the project.

  • creating/editing files, developing features, and fixing bugs as required.

  • committing and merging the changes with the remote Git repository.

The merging process starts by adding the changed files to a staging area and committing them. The staging area is a temporary holding area for the files to be committed. After committing your files, Git takes a snapshot of your repository. Your changes can then be merged/pushed to the remote repository.

Conversely, managing and tracking the status of your project is not the only use of Git. One key feature that makes it powerful is that several developers can use it concurrently to track their development work on the same codebase. This is where Git branching is useful.

What is Git Branching?

Git branching is a technique that allows developers working on the same codebase to do their jobs without interfering with one another. They can create branches either based off the master/main branch or even other branches. All individual development work can be done on a branch. The master/main branch is the default branch in Git. It is created for a project when the first commit is made. A repository can have only one master branch.

After making changes to a branch, developers push said changes to the remote repository in a process called a "pull request." A pull request is a proposal to make changes to the repository. It is a mechanism to control the flow of new changes to the master/main branch. After a pull request is made, the repository maintainers review all the new proposals to determine whether it is ok to merge them. They then fix any conflicts they encounter and merge the changes as required.

Additionally, you can always pull the main remote repository to your local machine to get an up-to-date status of the project.

What is a Git Branching Strategy?

Imagine a software development project with 1000 developers. How can we be assured that pull requests wouldn't cause numerous messy merge conflicts with the main branch? What will the efficiency and speed rate of the maintainers be on this project? These questions prompt the need for a Git branching strategy.

A Git branching strategy is a set of guidelines on branching and merging that development teams follow when working collaboratively on a codebase. Historically, different approaches to Git branching have emerged for the diverse needs of software teams. Some examples of popular Git branching strategies are GitFlow, GitHub Flow and GitLab Flow.

The Role of Feature Flags in Git Branching Workflows

Due to the diverse nature of the software industry, different teams use different strategies to organize workflows based on their project requirements.

We'll discuss how feature flags can complement, optimize or even replace some of these branching strategies.

1. Better Control of Feature Deployment and Release

One way that feature flags complement Git branching strategies is that they allow developers to control the deployment of new features. For instance, if you are working on a new feature in a branch designated for development, you can use a feature flag to control the deployment of that feature to production. This ensures that your team can test the feature in a production environment before it is fully deployed, reducing the risk of errors.

2. Reduce the Number of Branches

Another way feature flags optimize Git branching strategies is by reducing the number of branches on a project. Instead of creating separate branches for different stages of the development process, you can use feature flags to keep fewer branches. For example, one development branch can replace the development and release branches used in some popular branching strategies. That way, features that are not ready for release will be turned off via feature flagging.

3. Keep Pull Requests Small

Feature flags allow developers to merge code to the main branch before features are fully ready for release. This allows for smaller and more manageable pull requests, making them great tools for enabling more efficient code reviews. They help mitigate large pull requests that span several files and thus, are challenging to review.

4. Carry Out Less Messy Canary Deployment

Canary Deployment is a practice in software development where features are first released in stages to a small subset of users and expanded to more users as time passes. Feature flags complement Git branching strategies by allowing developers to do canary deployment without creating several branches for every stage of canary release. This keeps things cleaner and easier to navigate. Many feature flagging services come with a feature management dashboard that makes it easy to do Canary Deployment, even if you're not a developer.

5. Enable Seamless Trunk-Based Development

Trunk-Based Development is a branching strategy requiring no branching from developers. Instead, you are required to push changes into one dedicated branch(trunk) at least once a day. The trunk is always kept in a releasable state. This strategy stems from the idea that many merge conflicts from branching occur when pull requests are not made for long periods, causing the branches to fall out of sync with the main branch. Therefore, pushing code once a day to the trunk is a measure to reduce this risk.

Feature flagging is a vital component of Trunk-Based Development. To push code into a master branch that is always in a releasable state, you need a mechanism to turn off features that cause inevitable problems. Feature flags help you do that seamlessly.

6. Do More Efficient A/B Testing

A/B testing is an experimental process in software development. It is done to test features by showing different versions of a feature to different segments of users. The data collected from users after A/B testing is used to make key feature decisions in the future.

A/B testing can be properly achieved through feature flags. Most feature-flagging products provide user segmentation features that make it easy for you to do A/B testing. This optimizes the alternative approach of keeping multiple branches with different features in the codebase.

Final Thoughts

We talked about a general overview of Git branching workflows and how feature flagging can optimize branching strategies in software teams

Feature flags are flexible and powerful tools that can complement or even replace some aspects of conventional Git branching workflows. They allow developers to control the deployment of new features, test new functionalities, and manage risk in production. Hence, they are fantastic tools that help you build high-quality software more efficiently.

Regardless of what Git branching strategy your team uses, feature flagging is a great technique to effectively manage releases, prevent avoidable errors, and test in a canary deployment.