Feature branch

What is a feature branch?

A feature branch is a copy of the main codebase where an individual or team of software developers can work on a new feature until it is complete.

With many engineers working in the same code-base, it's important to have a strategy for how individuals work together. To avoid overriding each other's changes, engineers create their own copy of the codebase, called branches. Following an analogy of a tree, the master branch is sometimes called the trunk. The process of incorporating the changes of an individual's copy into the main master trunk is called merging.

Feature branch development process

In feature branch development, individual engineers or teams of engineers do not merge their branch until a feature is complete, sometimes working for weeks or months at a time on a separate copy. This long stretch of time can make the process of merging difficult because the trunk or master has likely changed due to other engineers merging their branches. This is known as a merge conflict.

Feature branch development and merging source code is handled in version control software such as Git, most commonly known as the service Github. The main branch and feature branches live in this code repository (or repo) and developers checkout code to create a new branch to work from.

Once the changes are made to the code, the developer makes what is known as a pull request, or a request to have other developers on the team do a code review to ensure that the local branch does not have any errors, and also that it will not cause any errors when merged into the main branch. Once a branch has been thoroughly reviewed, it can then be merged into the main branch and become part of the mainline repo.

Git branch development is one method of managing many engineers working off of the same codebase. Modern teams often rely on continuous integration and trunk-based development to avoid issues with bug fixes and merge conflicts that arise from the branching model of code development. This helps prevent issues with multiple people working on the same codebase, and keeps a detailed log of which bit of code was added by who, when and where. This process is also known as rebasing.

What to do in case of issues with a feature branch

One of the benefits of developing in a feature branch, is it’s not impacting your mainline code until you merge it back in. Using a git workflow, you can roll back to previous versions using the version control features.

Here are a couple of common git features to help diagnose and rollout a hotfix

Use git pull to download the latest code from the main branch. If you’re pulling from the main branch, this command is a synonym for git pull master origin.
Use git push to send back the code you’ve updated to your development branch.
Git branch was likely the command you ran to branch off from your main branch.
Git checkout allows you to switch to different versions of a branch. This tells Git to which version you want to record changes you’re making to code before pushing it back out.
Git merge is essentially the opposite of a git branch, allowing you to merge your changes back into the mainline code you branched from and cleaning up by removing your branch.

Using these commands devops team can evaluate their development work and use the version control system to debug specific versions and roll back where needed. If you’re in an organization with many team members working on the same codebase and using feature branches, this can help diagnose issues quickly.

Why use branching strategies

Using feature branches isolates each feature into it’s own separate area, monitored by the version control software (commonly git). This allows work on new, experimental features without impacting the mainline code directly, but still pull down any new versions and updates that might have happened while you were working on the new feature. This is especially helpful in teams where multiple team members are working on the same central repository of code.

A separate branch isolates issues and developments into a release branch, that can be merged back in when done. Having a git workflow and clear lines of communication between developers and engineers can help remove conflicts, and allow different branches of code to be developed at the same time without interfering with one another.

As part of a branch strategy, it’s important to not only focus on the gitflow, but also feature branch workflow practices like branch naming conventions and code review. The version control is exceptionally helpful functionality, allowing multiple team members to review code before it’s pushed out.

Some common naming conventions for feature branches:

Be descriptive, which feature is being
Be short, use no more words than necessary. If more explanation is needed, add it to the description
Write it in a way other developers and engineers can understand what’s being worked on

Even if you’re working on multiple new features at once, its still good practice to make branches for each particular feature so they don’t conflict with one another.

When ready, use a pull request to have other team members review your code and merge it back into the central repository. It is bad practice to merge and review your own code. There can always be unforeseen issues with your particular feature that others might be able to catch in review.

Continuous integration and feature branches

One alternative to the feature branch workflow is continuous integration, which is a software development methodology which involves continuously integrated new code changes into the mainline or trunk rather than waiting until a new feature branch has been under development for weeks or months and has diverged from the main branch.

Continuous integration, also known as trunk-based development helps to minimize merge conflicts by continually merging changes into a single source to prevent feature branching. Continuous integration, along with practices such as feature flagging can help developers to deploy code faster with less time spent trying to reconcile different versions of code.