Skip to content
Baptiste Clavié edited this page Mar 8, 2019 · 1 revision

This is a draft for the brand new git workflow we're using in the backend. THIS IS ONLY A DRAFT.

Workflow

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.

Case of a feature

When a new feature is being made, it should obviously target the main branch

     ---------------> hotfix-4.2
    /
------------------.-----------------> main-branch
        \         |
         ----------> feature

Case of a (non critical) bugfix

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.

Case of a critical bug-fix

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

Summary

So, with a graph which should be better to understand all this stuff, we should have the following :

http://data.baptiste.xn--clavi-fsa.net/graph-git-flow.png

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.

Versionning

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 !