Branching Model: clean-up those repos
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’s 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 main line 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, the common sense dictate to have the following branches:
- master / trunk
- development branches
In git the tags are not actually physical branches like in SVN but just snapshots, as what they are supposed to be.
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 suggestion the master contains only the stable version merged from the development branches, avoiding to commit direct into it keeps the history tidy and clean.
The dev branches contain the unstable codewhich is under development. Quite often it’s possible to have a branch for each version, in case of bug fixing or maintenance.
There are several different branching model, 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:
- 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.