Forge logicielle

Le développement logiciel est une activité fondamentalement collaborative. Alors qu’un dépôt Git local suffit pour un travail individuel, une forge est indispensable au travail en équipe.

Une forge logicielle, comme Forgejo, Github, Gitlab… agit comme un dépôt Git central, un référentiel commun autour duquel s’articule le travail de l’équipe.

L’objectif de ce cours est de présenter le flux de travail collaboratif standard de l’utilisation d’une forge, en se conformant aux bonnes pratiques du métier.

Dépôt distant et dépôt locaux

• Dépôt distant : c’est le dépôt Git hébergé sur la forge, le référentiel central ou le code est mis en commun ; il est par convention nommé “origin”.
• Dépôts locaux : ce sont les copies du dépôt distant présentent sur les machines de chaque développeur.

Chaque développeur travaille de manière isolée sur son dépôt local, et — à son initiative — se synchronise avec le dépôt distant.

Les commandes de synchronisation

Pour que les dépôts locaux et le dépôt distant restent cohérents, Git fournit des commandes de synchronisation essentielles :

• git clone <URL_dépôt> : cette commande est utilisée une seule fois par développeur, lorsqu’il rejoint un projet pour créer une copie locale du dépôt distant ; cette commande effectue les opérations suivantes :
  • crée le dossier du projet et y initialise un dépôt Git local (cf git init) ;
  • associe le dépôt local au dépôt distant (git remote add origin URL_Dépôt) ;
  • télécharge le contenu du dépôt distant (git pull origin main).
  • associe la branche locale main à la distante (git branch -u origin/main main)
• git pull : permet de récupérer les mises à jour de la branche active depuis le dépôt distant.
• git push : permet de partager son travail en envoyant les instantanés locaux au dépôt distant.

Authentification par clé (sécurité)

L’authentification par clé SSH est recommandée (voire obligatoire) pour pouvoir se synchroniser avec une forge. Pour cela une paire de clés est nécessaire :

• s’il n’y a pas de fichier ~/.ssh/id_ed25519, créer une paire de clés : ssh-keyhen ;
• configurer son profil sur la forge pour y ajouter sa clé publique (fichier ~/.ssh/id_ed25519.pub).

La manière dont un développeur commence à travailler avec un projet dépend de la situation initiale du dépôt distant sur la forge. On distingue principalement deux scénarios :

• scénario 1 : le projet est initialisé localement puis poussé sur une forge ;
• scénario 2 : le projet est créé sur une forge puis cloné localement.

Quel que soit le scénario suivi, le fichier de configuration du projet .git/config est complété pour définir l’URL du dépôt distant (“origin”) et lui associer la branche principale (“main”) :

[core]
    …
[remote "origin"]
    url = URL_Dépôt
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
    remote = origin
    merge = refs/heads/main

Scénario 1 : local → distant

Ce cas de figure est courant lorsqu’un projet démarré localement doit être partagé. Il faut pour cela :

• créer un dépôt vide sur la forge (décocher l’option pour l’initialiser) ;
• y relier son dépôt local et pousser son travail :

git remote add origin URL_Dépôt #configuration du dépôt distant "origin"
git push -u origin main         #-u lie la branche locale "main" à celle distante

Scénario 2 : distant → local

C’est le scénario le plus fréquent pour rejoindre un projet existant ou pour démarrer un nouveau projet que l’on souhaite voir hébergé d’emblée sur une forge :

• le dépôt doit être initialisé (cocher l’option) sur la forge avec un premier commit ;
• chaque membre de l’équipe (y compris le créateur du projet) doit ensuite cloner le dépôt : git clone URL_dépôt

Principe d’organisation

Le flux de travail en branches de fonctionnalité (Feature Branch Workflow) est une stratégie de gestion de branches conçue pour le travail en équipe.

Une branche commune — la principale (“main”) ou une autre (“dev” par exemple) — est utilisée pour mettre en commun les travaux finalisés, mais elle ne doit jamais être utilisée pour y travailler directement : chaque nouvelle fonctionnalité, ou correctif doit être développé dans une branche dédiée.

Ainsi, chaque développeur crée ses branches dédiées de fonctionnalité (ou de correctif) à partir de la branche commune. Le nom des branches devraient suivre des conventions de nommage : “feature_intitulé_fonctionnalité” ou “fix_intitulé_bug” par exemple.

Une fois le travail terminé, le développeur synchronise la branche commune, rebase la branche dédiée et résout les éventuels conflits.

Il peut ensuite soumettre son travail à l’équipe pour relecture / validation. Les forges disposent pour cela d’une fonctionnalité nommée requête de tirage (Pull Request — PR) ou requête de fusion (Merge Request — MR). L’interface web (de la forge) permet la revue de code, les discussions et la validation (ou le refus) de la demande de tirage / fusion.

Cette approche permet :

• à chaque développeur de réaliser ses tâches sans gêner les autres ;
• d’améliorer la qualité grâce à la revue de code ;
• de faciliter le suivit de l’historique dans la branche commune.

Les étapes :

Développer une fonctionnalité sur une branche dédiée

Une fonctionnalité ou un correctif doit être développée dans une branche dédiée crée à partir de la branche commune à jour.

1. S’assurer que la branche commune est à jour : git switch branche_commune (“main” ou “dev"…) puis git pull.
2. Créer et basculer sur une nouvelle branche dédiée : git switch -c branche_dediée.
3. Réaliser la tâche.
4. Indexer et valider les modifications (cf git add et git commit).

Synchroniser et mettre à jour sa branche

Il est très fortement recommandé de procéder par rebasage afin de traiter les éventuels conflits en amont, avant de soumettre son travail.

5. Mettre à jour la branche commune : git switch branche_commune puis git pull.
6. Rebaser la branche dédiée : git switch branche_dediée puis git rebase branche_commune ; si besoin, résoudre les conflits et finaliser le rebasage : git rebase --continue.

Partager et demander une intégration

Afin d’améliorer la qualité des développement et de favoriser la maîtrise globale du projet par l’ensemble des membres de l’équipe, ne pas intégrer soi même son travail à la branche commune, mais faire une demande de tirage / fusion.

7. Pousser la branche de fonctionnalité sur le dépôt distant : git push -u origin branche_dediée
8. Via l’interface web de la forge, faire une requête de tirage en sélectionnant la branche source (dediée) et la branche cible (commune).
9. Un autre membre de l’équipe vérifie le travail avant de valider (ou rejeter) la fusion (en “fast-forward” grâce au rebasage).

Fusionner et nettoyer

La branche dédiée, désormais inutile, doit être supprimée (localement et sur le dépôt distant), et la copie locale de la branche commune doit être synchronisée avec la forge (la fusion a été réalisée sur le dépôt distant).

10. Synchroniser la branche commune : git switch branche_commune puis git pull
11. Supprimer la branche locale : git branch -d branche_dédiée.
12. Supprimer la branche distante (si cela n’a pas été fait à l’issue de l’opération de fusion sur la forge) : git push origin --delete branche_dédiée.