Project Ramon

A learning journey from a Ruby noob perspective

Git Branching Model [Support Branches ]: A look at the Feature Branch

feature_branches_header_img

Hello and happy Monday!

In last Wednesday’s post we covered an introduction into the Git branching model. We covered one of several models for organizing our Git workflow. The two types of branches we mentioned were Main branches-which was covered Wednesday-master and develop, and the second type of branch we will be covering this week are supporting branches.

Support Branches

Here are the three support branches we’ll be covering:

  • Feature branches
  • Release branches
  • Hotfix branches

It should be mentioned that there is nothing technically special about any of these supporting branches. They are just plain old Git branches organized by how we will use them. These support branches will always have a limited life-span since they’ll eventually be merged and removed.

Today we’ll be focusing on the first support branch, the Feature branch.

Feature Branches

Let’s first list off the mechanics of this branch:

A Feature branch…

  • May branch off from: origin/develop
  • Must merge back into: origin/develop
  • Branch naming convention: Anything except master, develop, release-* or hotfix-*

A feature branch (aka topic branch) is used to build new features for the next release or a release in the distant future. When we start developing a feature, the target release in which this feature will be incorporated could very well be unknown at this point.

The essence of a feature branch is that it will exist as long as the feature is in active development. It will be merged eventually back into origin/develop (which adds the new feature to the upcoming release) or discarded (like when you receive direction from a client that this feature isn’t needed).

Creating a Feature Branch

  • When starting on a new feature, make sure to create this branch from the origin/develop branch.

    git checkout -b my_feature_name develop
    
  • When incorporating a finished feature on develop, you can merge them into origin/develop which will add them to the upcoming release.

    git checkout develop
    git merge --no-ff my_feature_name
    git branch -d my_feature_name
    git push origin develop
    
    1. The --no-ff flag will cause the merge to always create a new commit object, even if the merge could be performed with a fast-foward. This avoids losing any information about the historical existence of a feature branch and will group all commits together added to the feature.

      Conclusion

      In my next post, we’ll be covering Release branches.

      Stay tuned…

      Advertisements

      Categories: Newbie, Versioning

      Tags: , ,

      1 reply

      Trackbacks

      1. Git Branching Model [Support Branches]: A Look at the Release Branch | Project Ramon

      Leave a Reply

      Fill in your details below or click an icon to log in:

      WordPress.com Logo

      You are commenting using your WordPress.com account. Log Out / Change )

      Twitter picture

      You are commenting using your Twitter account. Log Out / Change )

      Facebook photo

      You are commenting using your Facebook account. Log Out / Change )

      Google+ photo

      You are commenting using your Google+ account. Log Out / Change )

      Connecting to %s