What Is a Feature Branch + How They Improve the Dev Process

Updated: July 21, 2023

Is keeping your codebase stable a vital thing for you and your team?

What about the possibility of multiple developers working on a particular feature without disturbing that codebase? Is that important to you?

Features under development can create instability, resulting in highly disruptive work if it’s all done on the main code line. That’s where feature branches come in. This article explains what feature branches are and the advantages and disadvantages of using them.

Additionally, you’ll learn how to optimize, scale, and reduce bottlenecks for feature branches with development environments from Bunnyshell’s EaaS platform. We’ll also look at some FAQs towards the end.

When developers write code, they’re writing it on a branch. When several developers work on the same code base, it becomes difficult to add, modify, or erase code without their work overlapping or overriding each other’s changes. 

The idea of a feature branch involves an individual or a team of developers creating a clone (1:1) branch leading from the master branch in which they can make modifications. It’s best to think of the analogy of a tree, where there’s a master branch (the trunk), and there are copies of the codebases (the branches). 

Merging is the process of incorporating any changes made to feature branches back into the master branch. So when the team deems the feature branch ready after a thorough review, it’s merged exactly where you left off last in your master branch. The feature branch can pinpoint the difference between the current branch point and the most common ancestor (the master branch from which it left) and applies the changes to the current master branch. 

Github, Gitlab, and Bitbucket are all version control software that manage feature branch development and merging. Feature branches live in a code repository, and developers can check out code to create a new branch with which to work. The developer then makes a pull request once changes are made to the code, so other developers can review the code to ensure there are no errors with the branch and no issues will occur once merged with the master branch. 

Developers can collaborate efficiently by focusing on the changes within their respective branches without interfering with other developers or overwriting each other’s work and reaching the desired result. Although developers work independently on separate branches, sharing changes with other developers when necessary is critical for feature branches. 

Developers can easily pull down other developers’ changes to collaborate on features and ensure their branch doesn’t stray too far from the master. Additionally, since each bug lives within its own branch, agile teams can use feature branches to see which issues are in progress and which ones are ready for release. This is where other developers can review any changes before merging to the master. 

The master branch is constantly changing because developers merge their feature branches as they deem fit. Although developers can work with feature branches in isolation for stability, this can lead to long-lived feature branches which aren’t frequently merged with the main code base, resulting in merging conflicts. Merge conflicts are bound to happen, but you want to reduce their impact and overall size. The more time you have to spend on merge conflicts, the less time you can spend on developing. This leads to lost revenue, release delays, and disappointed stakeholders. 

To avoid all these issues, developers should merge early and often. Doing so not only keeps the feature branch up to date but also increases velocity. Within the feature branch workflow, continuous integration also helps to minimize merge conflicts by continuously integrating new code changes into the master branch rather than waiting for the development of a feature branch for weeks or months. But remember, continuous integration is a hassle if you need to roll back changes, so it should not be a day-to-day practice. 

The later you find a bug in your release cycle, the harder and more costly it is to fix. Ideally, you should create an environment for each feature branch so you can test in isolation, but this also becomes rather costly and impractical. To find bugs as early as possible, you’ll need a proper CI/CD workflow to increase overall velocity and decrease the number of broken builds, especially later in your release cycle.   

In your different environments, whether it’s a staging environment or you’re doing UAT testing, you can deploy the different branches that you’re working on. However, this is where bottlenecks can appear because you may have the developers or QA testers available, but there’s a wait for testing. You can’t deploy or test however much you’d like. Say you have 20 environments but 40 branches or 300 developers, so there aren’t enough environments to test on. 

Creating more environments is not only time-consuming and costly but requires the skills of your DevOps team and constant maintenance afterwards. It’s also not practical to have too many environments that are simply sitting around either. To avoid this issue, you can use development environments from Bunnyshell’s EaaS platform. Here’s how that works:

If you don’t have a solution written by you that would periodically sync all of your environments, things become more complex. Changes appear within the master branch that need additional columns or lines, for example, which you have to maintain. Otherwise, your app may crash. One can say that it creates a friction point. 

With development environments from an  Environments as a Service (EaaS) solution, you leave from point A in your master branch, and you can leave from that same point going forward. If you want to move that starting point closer to the master, you’re able to do so. Without an EaaS platform, it becomes challenging, expensive, and time-consuming to optimize branches manually. 

It’s important to note that EaaS works as an accelerator for feature branches, not an enabler. EaaS gives you greater flexibility and eliminates any waiting times, plus gives you the ability to quickly and easily create environments while allowing you to see your branches in parallel without environment limitations.

Using feature branches allows teams to reach an important goal of an agile process - rapid integration of changes to minimize unknown risks. You’re able to release bug-free code faster and more efficiently, and stakeholders are satisfied. Remember, incorrectly branching slows a team down, so find the ideal merging frequency for you and your team. For some teams, merging once a day is enough, while others prefer to merge more often. The metric that matters is how long it takes to merge to master.

Yes, although the overhead from them is almost nonexistent. It’s good to delete feature branches due to cleanliness. Once used, delete the branch, so it doesn’t clutter up your list of branches, and you can focus only on your work-in-progress branches. Deleting them will also keep you from reusing the branch. Single-use, short-lived branches simplify the process by ensuring you only merge to the master branch once. If you need to fix a bug or issue from that (just-merged) branch, simply treat it as a bug in master and create a new branch to fix it. 

A feature branch should be deleted as soon as the merge happens in the master. Any previous changes that you made will remain in your Git history. Your tools like Github and Gitlab have the option to delete your feature branch as soon as the merge happens.  

Once you have a formal merge approval, you should merge after a code review and after all issues are resolved. Depending on the system configurations or tool, you work with either pull requests or merge requests. These requests allow other developers to review the code to ensure there are no errors within the branch. You’re able to leave comments, have traceability of changes, even go “back in time” to see why certain decisions were made and if there are discussions about that. By sending either a pull request or a merge request, you’re asking a reviewer to look at changes prior to merging them into another branch. 

It’s just a command in Git - dev minus payments, for example. The master will connect between the combined version (between master and payments in this case) if there are no conflicts. 

Feature branching allows teams of developers to collaborate inside one central code base - the master branch. For some developers, merging is scary, but version control systems help with merges and keep the master branch stable. Remember, an EaaS solution helps immensely in creating environments efficiently to allow you to test your feature branches and see your environments in parallel.

Bunnyshell has the perfect EaaS for you, the easiest and fastest way to get sharable environments with each pull request and keep everyone in the loop.