Git - Pratiques partagées

Ce guide expose les règles à suivre pour effectuer vos commit Git.

Pourquoi c’est important ?

  • Avoir un historique clair
  • Avoir des commit qui fonctionnent : si je me mets sur un commit particulier, ca doit compiler ! Important en - cas de recherche d’introduction de bugs
  • Pouvoir générer un changelog à partir des commit
  • Filtrer facilement

Message

On se base sur une convention définie par l’équipe Angular adaptée à nos besoins :

<type>(<scope>): IGNGPF-XXXX <subject>

Dont les différents composants sont détaillés ci-après :

Type

  • feat : feature
  • fix : bug fix
  • docs : documentation
  • style : CSS, HTML
  • codestyle : formatting, missing semi colons, …
  • refactor
  • test : when adding missing tests
  • chore : maintain, tooling, etc.
  • wip : commit non fonctionnel

Scope

Le scope représente le composant fonctionnel impacté : la liste sera définie avec les équipes et sera le référentiel fixe.

Exemple : feat(publication): api GET communities

IGNGPF-XXXX

Où XXXX est le numéro du ticket JIRA associé à la MR.

Sujet

  • en anglais
  • doit être très court (~50 caractères)
  • impératif présent (change, corrige). Pas de passé.
  • première lettre en minuscule
  • pas de point à la fin

Exemple complet

feat(download): IGNGPF-1 create new download service

Atomicité

Chaque commit doit se suffire à lui-même, il est atomique. Si on se met sur ce commit, le projet doit compiler ! Pour exemple, si le commit n'est pas suffisamment atomique, il sera difficile à annuler (revert) au besoin sans effet de bord. De la même manière, sur un travail collaboratif, on peut se retrouver à récupérer des commits d’une branche d’un collègue et si ça ne compile pas, on bloque le travail. Pensez à bien utiliser le git commit --amend pour refaire votre commit (changer le nom, ajouter des fichiers et changes - avant le push bien sûr !).

Nom de branche

Une branche respectera le nommage suivant :

feat/<n°ticket> ou hotfix/<n°ticket>

Exemple complet

feat/IGNGPF-26

Cycle de vie des branches

Avant de créer une branche, s'assurer d'être à jour avec la branche principale :

git fetch
git checkout develop
git pull

Ne pas hésitez à ouvrir sa merge-request tôt, quitte à la mettre en WIP.

Afin d'ouvrir une merge-request à la revue, s'assurer que la branche est à jour avec la branche principale :

git fetch
git rebase -i origin/develop

Review et Tableau des merge-request

Un tableau des merge-request en cours est disponible au sein de Teams : Merge-request.

Lorsque l'on prends une tâche JIRA

  1. Créer une branche feat/<n°ticket> sur chaque repo concerné
  2. Push
  3. Créer une MR de cette branche vers develop en mode Draft
  4. Créer une tâche dans la colonne "Draft" du tableau Teams et se l'affecter en mettant en notes les urls des MRs

Quand le dev est fini

  1. Passer le ticket du tableau Teams dans la colonne : "A relire"
  2. S'assurer que la ou les branches soient bien à jour par rapport à develop

Relecture

  1. Passer le ticket du tableau Teams dans la colonne : "En relecture"
  2. Se l'assigner
  3. Se mettre en Reviewer de la MR ou des MRS dans Gitlab
  4. Faire ses retours (cf. plus bas)
  5. Quand c'est fini, 2 possibilités :
    • Les MRs associées au tickets sont OK :
      1. Merger les MRs
      2. Passer le ticket du tableau Teams dans la colonne "Mergé"
      3. Mettre à jour le JIRA pour le clore
    • Au moins une MR à des retours :
      1. Passer le ticket du Teams dans la colonne "Retour à traiter"
      2. Prévenir la personne

Règles de bonnes conduite

  • On ne résout pas les commentaires sur sa propre MR afin qu'ils soient validés par la personne qui a fait la review (sauf éventuellement pour les suggestions automatiquement appliquées)
  • L'assignee d'une MR reste le développeur à l'origine (sauf si quelqu'un reprends la tâche à son compte)
  • Ce sont les relecteurs qui closent les discussions
  • Dans le cas de relecteurs multiples :
    • Une fois la passe sur ces propres retours faite, on approuve la MR
    • Si on est le dernier relecteur à approuver, on peut Merger
    • C'est le relecteur à l'origine d'une discussion qui clôt la discussion (sauf si congès)
  • Dans le cas d'une MR multi-repo :
    • Mettre le label "A merger quand MR liées OK" sur les MRs qui sont prêtes à être mergées (mais ne pas les mergées)
    • Une fois toutes les MRs OK, on peut les mergées