Série Git - Les plateformes d'hébergement (4/5)

Dans les articles précédents, nous avons travaillé principalement sur notre copie locale du projet. Dans cet article, nous allons présenter les plateformes d’hébergement les plus connues permettant de facilité le travail collaboratif.

En effet, comme nous l’avons expliqué dans le premier article de cette série, tout l’intérêt de Git est de facilité le travail collaboratif.

Pour cela, les plateformes GitHub et GitLab fournissent un moyen de centraliser la gestion du code source, mais pas seulement. Nous verrons ici les différentes fonctionnalités supplémentaires que ces outils proposent pour améliorer encore ce travail en équipe.

1 Les issues

Nous commençons avec les issues. Cette fonctionnalité permet de lister les tâches à réaliser sur votre projet.

Cela peut correspondre à :

• des nouvelles fonctionnalités ;
• des bugs à résoudre ;
• des optimisations à implémenter ;
• etc.

Un des principaux avantages de ces issues est qu’elle est parfaitement intégrée avec Git allant de l’ajout de simple référence dans l’issue ou bien la réalisation d’action sur cette issue.

En effet, il suffit d’utiliser #<issue_id> pour ajouter une référence à cette issue dans un commit par exemple.

Un autre exemple très commun est l’utilisation de la commande fix associée à la référence de l’issue dans le message du commit (exemple feat: ajout de la fonctionnalite (fix #<issue_id>)). Une fois ce commit fusionné avec la branche principale, l’issue numéro <issue_id> sera automatique marquée comme résolue.

Exemple :

1. L’équipe de test se rend compte d’un dysfonctionnement sur l’authentification.
2. Elle crée alors une issue sur GitHub ou GitLab.
3. Une référence unique est créée pour cette issue (exemple : 1).
4. Une personne de l’équipe de développement prend en charge le correctif. Il va donc démarrer une nouvelle branche : git checkout -b hotfix/1_correctif_authentification.
5. Il corrige le code source de l’application et valide ces modifications via un commit : git commit -am "fix: correction de l'authentification (fix #1)".
6. Il partage ce dernier commit via un push : git push.
7. Il fusionne sa branche avec la branche principale : git checkout master ; git merge hotfix/1_correctif_authentification ; git push
8. L’issue sera alors automatiquement marquée comme close.

2 Les pull request / merge request

Les pull request (GitHub) / merge request (GitLab) permettent de soumettre des modifications du code à l’équipe.

Au travers de celle-ci, un membre de l’équipe peut ainsi faire une proposition de fusion d’une branche (feature/toto par exemple) vers une autre branche. Le plus souvent, la branche de destination est une des branches principales (develop, master ou main).

Associé à chaque pull request/merge request est mis à disposition un espace d’échange permettant aux autres membres de l’équipe de faire des remarques/suggestions sur cette proposition d’évolution du code. Aussi, des règles d’approbation (review) peuvent être mises en place nécessitant par exemple qu’au moins un autre collaborateur de l’équipe valide les modifications avant que celles-ci ne puissent être fusionnées avec la branche de destination.

3 Les workflows / pipeline

Les workflows/Github Actions (GitHub) / pipelines (GitLab) sont des tâches ou enchainements de tâches qui sont exécutées lorsque surviennent des évènements.

Ces évènements peuvent être de différente nature :

• Un ou plusieurs nouveaux commits ;
• Création d’une pull request ;
• Fusion d’une branche dans une autre ;
• Création d’un nouveau tag.

Les usages de ces scripts automatisés sont multiples. On peut citer par exemple :

• Valider le formatage du code pour s’assurer qu’il correspond aux bonnes pratiques imposées par le projet ;
• Jouer une série de tests permettant de s’assurer de la non-régression du code ;
• Création automatique d’une release sur la présence d’un tag ;
• Déploiement du code/de l’application.

4 Les releases

Enfin, nous terminons ce chapitre sur les releases.

Les releases permettent d’associer un certain nombre de ressources à un tag. Les ressources associées peuvent être de différents types : fichiers compilés, code du projet compressé, documentation ou tout autre fichier.

Un des usages principaux de ces releases est la mise à disposition des fichiers compilés associés à un changelog.