YAGBW - Yet Another Git Branching Workflow

Hey guys! Andou here, backend engineer / web developer / tech leader for Bitmama Reply, an Italian web agency headquartered in Milan, Turin and London.

In this article I would like to talk to you about YAGBW - Yet Another Git Branching Workflow, the git branching workflow we usually work with.

Let's get started!

Intro: branching workflows

When you decide to version control your project (and you should do) using git, you are somewhat asked to choose a branching model or workflow.

I've listed the most common workflows in my tech resources list, which are:

• Git Flow : Probably the most famous branching model
• GitHub Flow : My favourite branching model, good for CI/CD
• Trunk Based Development : A skinny model good for initial project phases

YAGBW / Basics

Well, without further ado, here is the branching workflow we usually adopt to handle our web projects with minor headaches and a pretty full control over delivered features.

This is a solution somewhere between Git Flow and GitHub Flow.

Basic rules:

• You shall create a master (or main) branch and a cert branch
• You shall never push commits on master (or main)
• You shall never push commits on cert
• You shall never merge cert on master (or main)

Developing stuff:

• Every feature or bug resolution needs a specific branch, that we can refer to as feature branches
• feature branches need a speaking name, usually feature/<name> for a feature and hotfix/<name> for a bug resolution
• You'll always create new feature branches from master (or main)
• When you are done with your work on the feature branch you shall first merge it on cert to have it tested
• When your feature branch has been tested, your could merge it in master (or main)
• Merge master (or main) in your feature branch on a regular basis .

Deploying stuff (assuming you have at least a production and a certification environment):

• cert could be deployed at any given time on your certification environment
• master (or main) could be deployed at any given time on your production environment
• merge feature branche on cert
• deploy your certification environment
• test
• merge feature branch on master (or main)
• deploy your production environment

YAGBW / Addons

Of course the above workflow should perform well or not given the nature of the project you use it with. You may find yourself comfortable with some addons on the process:

Addon #1 / The prelive phase mode

Speaking of web projects there's always an initial phase where you are not online with your project and the word CI/CD makes no sense at all.
During this phase you may consider to merge and test directly on master (or main).

Addon #2 / Consider adding pull requests

You may find yourself comfortable introducing PRs to merge feature branches on cert and on master (or main). It's up to you, but it may helps to control your flow.

Addon #3 / Use tags

Well, this is not really an addon because I strongly recommend it. Consider to make an annotated TAG for every merge on cert and on master (or main).
This really helps with rollbacks.

Remember you can always detach a new branch from a previous tag (git checkout -b newbranch yourtag).

Wrap up

That's all for today. I hope this has been an helpful read. Please comment with your suggestions and feedback. Also, let me know what you think about our branching workflow and if you have some other addons we should consider introducing.

Comments

[Waylon Walker]

Liquid syntax error: Tag '{% youtube.com/watch?v=lXQEi1O5IOI %}' was not properly terminated with regexp: /\%\}/