Feature Branch Workflow

The Fea­ture Branch Work­flow is a nat­ur­al next step after using the Cen­tral­ized Work­flow. It still has a cen­tral­ized repos­i­to­ry but gives devel­op­ers a slight­ly dif­fer­ent approach to doing their devel­op­ment work.

Here are the main ten­ants behind the Fea­ture Branch Workflow:

  • All cod­ing work on new fea­tures or changes should take place in a branch spe­cif­ic to that set of fea­tures or changes. These branch­es are calledfea­ture branch­es.
  • The fea­ture branch­es should be named accord­ing to a con­ven­tion agreed upon by the team. E.g. feature_the-feature-name or feature/the-feature-name
  • By encap­su­lat­ing the fea­ture work in its own branch, this keeps the master branch pure and unaf­fect­ed by fea­ture cod­ing that may or may not be stable.
  • The fea­ture branch approach also makes it eas­i­er to imple­ment code reviews and/​or test­ing pri­or to merg­ing a new set of changes in to the master branch.

Step-by-Step #

Here’s a work­flow step-by-step for using the Git Fea­ture Branch Workflow:

  1. A devel­op­er clones the cen­tral repos­i­to­ry using git clone origin master, which cre­ates a local copy of the repos­i­to­ry. If the devel­op­er already has the repos­i­to­ry cloned then she can run git pull to bring down any changes.
  2. The devel­op­er then cre­ates a new local fea­ture branch so she can being doing her work on a new fea­ture of the appli­ca­tion. To do that she uses: git checkout -b feature_my-new-feature master The git-checkout com­mand cre­ates and checks out the new branch, which is based on the master branch.
  3. The devel­op­er now works on her fea­ture, cod­ing in the new branch until her work is com­plete, and cre­at­ing a series of com­mits along the way. She cre­ates as many com­mits as nec­es­sary to prop­er­ly doc­u­ment her work and cre­ate trail of changes that can be eas­i­ly undone, if necessary.
  4. Once her fea­ture cod­ing work is done, she push­es the fea­ture branch up to the remote serv­er using git push -u origin feature_my-new-feature. This will cre­ate the fea­ture branch on the remote serv­er, which also hosts the master branch. The -u flag cre­ates the branch as a track­ing branch, so the devel­op­er can lat­er sim­ply run git push to push changes up to the remote server.
  5. The devel­op­er can either request some­one else pull down her branch and review her changes and merge them into master (this is typ­i­cal­ly called a pull request” and is some­times built into tools like Github) or merge them into master herself.

Some teams that move from Sub­ver­sion to Git switch imme­di­ate­ly to the Fea­ture Branch Work­flow but it’s also a nor­mal prac­tice to move to it only after becom­ing com­fort­able work­ing with Git using the Cen­tral­ized Workflow.