-
Notifications
You must be signed in to change notification settings - Fork 0
Git Workflow
This is a draft for the brand new git workflow we're using in the backend. THIS IS ONLY A DRAFT.
The workflow is about the same as the famous git-flow ; We're basing ourselves on a main branch (dev-master
, master
, foo
, poney
...), which is the target for all features and refactos, and bugfixes which are not critical for a coming push. I'll get back to it a little bit later.
- ..warning::
- in the following schemes,
.
represents a merge commit,/
or\
represents a new branch, and|
the merge point of a branch.
Let's take a basic example. Let's say I have a main branch (which I'm naming here main-branch
), and the latest push, let's say 4.2
---------------> hotfix-4.2 / ------------------------------------> main-branch
Several cases can be discerned : a new feature, a refacto, a bug-fix and a critical bug-fix.
When a new feature is being made, it should obviously target the main branch
---------------> hotfix-4.2 / ------------------.-----------------> main-branch \ | ----------> feature
when a non critical bug fix is made (which should not be pushed right asap), it should target the main-branch
---------------> hotfix-4.2 / ------------------.-----------------> main-branch \ | ----------> bug-fix
It is not mandatory to make a branch if the bug-fix is only one commit.
When a critical bug-fix is made (we should push it asap), it should target the hotfix branch and then, once merged, be also manually merged (or cherry-picked) into the main-branch
---- critical-fix / | / .--------------------- / | | --------.------> hotfix-4.2 | / | ----------------------------------.----> main-branch --------.-------> hotfix-4.2 / \ ---------------.---------------------> main-branch
So, with a graph which should be better to understand all this stuff, we should have the following :
the blue nodes are the main-branch
commits, the cyan nodes the hotfix-x.y
commits, the green ones the critical-fix
commits, and the pink and orange ones the non-critical
commits (features, refacto, bugs...). The first commit on the main-branch
is the same first commit on the hotfix-x.y
.
the versionning is itself based on the semantic versionning ; while a major version (x.y.z) means a complete refactoring or a big event coming up (back / front split, new architecture, ...), let's focus on the other two types of releases, minor and bugfixes.
A minor release is starting from the main-branch
branch, and should vary only on the minor point (x.**y**.z). It should also be followed by the creation of a hotfix-x.y
branch, which will never be merged into the main-branch
, or even be rebased. Its commits (or merges) should be manually ported onto the main-branch
(see the sketches) through a git merge --no-ff
or git cherry-pick
command.
A bugfix release (x.y.**z**) is made from the adequate hotfix-x.y
branch. Each commit onto this branch is not necessarily a new tag though !