Feature Branch Workflow

Name: Mijingo, LLC
Price range: $

Question

Accepted Answer

The Feature Branch Workflow is a natural next step after using the Centralized Workflow. It still has a centralized repository but gives developers a slightly different approach to doing their development work.

Here are the main tenants behind the Feature Branch Workflow:

All coding work on new features or changes should take place in a branch specific to that set of features or changes. These branches are calledfeature branches.
The feature branches should be named according to a convention agreed upon by the team. E.g. feature_the-feature-name or feature/the-feature-name
By encapsulating the feature work in its own branch, this keeps the master branch pure and unaffected by feature coding that may or may not be stable.
The feature branch approach also makes it easier to implement code reviews and/or testing prior to merging a new set of changes in to the master branch.

Step-by-Step #

Here’s a workflow step-by-step for using the Git Feature Branch Workflow:

A developer clones the central repository using git clone origin master, which creates a local copy of the repository. If the developer already has the repository cloned then she can run git pull to bring down any changes.
The developer then creates a new local feature branch so she can being doing her work on a new feature of the application. To do that she uses: git checkout -b feature_my-new-feature master The git-checkout command creates and checks out the new branch, which is based on the master branch.
The developer now works on her feature, coding in the new branch until her work is complete, and creating a series of commits along the way. She creates as many commits as necessary to properly document her work and create trail of changes that can be easily undone, if necessary.
Once her feature coding work is done, she pushes the feature branch up to the remote server using git push -u origin feature_my-new-feature. This will create the feature branch on the remote server, which also hosts the master branch. The -u flag creates the branch as a tracking branch, so the developer can later simply run git push to push changes up to the remote server.
The developer can either request someone else pull down her branch and review her changes and merge them into master (this is typically called a “pull request” and is sometimes built into tools like Github) or merge them into master herself.

Some teams that move from Subversion to Git switch immediately to the Feature Branch Workflow but it’s also a normal practice to move to it only after becoming comfortable working with Git using the Centralized Workflow.