Usually, most rookie developers don’t use a VCS (Versioning Control System), like SVN or GIT, in this post I won’t talk about the benefits of using one. This post is dedicated to who are already using a VCS without using a branching model.
So, what’s a branch? A branch is a separate development line, where you or your team can work on to develop a single functionality or even an entire release. This line is separated from the rest in order not to mix unfinished functionalities and avoid to push them to the mainline or deploy them in production.
The solution is having two or more distinct lines (aka branches) so your team can work on those lines of development without interfering with each other.
The images above are referring to the Git Flow.
Generally, common sense dictate to have the following branches:
- master / trunk
- development branches
- tags
In git, the tags are not actually physical branches like in SVN but just snapshots, as what they are supposed to be.
The master / trunk must have the stable version, generally the latest version.
It’s highly recommended to tag it in order to have an archive of each deployed version (e.g. useful in case you need to rollback).
As a suggestion the master contains only the stable version merged from the development branches, avoiding to commit directly into it keeps the history tidy and clean.
The dev branches contain the unstable code which is under development. Quite often it’s possible to have a branch for each version, in case of bug fixing or maintenance.
Juan Batiz-Benet created a gist in which he’s explaining this simple model, that I’m quite sure it’s used by many developers without even being aware of it.
There are several different branching models, and most of the time you are already using one.
At the moment there are mainly two ones:
-
Git Flow
The general idea is to have several branches, each for a different purpose:master,develop,feature,release, andhotfix. -
GitHub Flow
The general idea is just to have two branches:masterand descriptive branches for the functionalities you are working on.
I recommend to start with a simple model, and then (only if you really need) move towards a more complex one.