YAGBW - Yet Another Git Branching Workflow
Tags: git, github, workflow, devops
Published: 2021-07-02 15:50:20

Hey guys! [Andou](https://github.com/andou) here, backend engineer / web developer / tech leader for [Bitmama Reply](https://www.bitmama.it/), 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](https://github.com/andou/tech-resources#branching-models), which are:
- [Git Flow](https://nvie.com/posts/a-successful-git-branching-model/) : Probably the most famous branching model
- [GitHub Flow](https://guides.github.com/introduction/flow/) : My favourite branching model, good for CI/CD
- [Trunk Based Development](https://trunkbaseddevelopment.com/) : 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.