/ Development

Branching for a better today

It has been a long time since I have had the chance to work with a propper workflow and processes. When working for agencies, time was always an issue. Be it because of the small life time of the project, or the almost inexistent time-frame we had to build sites and web applications, I considered it a winning scenario that most of our code was actually being stored on a Git repo.
My developers has a small crush on DropBox for file sync and had little or no patience to work with GIT. There were serious complaints about merges and the cost these had to our workflow and development process(we liked to call it - Extreme Go Horse! - yes with the exclamation at the end). I'll publish an article soon enough about this insanely flawed, inhumane, crazy methodology.
Anyways... all that is in the past.
I have a couple of pet projects I am developing from scratch, on my own, following a strict set of rules (I plan on bringing in more developers in the near future).
One of the aspects of importance to my project is Version Control, both in terms of code and version numbers. Today I will focus my article on how I choose to control my code in my Git Repos and the tools I use.

Starting My Repos

If you are new to the world of git, please read-up on the basics of checkouts, commits, pushs and pulls. I expect you to be able to create repositories, and generally just keep things up to date in them.

If you are like most developers, just having a single repository that keeps the last version of your code up to date in an off site repository is already a fantastic tool. You can access your code from anywhere in the world, you are one step closer to Continuous Integration (CI) and you can safely interact with other developers in a single project.

When you initialize a git repo, you are basically creating a branch called "Master" (you can call it anything you want, but the standard is calling it master.

I setup a minimal commit & push - usually just uploading a README file with the very minimum of information (usually an intro to the project, notes I want to keep handy and so on).


Branching in git is a way to keep your master branch clean and your workflows organized and well documented. It helps track errors and solutions. It also helps track the the life of your project.

The Dev Branch

With my initial commit to master, I instantly create a dev branch.

git checkout -b dev

This creates a snapshot of the current master repository in a branch called dev, and allows me to separate the dev environment from the master(production) environment.

The dev branch, is where most of the magic of git will happen. It is from this branch that I will branch off most of my other branches, and where I will merge in most of them. To make some kind of parallel, the dev branch reflects your dev environment, and master, reflects the production server.

Branch Terminologies

There is no, at least to my knowledge, standard or convention used for naming git branches other that the rules git imposes (like branches cannot end with a period), so as for naming conventions, I would recommend using common sense and what seems logical to your project.
My projects usually have the following conventions:

Example Type Description
ftr_user_session Feature New features or functionalities on the system.
bfx_user_session Bug Fix Bug fixing on features that are being tested
hfx_user_session Hot Fix Hot fixes are fixes being done directly onto master and are/should rarely be used.
rfc_user_session Refactoring Used when there is some refactoring that must be made over many modules due to a feature change.
rc_0_0_0 Release Candidate Used when we want to test a production version on our staging environment.

Practical use of terminologies

Rather than be all conceptual about all of this, I thought I walk you through a simple example. Since I mentioned User Sessions on the table above, let's keep the same example and walk you through a regular branching flow.

Create the feature branch

First thing, make sure you are in the dev branch and that you have the latest version on your machine.
Create a new branch for your feature - in our case, we will create the feature User Session.

git checkout -b ftr_user_session

Work on your feature and commit very frequently, push regularly too. When you are happy, it is tested, re-tested and validadted, you can get ready to merge it into dev.

To do that, make user you have committed and pushed all you work on the feature and checkout the dev branch.

git checkout master
git merge ftr_user_session

If all goes well, you should now be on dev, with your new feature in place.

Creating a Release Candidate

This is not obligatory, but, i find it comforting to do. Whenever I am to publish some feature on my system, I like to replicate my prodution server and test out the feature with real live data. Since this is usually done in parallel to other developments (eventual merges in the dev branch) I like to create RC branches which can be used to simulate a production upgrade.

git checkout dev
git checkout -b rc_0_1_0

Here I am bumping a minor version - but in a later article we will talk all about Semantic Versioning and ways you can automate this control.

In my staging server, I replicate the production environment, deploy my RC_0_1_0 to it and test the app out.
Let's go with a worse case scenario here. We found some bugs in our RC.
What I like to do is to branch off from the RC my Bug Fix branch, one branch per bug, one bug at a time, for example:

git checkout -b bfx_ie_5_compatibility

I apply my fix, merge it back into my RC, and keep on fixing bugs. When everything is done, I merge back into DEV.

git checkout dev
git merge rc_0_1_0

Fix any eventual conflicts to ensure dev is up to date.
Ensure my version numbers are correct (bug fixes generate new patch numbers).

Going back to master

Finally, when everything is OK, I go into my master branch and merge in the RC branch.

git checkout master
git merge rc_0_1_0

Again, we fix any conflics (we shouldn't have any though).
Add a tag with the version number

git tag v.0.1.1 -m "Release candidate v0.1.0 with ie bugfix"

Finally your master should be up to date with the latest release candidate. You can eventually erase the merged branches from git to avoid clutter, but I tend to keep mine around for a while after.

Gregory Brown

Gregory Brown

Baker, cake designer, cook and just by chance, a full featured developer that is passionate about technology.

Read More