Git - Bonnes Pratiques

2018-12-19

Git - bonnes pratiques

Note

Avant toute choses, sachez qu'il n'y a pas vraiment de structure magique et que cette structure dépend fortement des ressources auxquelles vous avez accès.

Souvent les entreprises ont chacune leur propre méthode d'utilisation de GIT relative à leur structure de projet.Voici une de mes solutions préférées.

Ici mon environnement serveur utilisé est structuré de la manière suivante:

  • local
  • staging
  • integration
  • prod

Branches

Structure de base du GIT lors de l'implémentation d'un nouveau projet.

  • master
  • stable
  • dev
  • Features/Tickets (ensemble de branches - on une nouvelle branche par features/tickets - nom branche = nom du feature/ticket)

Master

Cette branche est automatiquement crée lors de la création d'un projet GIT.  Toutes les autres branches ont besoin d'être crées.

On ne doit JAMAIS travailler sur cette branche! Cette branche est la branche propre qui sera mise en Production.  C’est à partir de cette branche que l’on crée les tags à déployer (si vous utilisé des tags).

Stable

On ne doit JAMAIS travailler sur cette branche!

Tout code voulant se trouver sur master doit obligatoirement passer sur stable. C'est sur stable que les conflits (si il y en a) vont être régler afin de garder master propre.

Tout code qui est ajouté à stable doit avoir était QA au préalable sur le local au minimum (si vous n'avez pas d'autre environnement).

Stable est supposé être déployé sur l'environnement de "staging". Le dernier QA pour voir si tout est beau doit se faire la dessus.

J'aime utiliser cette branche pour créer toutes nouvelles branches, de cette manière on ne "touche" jamais à master mis à par les merges avec stable.

Dev

Branche de développement lors de la phase "création" du projet. Une fois en maintenance je suggère de ne plus travailler dessus.

Cette branche sera utilisée sur l’environnement d’intégration pour la 1ère ronde de QA.

Features / Tickets

Ceci n'est pas une branche mais bien un regroupement de branches.

Lors de la période de maintenance (ticket) ou de nouveau développement (feature) vous allez créer de nouvelles branches afin de travailler dessus et de segmenter votre travail par tickets/features pour ne pas polluer le tronc.

Flow

Je vais me concentrer ici sur la période "maintenance" d'un projet car lors de la création, souvent le flow est de moindre importance même si il ressemble beacoup à celui-ci.

Nouveau ticket / Nouveau Feature = Création branche

Créer votre branche à partir de “stable”.
Pas à partir de dev car la branche dev n’est pas forcement “stable” et on ne peux pas contrôler vraiment ce que l’on veux déployer du au fait que tout le monde peux pousser sur dev pour faire du QA sur l'intégration même si ses modifications ne sont pas “correct”.

Vous avez fini votre ticket / feature

Votre tâche est maintenant faite et vous avez QA cette tâche sur votre local. Vous voulez maintenant l'envoyer en QA sur l'intégration.

Pour ce faire, il vous faut merger votre branche sur la branche “dev”. Afin de tester la branche dev sera poussé sur l'intégration.

QA = Erreur(s)

Continuer votre développement sur votre branche et une fois fini, répéter l'étape précédente.

QA = OK

Tout est correct ET approuvé, la tache est maintenant en “Ready for live”. À partir de maintenant, le “release manager" devrait prendre le relais.

On merge la branche “ticket/feature” sur “stable”. On règle les conflits si il y en a. On met maintenant notre code sur le serveur de staging afin de tester une dernière fois que tout va bien.

Déploiement Live

Le “release manager” lorsqu’il le souhaite, merge “stable” sur “master” et pousse ceci en live.
On pourrait le mettre “automatique” et dans ce cas, dès que des changements apparaissent sur “master”, notre setup le déploie via des outils comme jenkins par exemple.

 

Conseils

Commiter souvent

Pensez à souvent commiter afin de créer des points de repères dans votre arbre local/distant. Cela n’affecte personne et vous permettra de facilement revenir en arrière en cas de besoin.

Message du commit

Essayer d'être le plus précis possible dans vos message de commit cela vous sera utile ainsi qu’a tout les autres dev.
Le mieux serait d’avoir un structure de ce type:

#numeroTicket - message explicatif du commit

 

 

Commentaires

Wednesday 19 December 2018 - Stas
Je recommande d'essayer Codelobster: http://www.codelobster.com