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.
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.
Let’s first list off the mechanics of this branch:
A Feature branch…
- May branch off from:
- Must merge back into:
- Branch naming convention: Anything except
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
git checkout -b my_feature_name develop
When incorporating a finished feature on develop, you can merge them into
origin/developwhich 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
--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.
In my next post, we’ll be covering Release branches.