One day I was reading Hacker News when I stopped in a gist named a simple git branching model by Juan Batiz-Benet. After sending it to The Amazing Dev Team we started discussing how to have a simple, clean and semantic branching model.

After a few conversations during these months, we decided to write it down to specify the rules and why they work for us.

The Rules

1. master must always be deployable
2. all changes should be made using feature branches (merging with master)
3. all hotfixes should be made in the hotfixes-{name}
4. rebase to avoid/resolve conflicts; merge into master

The explanation

1. master must always be deployable
   We deploy master when pushing to origin. We do this using Jenkins and Continuous Integration.
2. all changes should be made using feature branches (merging with master)
   This way branches have more meaning in a semantic way. Each branch is a feature of the project and the code can easily be found.
3. all hotfixes should be made in the hotfixes-{name} branches
   When lauching an application you receive a lot of feedback, specially if you have more than 9 million readers a month. This feedback sometimes is a new feature or sometimes is a quick and hot fix that should be deployed immediately. One optimization to this step is creating a hotfixes branch every release and deploy it to production, this way you will keep the master clean and you have a fast response time.
4. rebase to avoid/resolve conflicts; merge in to master
   Please avoid the merge bubbles. Please.

#Some Code To Understand

# First, create a new branch from master.
$ git pull origin master
$ git checkout -b new-feature

# Make changes and commits.
$ git add .
$ git commit -m "Changes"

# When finishing the new feature you should bring the code inside master to the branch.
# It's a good practice to make it frequently during the development of the feature.
$ git fetch origin master
$ git rebase origin/master
$ git push origin new-feature
# Sometimes, when there are conflits at rebasing, you should make git push -f origin new-feature.

# After finishing, you should merge and push the new features to master.
$ git checkout master
$ git pull origin master
$ git merge --no-ff new-feature
$ git push origin master

The importance of --no-ff flags when merging is huge, because it prevents a “fast forward” constructing a commit for the merge. You can read more information in this post.

The results

If you follow this methodology you can transform this merge chaos:

Into this beautiful git pipeline:

Feel free to send feedback!