Most of us live in a GIT world. Most teams use feature branches to develop functionality using GIT. However there are still a lot of people who use TFS, SVN or even SourceSafe and may not know what they are and how to use them. In this post I will show what feature branches are and how you can create them.
Feature Branches
This isn’t a concept that’s completely new, however it became more popular as the ‘default’ way to work with Git source control. To give an example on how to use them we need some diagrams. GIT still has a lot of the concepts of other source control systems so most of it should familiar. Suppose we have an application where a feature needs to be added. ‘Jane’ is going to work on it. When working with feature branches new features a developed in separate branches and when they are done they are merged on the main version. An example of this can be seen below:
The first thing ‘Jane’ has to do is to create a new branch to store her new feature. She creates that on the main version of the application which is called ‘Master’ in GIT and ‘TRUNK’ for SVN users. After that is done she changes here local version to that newly created branch. Then she starts working on it, after finishing some functionality she can commit her code on that branch. After three commits the new feature is done and needs to be merged back to Master (TRUNK). After she’s done the feature is ready and available on the main version of the application.
But this a simple example, let’s create a slightly more complex example where multiple developers are working on that application. A diagram of this can be seen below:
In this example ‘Jane’ is joined by ‘Bill’ and ‘Adrian’. However ‘Bill’ joined later then ‘Jane’ so when ‘Jane’ is working on her feature ‘Bill’ also creates a new branch and works on his feature there. After ‘Bill’ is done he merges his branch with the main version. But they needed a third developer on the project so ‘Adrian’ was brought in to work on feature 3. He started before ‘Bill’ was finished so he then creates a new branch (which now has the code from the feature ‘Jane’ was working on) and works on his feature there. After he is done he also merges his branch back to the main version. Now all there feature are added in the application. But why would you work like this? Merging is a pain in the ass I hear you say. But this way of working has some advantages:
Releasing only specific/finished features is easy
Features are only added to the main version when they are done. This means that you can release your software and be sure that only finished things are available in that release.You can even have multiple Master (trunk) branches and choose what feature is in a release.
You don’t bother other developers with your half finished code
Working in a team is great except when you update your code and it stops compiling because some other developer is also working on code and you chose the worst possible time to update. This gives you a delay because you first have to figure out what went wrong and them find out who is currently working on a feature that causes your build to crash. When this delays your for 5 minutes your glad but it can also cause a 30 minute debugging sessions before you figure out what went wrong.
You can easily work on another feature if that is needed
So suppose you are working on a feature but something comes along with a higher priority? well no problem, just create another feature branch from the main version and start working there. I don’t say you should do this all the time but this works fine when it is needed.
So now that you now what feature branches are and why you should use them. In another post I’ll show you how to create them in GIT and give you a way to do a code review in GIT.