You Do You: Feature Branching
There’s huge risk of conflict when two developers are working on different features in the same code.
Imagine you are creating a new page template. Another developer is updating the header site-wide.
If you both work and push code to the master branch, there is a potential for conflict. Even worse, imagine the page template is approved but the header changes are not. Reverting to a previous version can be a pain.
Feature branching allows developers to work on pieces of the project separately, so they don't step on each other's toes.
Picture this: We have the master branch with the current code state and both you, creating a new page template, and your co-worker, making updates to the site header, each do so on a separate branch. Additionally, you do a code review for one another. That workflow would look like this:
Approved branches get merged and deleted. If a branch isn’t approved it can be further iterated on or discarded without affecting the master branch.
Branching works great internally, but what happens when a stakeholder needs to check out a branch? You could bring them on-site to look at it, but they would likely prefer a URL to view remotely.
The best way to handle this situation is to set up a dedicated environment, with its own resources and URL, for each feature branch.
This way anyone can view the code in the feature branch or visit the site at the dedicated URL. If the branch environment matches the live environment, there won't be any surprises when you deploy.
Tauno Hogue, CTO, ThinkShout
Regardless of if your development team consists of a single developer or more than a dozen, working with feature branches will save your sanity. By containing work related to a single feature in its own branch, you protect against several key problems: deploying incomplete work, not deploying completed work because it's mixed with incomplete work and conflicts between developers. If you do all development on a single branch then all work on that branch must be complete at the same time in order to deploy safely. How often do internal QA, client approvals, and a lull in ongoing development coincide? Rarely. When using feature branches, you review and test work on the feature branch before merging it back into the release branch. The release branch is then always ready to deploy. A particularly important use case is security updates or other critical hotfixes. If in-progress work is confined to feature branches, a critical fix can be deployed on top of the stable release branch without having to deploy a feature the is incomplete. Not deploying a security update because a developer hasn't finished an unrelated feature on the same branch is just as troubling as deploying an incomplete and untested feature because it's on the same branch as the security update.
For most of our projects we have two primary branches: master for production releases and dev for our ongoing development work. When working on a feature we branch off of develop. After completing and testing the feature we merge back into dev. To deploy a release, we merge develop into master and our Continuous Integration systems deploy the code to the dev environment on Pantheon. If a hotfix/security update is needed we can branch off of master, make the fix, and merge back into master (and later develop). By using a develop branch in addition to master we have a stable release branch and an in-progress branch of all the combined feature work. This branching methodology is a mix of Git Flow and GitHub flow. An added benefit of using feature branches when working with Pantheon is that each branch can easily be demo'd and QA'd on a Pantheon Multidev.
It can take a team of dedicated DevOps specialists to do branching right. Pantheon makes this really easy with our Multidev cloud environments. Environments can be created right from the dashboard with Terminus (our command line tool), or from an existing Git branch.
Each Multidev environment runs on the same infrastructure as the live environment, has dedicated resources, and it's own URL. You can even pull the latest database from the live site, add HTTP Auth to protect some super-secret new feature, and more.