14
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!
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
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
(ormain
) branch and acert
branch - You shall never push commits on
master
(ormain
) - You shall never push commits on
cert
- You shall never merge
cert
onmaster
(ormain
)
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 andhotfix/<name>
for a bug resolution - You'll always create new feature branches from
master
(ormain
) - 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
(ormain
) - Merge
master
(ormain
) 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
(ormain
) 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
(ormain
) - deploy your production environment
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:
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
).
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.
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
).
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.
14