TP3 - Git en réseau

L'objectif de ce TP est d'utiliser Git en réseau, pour pouvoir travailler en équipe.

Partie 0 - Instructions

L'utilisation de Large Language Models (ChatGPT, DeepSeek, Gemini, Grok, etc) reste interdite et sanctionnée, comme aux TPs précédents.

Le rendu se fera dans un fichier TP3.txt. Écrivez-y toutes les commandes exécutées dans cette liste : git push, git pull, git remote, git clone.

Partie 1 - Codeberg et dépôt distant

Codeberg.org est une forge Git hébergée par une association qui gère ses propres serveurs en Allemagne. Elle est à destination de développeurs et développeuses de logiciel libre.

Codeberg est basé sur le logiciel libre Forgejo, comme de nombreuses autres forges.

On va donc se créer un compte sur https://codeberg.org.

On ne va plus utiliser Codeberg, à cause de problèmes de rate-limit. On va utiliser ce site, créé dans l'urgence : https://git.ppom.fr

Une fois votre compte créé, renseignez-le dans le champ texte du rendu « Identifiants git.ppom.fr » sur Moodle. Ça vous permet de mettre le pseudo de votre choix 🙂

On va maintenant créer repo git local puis le lier à un repo git distant (c'est-à-dire en ligne, sur git.ppom.fr).

Créer un dépôt local

Dans un nouveau dossier TP3, créez un dossier mon_tp3 et initalisez-y un dépôt git.

Créez un fichier appelé README.md et validez dans un premier commit.

Créer un dépôt distant

Créez sur git.ppom.fr un nouveau dépôt appelé tp3.

• Le repository doit être public.
• Il ne doit pas être initialisé.

Pour faire ça, on clique sur le + en haut à droite, à côté de votre avatar. Cela devrait ouvrir un menu déroulant proposant « New repository » ou « Nouveau dépôt ». Cliquez dessus.

Vous devriez arriver sur une nouvelle page vous demandant des informations : Laissez le dépôt public (ne pas cocher la case « Make repository private » ou « Rendre le dépôt privé »).

Ne sélectionnez pas de modèle (template), et ne cochez pas la case « Initialize repository » ou « Initialiser le dépôt ».

Lier le dépôt distant au dépôt local

On va maintenant lier notre dépôt local au dépôt distant, en ajoutant une remote au dépôt local.

Une fois le dépôt créé sur git.ppom.fr, l'interface vous propose deux options : Créer un nouveau dépôt, ou soumettre un dépôt existant. Puisqu'on a déjà un dépôt existant, avec un premier commit, on va choisir la deuxième option.

git.ppom.fr vous suggère deux commandes à utiliser : git remote add origin <URL de votre dépôt> et git push -u origin main.

origin est, par convention, le nom de la remote principale, mais on peut en avoir plusieurs. Vous remarquerez que la commande n'est pas juste git push comme on a vu en amphi, mais a d'autres arguments. Ils permettent, lors du premier push, de dire que la branche main de votre dépôt local va être lié à la branche main de la remote origin.

• Exécutez ces deux commandes.

Afin de pouvoir pousser sur votre dépôt, il faut vous identifier. Git va donc vous demander vos identifiants git.ppom.fr pour effectuer le push. Et ce à chaque fois. Dans le vraie vie, on utilise plutôt le protocole SSH qui permet de ne pas avoir à le faire à chaque fois, mais c'est bloqué à l'IUT donc on va taper les identifiants.

Interface web

Rechargez la page de votre projet sur git.ppom.fr et vérifiez que votre fichier README est bien présent.

• Cherchez comment afficher votre commit sur le site.

Deuxième copie du repo

On va maintenant simuler le fait de travailler sur deux ordinateurs en même temps.

Retournez dans le dossier TP3, et clonez votre dépôt. Si vous avez suivi nos instructions, cela devrait vous créer un dossier tp3 à côté de votre dossier mon_tp3. Par la magie de la simulation pédagogique, on va imaginer qu'il s'agit de deux ordinateurs différents.

Déplacez-vous dans ce nouveau dossier. Est-ce que le fichier README est bien présent ? Est-ce que vous pouvez bien voir le commit dans l'historique ?

Créez un nouveau fichier appelé git_c_cool.txt contenant « Git est un outil super agréable à utiliser ! », validez cet ajout dans un nouveau commit, et poussez vos modifications avec git push (sans autre arguments cette fois-ci, juste git push).

Vérifiez sur l'interface web que votre commit a bien été soumis.

Pull 🐔

• Revenez notre autre ordinateur, c'est à dire dans notre premier dossier mon_tp3.

• Est-ce vous dernier commit a été pris en compte ?

Utilisez git pull pour récupérer les modifications disponibles depuis git.ppom.fr.

• Est-ce que votre fichier git_c_cool.txt apparait dans votre Working Directory ? Vérifiez que votre log est bien à jour.

Des modifications simultanées

On sait maintenant utiliser la remote pour se partager l'historique d'un ordi à l'autre. Simulons maintenant des modifications effectuées simultanément sur les deux ordinateurs.

Toujours dans mon_tp3, modifiez le fichier README pour y expliquer qu'il s'agit d'un TP de l'IUT. Validez vos modifications dans un nouveau commit. Ne pas faire de push!

Malheureusement, vous êtes dans un train, il n'y a pas de réseau, vous ne pouvez pas push. Vous avez assez travaillé pour ce trajet, vous fermez votre ordi.

En rentrant chez vous, sur un autre ordinateur, vous décidez de continuer à travailler, en oubliant que vous aviez des commits qui n'ont pas été envoyé sur la remote.

Passez dans le dossier tp3, et ajoutez au fichier README les instructions permettant de cloner votre dépôt. Validez les modifications, et pousser les. Vérifiez que ça a bien été pris en compte dans l'interface web.

On repasse sur l'autre ordi (donc on se déplace dans mon_tp3), et on veut récupérer ces modifications.

• Lancez git pull dans mon_tp3. Que se passe-t-il ?

Git est gentil et vous propose plusieurs façon de gérer les divergences avec les dépôts distants. Vous devriez avoir un message d'erreur indiquant différentes commandes à effectuer.

• Lancez git config pull.rebase true. Sans rentrer dans les détails, ça permet de « réécrire » l'historique local pour avoir un log propre sans avoir des commits de merge à chaque pull. Vous verrez plus tard, pour l'instant faites nous confiance.

• Réessayez de git pull. Que se passe-t-il ?

• Vous pouvez constater que le conflit ressemble maintenant à ce qu'on a vu en fusionnant des branches la semaine dernière. faites un git status. Vous voyez que le dépôt est dans un état étrange, un « rebase interactif ». Ouvrez le fichier README.md et résolvez le conflit.

• Une fois que votre fichier est dans l'état que vous souhaitez, on va dire à git que c'est bon, on peut continuer notre pull : on add notre fichier, puis lance la commande git rebase --continue (git status vous indique cette commande si vous l'oubliez).

• Consultez votre log. Que remarquez-vous ?

• Effectuez un push pour avoir vos dernières modifications sur le dépôt distant.

Partie 2 - Outils de gestion de projet

La plupart des forges git proposent des outils de gestion de projet intégrés pour faciliter l'organisation et la collaboration. Ceux que nous verrons ici sont communs à presque toutes les forges et fonctionnent de la même façon.

Une première issue

Une issue, ou un ticket, est un fil de discussion utilisé pour faire remonter un problème, proposer des modifications, et plus généralement pour lister les tâches à effectuer sur un projet. Une issue ouverte correspond généralement à une tâche à faire; on la ferme lorsque la tâche est résolue.

Notre projet n'a pas de licence pour l'instant. Par défaut c'est donc le droit d'auteur classique du droit français qui s'applique. Puisque l'on souhaite que d'autres personnes puissent jouïr de notre travail et y contribuer, nous allons préciser une licence libre autorisant l'usage, l'étude, la modification et la redistribution du projet.

Créez une première issue concernant l'ajout d'une licence.

Une première PR

Renseignez-vous rapidement sur les licences suivantes et choisissez celle que vous préférez : AGPL, CeCILL, WTFPL, MIT

On va donc ajouter une licence. Dans une nouvelle branche licence, créez un fichier LICENCE.md et mettez-y le texte de la licence de votre choix. Validez dans un commit et pushez vos modifications.

Vous constatez dans l'onglet « Code » de git.ppom.fr qu'il y a maintenant deux branches.

Allez dans l'onglet « Pull requests » (ou « Demandes d'ajout »), créez une nouvelle Pull Request (PR, aussi Merge Request dans d'autres forges) pour fusionner dans main les modifications de licence. Ajoutez une courte description contenant une référence à l'issue (avec #1 -- 1 étant le numéro de l'issue). Validez la création.

Vérifiez dans l'interface que votre PR fait bien ce qu'on veut, à savoir ajouter le fichier LICENCE.md.

Il n'y a pas de conflit, on peut donc effectuer la fusion directement en cliquant sur le bouton de l'interface web.

Notre issue est résolue, allez la femer.

Pensez à pull les modifications dans votre dépôt local !

Partie 3 - Participer à un projet ouvert

On va maintenant construire un projet ensemble. Un dépôt a été créé et va, à terme, contenir un fichier pour chaque étudiant·es.

• Rendez vous sur la page https://git.ppom.fr/ppom/BUT1

• Vous n'avez pas les droits pour effectuer des commits sur ce dépôt, tout doit être validé par les maintainers. Forkez (bifurquez en français?) le projet en cliquant sur la Fourche en haut à droite.

• Cela va créer une copie du dépôt dans votre espace, sur laquelle vous avez la main.

• Clonez votre version du dépôt.

• Dans le dossier de votre groupe, créez un fichier dont le nom est votre username sur le site git.ppom.fr.

• Poussez cet ajout sur votre dépôt git.ppom.fr, constatez depuis l'interface web que votre fichier a bien été ajouté.

• Maintenant, pour demander aux maintainers du projet d'intégrer vos modifications, retournez sur le dépôt de base (https://git.ppom.fr/ppom/BUT1). Créez une PR demandant l'ajout de vos modifications dans la branche main du dépôt.

• Demandez à votre prof d'accepter votre PR. (Si vous finissez après le créneau de TP, on va recevoir des mails automatiques, pas besoin de nous prévenir par ailleurs; on ne vous promet pas d'être disponible directement pour valider par contre.)