Feature Branching and Pull-Request Strategy with Git, GitHub and VSCode

When a software development team grows, and we have multiple people working in parallel. Or  even if the team is small, but there are multiple feature changes, the source control versions can quickly become unmanageable with code conflicts. A way to solve this problem is to have developers work on different areas/features of the app.  Even though this helps somewhat, there are still potential problems that can be prevented by following a feature branch and pull-request strategy. This strategy helps us prevent typical problems during the software development cycles. To better understand, let us see what this strategy is about.

Code Repository Branches

As part of the Software Development Lifecycle (SDLC), it is a must practice to use source control software which enables us to track the changes on the software. To isolate the code changes between a development and production version, the concept of branches is used. A branch enables us to track code changes during the development phase and later merge them once that code is deployed to production.

This approach provides the flexibility to create patches from production branch while the development branch is still undergoing changes. The same concept is applicable to the development branch when we want to isolate independent feature changes in which some can be completed much sooner than others.

Feature Branches

A feature branch enables us to isolate code changes for each specific feature.  A “feature” can be a change request, enhancement, or defect fix on the application. A feature branch can also be used to create a software patch from a specific version.  These are often referred as a firefight fix.

The idea behind a feature branch is to create changes or building blocks that are isolated and easily tested independently. For this approach to be successful, we must follow a specific process.

Feature Branch Process

When creating feature branches, we need to adhere a process that is easily repeatable.  In the case of feature development, we want to always create a feature branch from the development branch. Once the feature is complete and ready to test, the code is pushed to the remote repo, and a pull-request (PR) is created which enables the team to run code reviews and merge the code back into development.

Once a feature branch has been merged into development, it is important that all other open feature branches continuously merge back with development to minimize the risk of conflicts. This enables a smooth code merge from multiple feature branches back into the source branch.

Feature Branching with Git

Git is a popular source control management tool that operates on a client workspace. This is not to be confused with Server (remote) Repository like GitHub and Team Services (TFS). The purpose of Git is to clone a remote repo locally and make changes that are only reflected on the local workspace.  For the changes to be available to the rest of the team, the changes must be pushed from a local repo to the remote repo.

When using Git and working on Feature branches, we want to follow a serious of steps that enable us to get the latest changes from the development remote branch and then create a feature branch. We can do this by using Git UI client tools. In our case, we want to use GIT CLI from Visual Studio Code. From VS Code, open a terminal window and let us look at the commands we need to get this done.

Note:  First clone a remote repo and ensure there is development branch. These commands can be done from VS Code Terminal.

 

Command	Description
git checkout development	Checkout the dev branch
git pull origin development	Pull most recent from remote repo
git checkout -b f_featureName	Create a feature branch from dev. This is where the changes are done.
git add -A	Stage all the ongoing changes
git commit -a -m "#id my new changes"	Commit locally all the changes, add comments and possible issue #id
git pull origin development	Pull from development to merge any pending changes from the remote repo
git push origin f_featureName	Push to the remote repo

 

These are the basic set of commands that enable us to create another branch from the development branch. We should notice that for our feature branch we can use a naming convention (f_*) that can easily tell us what the branch is for. Once the branch is created, we can make the code changes and push our new branch to the remote repo.

Note: It is important to continuously merge from development before pushing the changes.

GitHub Pull-Request

After we have pushed to the remote repo, we can now open a pull-request. This is a gated process which signals to the team that a code review and merge should be executed. A PR can be requested from a GitHub project website (branches page) or using GitHub CLI which can be found at this location https://github.com/cli/cli The GitHub CLI is a sorely needed feature that can enable us to easily create PRs from VSC ode terminal.

After a pull request is merged back into the development branch, the feature branch can be safely deleted from both the remote (team - build manager) and local repos (developer).

Summary

Software development is a complex process, and we need to constantly be learning and creating new processes that can increase our productivity by reducing possible downstream problems. The feature branch pull-request strategy is a simple, repeatable, and valuable process of helping teams work with multiple versions of the product and rapidly adapt to changes.

Thanks for reading.

Originally published by ozkary.com