Git au quotidien ?

C’EST QUOI GIT ?

Crée par Linus Torvald en 2005 (suite à l’abandon de BitKeeper concernant la fin de l’utilisation gratuite de son logiciel), Git a été développé spécialement pour le noyau Linux, il est devenu l’outil de versionning le plus populaire depuis 2016.

Si vous voulez être étonné-e par l’origine de son nom, je vous invite à consulter la page Wikipedia.

Git possède une structure composée d’objets (blob, tree, commit, tag, branch) tous identifiés par une somme de contrôle SHA-1 du contenu (en gros un ID unique).

 

HISTOIRE VÉCUE

C’est lors d’une matinée d’hiver où la neige recouvrait la végétation que tout à changé pour John. Il est venu me voir sur l’open-space voisin au sien. L’air soucieux, il avait l’air embarrassé.

    “Jim j’ai un souci ! On doit annuler la livraison d’une fonctionnalité mais on y arrive pas dans l’équipe.”

Curieux , je lui demande de m’exposer son problème et voir comment je vais pouvoir l’aider. Quelques minutes plus tard je finis par comprendre que c’est la façon dont son équipe et lui ont démarré le développement qui posait problème.

Ils utilisaient Git pour versionner leur code et le livrer sans comprendre l’essence de la force du  versionning (de quel côté ont-ils basculé?).

 

SOLUTION AU PROBLÈME

Après 5 cafés, 2 viennoiseries et 4 allers-retours aux WC,  je suis parvenu à expliquer à John comment résoudre son problème pour qu’il puisse livrer sans embarquer la fameuse fonctionnalité.

Je lui propose une autre approche qui pourrait lui changer la vie (de développeur).

Les yeux écarquillés et le toucher du clavier fébrile je sens que John est à l’écoute en espérant se sortir de là.

Je lui raconte que Git est son ami mais qu’il faut apprendre à le connaître. Et pour cela il faut appréhender son potentiel et l’exploiter comme un samouraï de la période Nara.

La première chose à faire est de créer des branches (oui comme un arbre). Cela va permettre de paralléliser les développements des fonctionnalités et de les livrer au moment voulu. Pour cela rien de plus simple.

Dans notre cas on partira d’une branche de release afin de ne pas coder directement depuis la branche principale (souvent master).

        $ git checkout -b little-feature releaseA

 

Crédits: https://www.atlassian.com/git/tutorials/using-branches

 

Une fois la branche créée le développement peut démarrer. On peut alors itérer plusieurs versions alternatives si besoin. C’est aussi simple que ça :

 

        $ git checkout -b little-feature–alternative  little-feature

 

Une fois le développement terminé, il suffit alors de fusionner la branche dans la branche de release (branche à livrer).

 

        $ git checkout releaseA  && git merge little-feature

 

Et si par le plus pur des hasards il fallait annuler tout le code embarqué, il suffira de reprendre le commit ID du merge et d’inverser tout les changements par cette formule magique (à prononcer en grec ancien) :

 

    $ git revert -m 1  <commit-id>

 

Le soleil de l’après midi avait réchauffé l’atmosphère, la neige avait fondu comme si la nature se réveillait. John était dans le même état. Il s’éveillait à une nouvelle approche qui lui permettrait d’être plus agile.

Avec cette approche vous n’aurez plus à vous inquiéter du code que vous produisez. Bien au contraire : la puissance des branches vous permettra d’éprouver plusieurs alternatives à vos développements sans écraser, perdre, mélanger ce que vous avez fait avec les autres versions ou la codebase.

Fier d’avoir pu aider, c’est le cœur léger que je retourne à mon code.

PS : Prenez garde aux effets de bords car gérer 80 branches en même temps relève presque de la magie mais on en reparlera dans un autre article sur les tips de Git.

 

Happy end.

 

Auteur : David Lemesle, Ingénieur Concepteur développeur SQLI PARIS