From 2c724f7412652bb37cec7d14cc31aeb02867db61 Mon Sep 17 00:00:00 2001 From: Olivier Maury <olivier.maury@inrae.fr> Date: Tue, 4 Jun 2024 14:39:44 +0200 Subject: [PATCH 1/8] Typo --- scenario_branches.md | 83 ++++++++++++++++++++++---------------------- 1 file changed, 42 insertions(+), 41 deletions(-) diff --git a/scenario_branches.md b/scenario_branches.md index c45f6ce..3388ea5 100644 --- a/scenario_branches.md +++ b/scenario_branches.md @@ -1,22 +1,23 @@ -# Scénario Gitlab « branches » +# Scénario GitLab « branches » ## Action Formateur (à faire avant la formation) ### Création d'une copie du projet exercice_session3 -* Aller à la page [du projet exercice_session3](https://forgemia.inra.fr:git-gitlab-paca/exercice_session3) -* Récupération du code (tgz) projet `git@forgemia.inra.fr:git-gitlab-paca/exercice_session3.git` et installation dans un nouveau répertoire local -* Création d'un nouveau projet dans un autre espace de nom (au choix) - * Nouveau nom du projet: session3_labo - * Description: démo session 3, pour groupe ... , date ... - * Visibilité: private - * casser le lien avec le projet source (fork relationship / relation de bifurcation) via general settings/ Advanced/ Fork relationship +[Créer une bifurcation (*fork*)](https://forgemia.inra.fr/git-gitlab-paca/exercice_session3/-/forks/new) et définir + +* **nom du projet :** exercice_session3_labo +* **espace de nommage :** au choix +* **description :** démo session 3, pour groupe ... , date ... +* **visibilité :** private ### Configuration du nouveau projet -* Déclarer les membres en fonction des présents (Manage/Members), en rôle "developper" -* configuration à faire pour empêcher la modification de la branche "main" par les stagiaires: - * bloquer qui peut modifier la branche main (settings/Merge request,Merge commit with semi-linear history ) - * repository / protected branch et sur main, bloquer les push (no one ) + +* Casser le lien avec le projet source dans le menu *General settings / Advanced / Fork relationship* +* Déclarer les membres en fonction des présents (Manage/Members), en rôle "Developper" +* Définir le mode de fussion dans le menu *General settings / Merge request* : *Merge commit with semi-linear history* +* Empêcher la modification de la branche "main" par les stagiaires : + * *repository / protected branch* et sur main, bloquer les push (no one) # But de l'exercice A la place d'un code, on a mis du texte faisant référence à des évènements de l'histoire de France. @@ -25,7 +26,7 @@ Des erreurs ont été faites volontairement. Le jeu sera de les corriger, tout en adoptant les bonnes pratiques concernant l'usage des branches -La bonne pratique est ici de créer une issue et à partir de cette issue créer une branche dans laquelle on va faire la correction. A la fin, il y a autant de branches que d'issues. Chaque branche avec sa correction est ensuite fusionnée dans la branche principale, nommée main +La bonne pratique est ici de créer une issue et à partir de cette issue, créer une branche dans laquelle on va faire la correction. A la fin, il y a autant de branches que d'issues. Chaque branche avec sa correction est ensuite fusionnée dans la branche principale, nommée main. De manière générale, on rappelle que la branche main doit être la branche stable, c'est à dire celle qui porte le code le plus à jour et opérationnel. @@ -37,14 +38,14 @@ Les templates sont nommés en fonction du fichier et du chapitre concerné. ## Tous les utilisateurs -* pull du projet "fork" +* `git clone` du projet "fork" * Découverte des fichiers ## Par le formateur * Affectation des issues * Au passage, expliquer qu'il joue le rôle de chef de projet * Il explique les règles de MR (pas sur main) et que ce sont des conventions à définir/appliquer dès le début du projet -* On choisi le modèle une branche main stable, des branches par issues pour faire évoluer le code. +* On choisit le modèle une branche main stable, des branches par issues pour faire évoluer le code. # Use case idéal @@ -55,9 +56,9 @@ Les templates sont nommés en fonction du fichier et du chapitre concerné. * création d'une MR et d'une branche sur la forge * récupération de la nouvelle branche, en local -* Correction de l'erreur dans le fichier texte en question -* commit -* push +* correction de l'erreur dans le fichier texte en question +* `git commit` +* `git push` * Connexion à la forge * Activation de la demande de fusion @@ -66,35 +67,35 @@ Les templates sont nommés en fonction du fichier et du chapitre concerné. * peuvent accepter la fusion ## Le formateur -* montre le contenu de la fusion, les changements , les commits associés +* montre le contenu de la fusion, les changements, les commits associés * procède à une revue de code sur les changements proposés (option) * valide la fusion * déclenche la fusion ## Tous les utilisateurs -* pull --> mise à jour des dépôts locaux +* `git pull` --> mise à jour des dépôts locaux * A ce stade, tout le monde est synchro (même dépôt pour tous) # Use case rebasage nécessaire Deux utilisateurs vont faire des corrections sur des fichiers différents, mais la deuxième fusion va se retrouver bloquée parce que la branche à fusionner sera en retard par rapport au main. ## Utilisateurs en charge des issues Partie2_Chapitre et 3, les autres ne font rien -* ouverture de l'issue -* échange éventuel de commentaires -* création d'une MR et d'une branche sur la forge +* Ouverture de l'issue +* Échange éventuel de commentaires +* Création d'une MR et d'une branche sur la forge -* récupération de la nouvelle branche, en local +* Récupération de la nouvelle branche, en local * Correction de l'erreur dans le fichier texte en question -* éventuellement dialogue avec celui qui a signalé l'issue -* commit -* push +* Éventuellement dialogue avec celui qui a signalé l'issue +* `git commit` +* `git push` * Connexion à la forge * Activation de la demande de fusion ## Formateur * Constat que la troisième fusion ne peut être faite parce que le dépôt n'est plus à jour (il ne contient pas la fusion 2 par exemple) -* résolution du problème par rebasage (on embarque dans la branche locale ) +* Résolution du problème par rebasage (on embarque dans la branche locale ) ```bash git checkout issue3 git rebase origin/main @@ -104,15 +105,15 @@ git rebase origin/main Deux utilisateurs vont modifier la même partie d'un fichier. git ne pourra pas arbitrer par lui même. On est dans un situation dite de conflit. ## Utilisateur en charge issue Partie2_Chapitre2 -* ouverture de l'issue -* échange éventuel de commentaires -* création d'une MR et d'une branche sur la forge +* Ouverture de l'issue +* Échange éventuel de commentaires +* Création d'une MR et d'une branche sur la forge -* récupération de la nouvelle branche, en local +* Récupération de la nouvelle branche, en local * Correction de l'erreur dans le fichier texte en question -* éventuellement dialogue avec celui qui a signalé l'issue -* commit -* push +* Éventuellement dialogue avec celui qui a signalé l'issue +* `git commit` +* `git push` * Connexion à la forge * Activation de la demande de fusion @@ -121,8 +122,8 @@ Deux utilisateurs vont modifier la même partie d'un fichier. git ne pourra pas * Activation de la fusion précédente sans pull (en local, main est en retard, ainsi que la branche de l'issue) * récupération de la nouvelle branche en local * Correction de l'erreur dans le même fichier texte -* commit -* push +* `git commit` +* `git push` * Connexion à la forge * Activation de la demande de fusion * Constat de l'impossibilité à cause d'un conflit (git ne sait pas choisir laquelle des deux versions conserver) @@ -134,10 +135,10 @@ git switch Partie2_Chapitre2_bis git fetch git rebase origin/main ``` -* lire les messages retournés par git !! -* ouvrir le fichier en conflit dans un éditeur -* constater les marques de conflit -* corriger (choisir le code à conserver, supprimer l'autre, supprimer les marques de conflit) +* Lire les messages retournés par git !! +* Ouvrir le fichier en conflit dans un éditeur +* Constater les marques de conflit +* Corriger (choisir le code à conserver, supprimer l'autre, supprimer les marques de conflit) ```bash git add . -- GitLab From d42be16b4afb5fc9d226f5eedc84f4f45a4b77aa Mon Sep 17 00:00:00 2001 From: Olivier Maury <olivier.maury@inrae.fr> Date: Tue, 4 Jun 2024 14:41:10 +0200 Subject: [PATCH 2/8] Ligne vide en trop --- scenario_branches.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/scenario_branches.md b/scenario_branches.md index 3388ea5..af13e7b 100644 --- a/scenario_branches.md +++ b/scenario_branches.md @@ -54,7 +54,6 @@ Les templates sont nommés en fonction du fichier et du chapitre concerné. * ouverture de l'issue * échange éventuel de commentaires avec le commanditaire de l'issue (formateur) * création d'une MR et d'une branche sur la forge - * récupération de la nouvelle branche, en local * correction de l'erreur dans le fichier texte en question * `git commit` @@ -83,7 +82,6 @@ Deux utilisateurs vont faire des corrections sur des fichiers différents, mais * Ouverture de l'issue * Échange éventuel de commentaires * Création d'une MR et d'une branche sur la forge - * Récupération de la nouvelle branche, en local * Correction de l'erreur dans le fichier texte en question * Éventuellement dialogue avec celui qui a signalé l'issue @@ -108,7 +106,6 @@ Deux utilisateurs vont modifier la même partie d'un fichier. git ne pourra pas * Ouverture de l'issue * Échange éventuel de commentaires * Création d'une MR et d'une branche sur la forge - * Récupération de la nouvelle branche, en local * Correction de l'erreur dans le fichier texte en question * Éventuellement dialogue avec celui qui a signalé l'issue -- GitLab From f1b306894c3da64a5cf115dfe044b2488e73f7ac Mon Sep 17 00:00:00 2001 From: Olivier Maury <olivier.maury@inrae.fr> Date: Mon, 10 Jun 2024 12:33:27 +0200 Subject: [PATCH 3/8] Retour sur la session 3 du 10 juin 2024 --- 03_branches/05_04_vscode.md | 1 - 03_branches/06_03_vscode.md | 9 ++------- retour_experiences.md | 17 +++++++++++++++++ 3 files changed, 19 insertions(+), 8 deletions(-) diff --git a/03_branches/05_04_vscode.md b/03_branches/05_04_vscode.md index dc6becb..6650d90 100644 --- a/03_branches/05_04_vscode.md +++ b/03_branches/05_04_vscode.md @@ -81,7 +81,6 @@ gitGraph * sélectionner la branche à supprimer * la branche en cours ne peut être supprimée - ---vertical--- ## Travailler avec plusieurs branches simultanément diff --git a/03_branches/06_03_vscode.md b/03_branches/06_03_vscode.md index 15e9eeb..1c72a41 100644 --- a/03_branches/06_03_vscode.md +++ b/03_branches/06_03_vscode.md @@ -3,19 +3,18 @@ # Gestion des branches distantes ## avec VS Code - ---vertical--- # Récupérer une branche distante :  - - ---vertical--- ## Récupérer les modifications de la branche distante : synchroniser les modifications locales avec celles distantes  + ---vertical--- + ## Envoyer les modifications sur la branche distante : L'icône identifiée apparait tant que la branche locale n'existe pas sur le serveur distant. @@ -31,19 +30,15 @@ Il est nécessaire de passer par la ligne de commande, dans le terminal. git push -d origin remote-patch-1 ``` - - ---vertical--- ## Dans quelle branche suis-je ?  - ---vertical--- ## Quelles sont les branches ?  - diff --git a/retour_experiences.md b/retour_experiences.md index 193ffd6..52d6c94 100644 --- a/retour_experiences.md +++ b/retour_experiences.md @@ -122,3 +122,20 @@ Au bilan, encore une fois, déçu de ne pas avoir eu plus de monde. - puces « Commandes initiales sur un nouveau dépôt » dans un ordre différent des diapos suivantes - on ne peut assigner qu'une seule personne - recommandation : présenter d'un trait tout un thème et faire pratiquer (ne pas faire de démo). J'ai (Olivier) fait la démo à la place des captures d'écran et c'est trop long. Faire pratiquer permet de retenir l'attention. + +| Date | Qui | Combien | Mode | Durée |Session | +|:-: |:-: |:-: |:-: |:-: |:-: | +| 10 juin 2024 | Olivier AgroClim & Philippe URFM | 5 | Web + RStudio | 2h00 | 3 | + +- Fichiers d'exercice : + - Des problèmes d'encodage des fichiers d'exercice ont été rencontrés. + - Ajouter des retours à la ligne pour simplifier la comparaison. +- Incohérence de majuscule dans le ticket chapitre 2 partie 2. +- Expliquer `git rebase` en dehors de la gestion de conflit. +- Écrire un script pour créer les tickets automatiquement en fournissant les identifiants des élèves. +- Chaque élève n'a pu se confronter à toutes les situations : changer le scénario : + 1. Ticket tâche simple : créer une branche, corriger une ligne en local, pousser. + 2. Le formateur traite son propre ticket et fusionne. + 3. Ticket tâche simple + rebase : créer une branche, (le formateur fait un commit sur *main* sans conflit), corriger une ligne en local, pousser, observer, fetch, rebase, pull + 4. Ticket conflit +- Écrire un dérouler pour le formateur avec les points d'arrêt vers le support. \ No newline at end of file -- GitLab From 53128750360afce9d98a50e82a856a12679a56ba Mon Sep 17 00:00:00 2001 From: Philippe Clastre <philippe.clastre@inra.fr> Date: Mon, 10 Jun 2024 15:24:59 +0200 Subject: [PATCH 4/8] =?UTF-8?q?Int=C3=A9gration=20du=20retour=20de=20Phili?= =?UTF-8?q?ppe.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- retour_experiences.md | 15 ++++- scenario_branches_formateur.md | 104 ++++++++++++++++++++++++++++++ scenario_branches_utilisateurs.md | 99 ++++++++++++++++++++++++++++ 3 files changed, 215 insertions(+), 3 deletions(-) create mode 100644 scenario_branches_formateur.md create mode 100644 scenario_branches_utilisateurs.md diff --git a/retour_experiences.md b/retour_experiences.md index 52d6c94..839c430 100644 --- a/retour_experiences.md +++ b/retour_experiences.md @@ -125,17 +125,26 @@ Au bilan, encore une fois, déçu de ne pas avoir eu plus de monde. | Date | Qui | Combien | Mode | Durée |Session | |:-: |:-: |:-: |:-: |:-: |:-: | -| 10 juin 2024 | Olivier AgroClim & Philippe URFM | 5 | Web + RStudio | 2h00 | 3 | +| 10 juin 2024 | Olivier AgroClim & Philippe URFM | 5 | Web + RStudio | 2h10 | 3 | +- stagiaires, CDD, doctorants, post-doc, scientifiques : 3 AgroClim, 3 URFM +- 1 utilisateur de Mac +- Démarrage nécessitant du git config sur un poste et, sur un autre poste, constat que la clé SSH créée la dernière fois (via git gui) n'était pas trouvée lorsque l'utilisateur lance des commande git dans "git bash": la clé n'est pas cherchée dans le même répertoire !! +- on s'appuie sur le document `scenario_branche.md` qui est déjà d'une grande aide - Fichiers d'exercice : - Des problèmes d'encodage des fichiers d'exercice ont été rencontrés. - Ajouter des retours à la ligne pour simplifier la comparaison. - Incohérence de majuscule dans le ticket chapitre 2 partie 2. - Expliquer `git rebase` en dehors de la gestion de conflit. -- Écrire un script pour créer les tickets automatiquement en fournissant les identifiants des élèves. +- Temps de réalisation des issues par le formateur trop long + - Écrire un script pour créer les tickets automatiquement en fournissant les identifiants des élèves. +- besoin de simplifier les étapes pour rendre accessible le contenu qui est relativement complexe: + - issue / branche / édition / MR + - issue / branche / édition / rebase / MR + - issue / branche / édition / rebase + gestion conflit / MR - Chaque élève n'a pu se confronter à toutes les situations : changer le scénario : 1. Ticket tâche simple : créer une branche, corriger une ligne en local, pousser. 2. Le formateur traite son propre ticket et fusionne. 3. Ticket tâche simple + rebase : créer une branche, (le formateur fait un commit sur *main* sans conflit), corriger une ligne en local, pousser, observer, fetch, rebase, pull 4. Ticket conflit -- Écrire un dérouler pour le formateur avec les points d'arrêt vers le support. \ No newline at end of file +- Écrire un dérouler pour le formateur avec les points d'arrêt vers le support. diff --git a/scenario_branches_formateur.md b/scenario_branches_formateur.md new file mode 100644 index 0000000..9c13710 --- /dev/null +++ b/scenario_branches_formateur.md @@ -0,0 +1,104 @@ +# Scénario Gitlab « branches » + +Pour mémoire, un document scenario_branches_utilisateurs.md doit être fourni aux apprenants. + +Il reprend les instructions à réaliser à chaque étape. + +Le présent document est destiné au formateur afin de le guider de manière efficace dans le suivi du scénario. + +Trois cas d'utilisations sont déroulés +* use case idéal: une issue = une MR = une branche = un commit = un push = une PR +* use case rebasage: +* use case conflit: + +## Préparation formation + +### Création d'une copie du projet exercice_session3 +* Aller à la page [du projet exercice_session3](https://forgemia.inra.fr:git-gitlab-paca/exercice_session3) +* Récupération du code (tgz) projet `git@forgemia.inra.fr:git-gitlab-paca/exercice_session3.git` et installation dans un nouveau répertoire local + +* Création d'un nouveau projet dans un autre espace de nom (au choix) + * Nouveau nom du projet: session3_labo + * Description: démo session 3, pour groupe ... , date ... + * Visibilité: private + * casser le lien avec le projet source (fork relationship / relation de bifurcation) via general settings/ Advanced/ Fork relationship + +### Configuration du nouveau projet +* Déclarer les membres en fonction des présents (Manage/Members), en rôle "developper" +* configuration à faire pour empêcher la modification de la branche "main" par les stagiaires: + * bloquer qui peut modifier la branche main (settings/Merge request,Merge commit with semi-linear history ) + * repository / protected branch et sur main, bloquer les push (no one ) + + +# Use case idéal + +## (Formateur) +* Création et affectation des issues à chaque utilisateur (script à venir pour automatiser cette action car c'est un peu long) +* Au passage, expliquer qu'il joue le rôle de chef de projet +* Il explique les règles de MR (pas sur main) et que ce sont des conventions à définir/appliquer dès le début du projet +* On choisi le modèle une branche main stable, et des branches par issues pour faire évoluer le code. + +## (Formateur) démo de fusion et ménage +* montre le contenu de la fusion, les changements , les commits associés +* procède à une revue de code sur les changements proposés (option) +* valide la fusion +* déclenche la fusion +* s'il a le temps, fermeture de toutes les issues, ménage dans les branches et les MR en attente + + +# Use case rebasage +On veut illustrer ici la fonctionnalité de rebasage, sans conflit. + +Diapos: 72 à 80 + +## (Formateur) Création des issues +* Création des issues et affectation aux utilisateurs +* il s'en prévoit une pour lui, afin de faire la démo d'accompagnement + + +## (Formateur) Démo rebasage +* Constat que la troisième fusion ne peut être faite parce que le dépôt n'est plus à jour (il ne contient pas la fusion 2 par exemple) + +* résolution du problème par rebasage (on embarque dans la branche locale ) + +```bash +git checkout issue3 +git rebase origin/main +``` + +# Use case conflit +Nous allons volontairement créer une situation de conflit, que Git va vous demander de régler. + +Diapos 64 à 66 + +Un conflit apparait lorsque deux modifications ont été faite au même endroit dans un fichier. +Git ne sait pas choisir qu'elle est la version à retenir, il va donc vous inviter à résoudre le conflit vous même. + +## (Formateur) Démo résolution de conflit +* Prise en charge de l'issue Partie2_Chapitre2_bis (création branche à faire avant le push de la branche de l'issue précédente) +* Activation de la fusion précédente sans pull (en local, main est en retard, ainsi que la branche de l'issue) +* récupération de la nouvelle branche en local +* Correction de l'erreur dans le même fichier texte +* commit +* push +* Connexion à la forge +* Activation de la demande de fusion +* Constat de l'impossibilité à cause d'un conflit (git ne sait pas choisir laquelle des deux versions conserver) +* On peut voir les marques du conflit depuis les outils de la forge +* On peut aussi (bonne pratique) gérer ce conflit localement + +```bash +git switch Partie2_Chapitre2_bis +git fetch +git rebase origin/main +``` +* lire les messages retournés par git !! +* ouvrir le fichier en conflit dans un éditeur +* constater les marques de conflit +* corriger (choisir le code à conserver, supprimer l'autre, supprimer les marques de conflit) + +```bash +git add . +git commit -m "Fix conflict on issue Partie2_Chapitre2_bis" +git rebase --continue +``` \ No newline at end of file diff --git a/scenario_branches_utilisateurs.md b/scenario_branches_utilisateurs.md new file mode 100644 index 0000000..71aec00 --- /dev/null +++ b/scenario_branches_utilisateurs.md @@ -0,0 +1,99 @@ +# Scénario Gitlab « branches » + +# Présentation des principes des exercices +Un projet a été créé par le formateur et va servir de dépôt martyre. + +Vous allez donc pouvoir récupérer ce projet, et y apporter des modifications. + +Le projet en question contient plusieurs fichiers textes avec du contenu. En l'occurrence, il s'agit d'extraits racontant certains évènement de l'histoire de France. + +Dans la vraie vie, vous y rencontreriez probabement du code informatique + +Dans ces différents textes, des erreurs ont été faites volontairement. + +Le jeu sera de les corriger, tout en adoptant les bonnes pratiques concernant l'usage des branches + +La bonne pratique est ici de créer une issue (l'animateur s'en occupe) et à partir de cette issue chacun pourra créer une branche dans laquelle il va faire la correction. A la fin, il y a autant de branches que d'utilisateur et que d'issues. Chaque branche avec sa correction est ensuite proposée à la fusion (Merge request) dans la branche principale, nommée main + +De manière générale, on rappelle que la branche main doit être la branche stable, c'est à dire celle qui porte le code le plus à jour et opérationnel. + +## Les issues + +Le formateur va créer les issues en direct. Les utilisateurs recevront des mails avec un lien vers l'issue dans la forge + +# Use case idéal + +## (Utilisateur) récupération du projet +* clone du projet "fork" (cf ligne de commande: git clone git@... reçue par mail) +* Découverte des fichiers avec votre éditeur préféré + +## (Utilisateur) prendre en charge l'issue reçue (cf mail) +* ouverture de l'issue +* échange éventuel de commentaires avec le commanditaire de l'issue (formateur) +* création d'une MR et d'une branche sur la forge + +* récupération de la nouvelle branche, en local +* Correction de l'erreur dans le fichier texte en question (cf contenu de l'issue) +* commit +* push +* Connexion à la forge +* Activation de la demande de fusion + +* observent les mouvements sur la forge, les changements proposés dans le texte +* peuvent accepter la fusion +* ne peuvent pas effectuer la fusion car ils n'en ont pas les privilèges dans le contexte de la formation + +## (Utilisateur) mise en conformité du dépôt local +* git checkout main --> bascule sur la branche main +* git pull --> mise à jour de la branche main dans le dépôt local +* A ce stade, tout le monde est synchro (même version de main pour tous) +* les branches et MR créées à l'occasion de ce premier exerice peuvent être jetées. + +# Use case rebasage +On veut illustrer ici la fonctionnalité de rebasage, sans conflit. + +Une branche nécessite d'être rebasée lorsque la branche sur laquelle est elle basée (ici main) comporte des commits qu'elle ne connait pas. + +Diapos: 72 à 80 + +## (Utilisateur) prend en charge l'issue reçue (cf mail) +* ouverture de l'issue +* échange éventuel de commentaires +* création d'une MR et d'une branche sur la forge +* option: possibilité d'ajouter un voisin en reviewer du travail qui sera fait + +* récupération de la nouvelle branche (distante), en local +* Correction de l'erreur dans le fichier texte en question +* éventuellement dialogue avec celui qui a signalé l'issue +* commit +* push +* Connexion à la forge +* Activation de la demande de fusion + +## (Utilisateur) mise en conformité du dépôt local +* git checkout main --> bascule sur la branche main +* git pull --> mise à jour de la branche main dans le dépôt local +* A ce stade, tout le monde est synchro (même version de main pour tous) +* les branches et MR créées à l'occasion de ce premier exerice peuvent être jetées. + +# Use case conflit +Nous allons volontairement créer une situation de conflit, que Git va vous demander de régler. + +Diapos 64 à 66 + +Un conflit apparait lorsque deux modifications ont été faite au même endroit dans un fichier. +Git ne sait pas choisir qu'elle est la version à retenir, il va donc vous inviter à résoudre le conflit vous même. + +## (Utilisateur) prend en charge l'issue reçue (cf mail) +* ouverture de l'issue +* échange éventuel de commentaires +* création d'une MR et d'une branche sur la forge + +* récupération de la nouvelle branche, en local +* Correction de l'erreur dans le fichier texte en question +* éventuellement dialogue avec celui qui a signalé l'issue +* commit +* push +* Connexion à la forge +* Activation de la demande de fusion + -- GitLab From 9a74287b604dd75aad8724c24c51a400c83ec356 Mon Sep 17 00:00:00 2001 From: Olivier Maury <Olivier.Maury@inrae.fr> Date: Tue, 11 Jun 2024 11:12:18 +0200 Subject: [PATCH 5/8] Typo, cf 2c724f74 --- scenario_branches_formateur.md | 99 ++++++++++++----------- scenario_branches_utilisateurs.md | 130 ++++++++++++++++-------------- 2 files changed, 119 insertions(+), 110 deletions(-) diff --git a/scenario_branches_formateur.md b/scenario_branches_formateur.md index 9c13710..29e2855 100644 --- a/scenario_branches_formateur.md +++ b/scenario_branches_formateur.md @@ -1,104 +1,107 @@ -# Scénario Gitlab « branches » +# Scénario GitLab « branches » -Pour mémoire, un document scenario_branches_utilisateurs.md doit être fourni aux apprenants. +Pour mémoire, un document `scenario_branches_utilisateurs.md` doit être fourni aux apprenants. Il reprend les instructions à réaliser à chaque étape. Le présent document est destiné au formateur afin de le guider de manière efficace dans le suivi du scénario. -Trois cas d'utilisations sont déroulés -* use case idéal: une issue = une MR = une branche = un commit = un push = une PR -* use case rebasage: -* use case conflit: +Trois cas d'utilisations sont déroulés : +* use case idéal : une issue = une MR = une branche = un commit = un push = une PR +* use case rebasage : +* use case conflit : ## Préparation formation ### Création d'une copie du projet exercice_session3 -* Aller à la page [du projet exercice_session3](https://forgemia.inra.fr:git-gitlab-paca/exercice_session3) -* Récupération du code (tgz) projet `git@forgemia.inra.fr:git-gitlab-paca/exercice_session3.git` et installation dans un nouveau répertoire local -* Création d'un nouveau projet dans un autre espace de nom (au choix) - * Nouveau nom du projet: session3_labo - * Description: démo session 3, pour groupe ... , date ... - * Visibilité: private - * casser le lien avec le projet source (fork relationship / relation de bifurcation) via general settings/ Advanced/ Fork relationship +[Créer une bifurcation (*fork*) de `exercice_session3`](https://forgemia.inra.fr/git-gitlab-paca/exercice_session3/-/forks/new) et définir + +* **nom du projet :** exercice_session3_labo +* **espace de nommage :** au choix +* **description :** démo session 3, pour groupe ... , date ... ### Configuration du nouveau projet -* Déclarer les membres en fonction des présents (Manage/Members), en rôle "developper" -* configuration à faire pour empêcher la modification de la branche "main" par les stagiaires: - * bloquer qui peut modifier la branche main (settings/Merge request,Merge commit with semi-linear history ) - * repository / protected branch et sur main, bloquer les push (no one ) +* Casser le lien avec le projet source dans le menu *General settings / Advanced / Fork relationship* +* Déclarer les membres en fonction des présents (Manage/Members), en rôle "Developper" +* Définir le mode de fussion dans le menu *General settings / Merge request* : *Merge commit with semi-linear history* +* Empêcher la modification de la branche "main" par les stagiaires : + * *repository / protected branch* et sur main, bloquer les push (no one) # Use case idéal ## (Formateur) -* Création et affectation des issues à chaque utilisateur (script à venir pour automatiser cette action car c'est un peu long) -* Au passage, expliquer qu'il joue le rôle de chef de projet -* Il explique les règles de MR (pas sur main) et que ce sont des conventions à définir/appliquer dès le début du projet -* On choisi le modèle une branche main stable, et des branches par issues pour faire évoluer le code. + +* Créer et affecter des issues à chaque utilisateur (script à venir pour automatiser cette action car c'est un peu long). +* Au passage, expliquer qu'il joue le rôle de chef de projet. +* Expliquer les règles de MR (pas sur main) et que ce sont des conventions à définir/appliquer dès le début du projet. +* On choisit le modèle une branche main stable, et des branches par issues pour faire évoluer le code. ## (Formateur) démo de fusion et ménage -* montre le contenu de la fusion, les changements , les commits associés -* procède à une revue de code sur les changements proposés (option) -* valide la fusion -* déclenche la fusion -* s'il a le temps, fermeture de toutes les issues, ménage dans les branches et les MR en attente +* Montrer le contenu de la fusion, les changements, les commits associés. +* Procèder à une revue de code sur les changements proposés (option). +* valider la fusion. +* Déclenche la fusion. +* S'il y a le temps, fermer toutes les issues, faire le ménage dans les branches et les MR en attente. # Use case rebasage + On veut illustrer ici la fonctionnalité de rebasage, sans conflit. -Diapos: 72 à 80 +Diapos : 72 à 80 ## (Formateur) Création des issues -* Création des issues et affectation aux utilisateurs -* il s'en prévoit une pour lui, afin de faire la démo d'accompagnement +* Créer des issues et affecter aux utilisateurs. +* En créer aussi une pour lui, afin de faire la démo d'accompagnement. ## (Formateur) Démo rebasage -* Constat que la troisième fusion ne peut être faite parce que le dépôt n'est plus à jour (il ne contient pas la fusion 2 par exemple) -* résolution du problème par rebasage (on embarque dans la branche locale ) +* Constat que la troisième fusion ne peut être faite parce que le dépôt n'est plus à jour (il ne contient pas la fusion 2 par exemple). +* Résoudre le problème par rebasage (on embarque dans la branche locale). ```bash -git checkout issue3 +git switch issue3 git rebase origin/main ``` # Use case conflit + Nous allons volontairement créer une situation de conflit, que Git va vous demander de régler. -Diapos 64 à 66 +Diapos : 64 à 66 -Un conflit apparait lorsque deux modifications ont été faite au même endroit dans un fichier. +Un conflit apparait lorsque deux modifications ont été faites au même endroit dans un fichier. Git ne sait pas choisir qu'elle est la version à retenir, il va donc vous inviter à résoudre le conflit vous même. ## (Formateur) Démo résolution de conflit -* Prise en charge de l'issue Partie2_Chapitre2_bis (création branche à faire avant le push de la branche de l'issue précédente) -* Activation de la fusion précédente sans pull (en local, main est en retard, ainsi que la branche de l'issue) -* récupération de la nouvelle branche en local -* Correction de l'erreur dans le même fichier texte + +* Prendre en charge l'issue Partie2_Chapitre2_bis (création branche à faire avant le push de la branche de l'issue précédente) +* Activer la fusion précédente sans pull (en local, main est en retard, ainsi que la branche de l'issue) +* Récupérer la nouvelle branche en local +* Corriger l'erreur dans le même fichier texte * commit * push -* Connexion à la forge -* Activation de la demande de fusion -* Constat de l'impossibilité à cause d'un conflit (git ne sait pas choisir laquelle des deux versions conserver) -* On peut voir les marques du conflit depuis les outils de la forge -* On peut aussi (bonne pratique) gérer ce conflit localement +* Aller sur la forge +* Activer la demande de fusion +* Constater l'impossibilité à cause d'un conflit (git ne sait pas choisir laquelle des deux versions conserver) +* On peut voir les marques du conflit depuis les outils de la forge. +* On peut aussi (bonne pratique) gérer ce conflit localement. ```bash git switch Partie2_Chapitre2_bis git fetch git rebase origin/main ``` -* lire les messages retournés par git !! -* ouvrir le fichier en conflit dans un éditeur -* constater les marques de conflit -* corriger (choisir le code à conserver, supprimer l'autre, supprimer les marques de conflit) +* Lire les messages retournés par git !! +* Ouvrir le fichier en conflit dans un éditeur +* Constater les marques de conflit +* Corriger (choisir le code à conserver, supprimer l'autre, supprimer les marques de conflit) ```bash git add . git commit -m "Fix conflict on issue Partie2_Chapitre2_bis" git rebase --continue -``` \ No newline at end of file +``` diff --git a/scenario_branches_utilisateurs.md b/scenario_branches_utilisateurs.md index 71aec00..9cf2746 100644 --- a/scenario_branches_utilisateurs.md +++ b/scenario_branches_utilisateurs.md @@ -1,4 +1,4 @@ -# Scénario Gitlab « branches » +# Scénario GitLab « branches » # Présentation des principes des exercices Un projet a été créé par le formateur et va servir de dépôt martyre. @@ -7,93 +7,99 @@ Vous allez donc pouvoir récupérer ce projet, et y apporter des modifications. Le projet en question contient plusieurs fichiers textes avec du contenu. En l'occurrence, il s'agit d'extraits racontant certains évènement de l'histoire de France. -Dans la vraie vie, vous y rencontreriez probabement du code informatique +Dans la vraie vie, vous y rencontreriez probablement du code informatique. Dans ces différents textes, des erreurs ont été faites volontairement. -Le jeu sera de les corriger, tout en adoptant les bonnes pratiques concernant l'usage des branches +Le jeu sera de les corriger, tout en adoptant les bonnes pratiques concernant l'usage des branches. -La bonne pratique est ici de créer une issue (l'animateur s'en occupe) et à partir de cette issue chacun pourra créer une branche dans laquelle il va faire la correction. A la fin, il y a autant de branches que d'utilisateur et que d'issues. Chaque branche avec sa correction est ensuite proposée à la fusion (Merge request) dans la branche principale, nommée main +La bonne pratique est ici de créer une issue (l'animateur s'en occupe) et à partir de cette issue chacun pourra créer une branche dans laquelle il va faire la correction. A la fin, il y a autant de branches que d'utilisateur et que d'issues. Chaque branche avec sa correction est ensuite proposée à la fusion (Merge request) dans la branche principale, nommée `main`. -De manière générale, on rappelle que la branche main doit être la branche stable, c'est à dire celle qui porte le code le plus à jour et opérationnel. +De manière générale, on rappelle que la branche `main` doit être la branche stable, c'est à dire celle qui porte le code le plus à jour et opérationnel. ## Les issues -Le formateur va créer les issues en direct. Les utilisateurs recevront des mails avec un lien vers l'issue dans la forge +Le formateur va créer les issues en direct. Les utilisateurs recevront des mails avec un lien vers l'issue dans la forge. # Use case idéal -## (Utilisateur) récupération du projet -* clone du projet "fork" (cf ligne de commande: git clone git@... reçue par mail) -* Découverte des fichiers avec votre éditeur préféré - -## (Utilisateur) prendre en charge l'issue reçue (cf mail) -* ouverture de l'issue -* échange éventuel de commentaires avec le commanditaire de l'issue (formateur) -* création d'une MR et d'une branche sur la forge - -* récupération de la nouvelle branche, en local -* Correction de l'erreur dans le fichier texte en question (cf contenu de l'issue) -* commit -* push -* Connexion à la forge -* Activation de la demande de fusion - -* observent les mouvements sur la forge, les changements proposés dans le texte -* peuvent accepter la fusion -* ne peuvent pas effectuer la fusion car ils n'en ont pas les privilèges dans le contexte de la formation - -## (Utilisateur) mise en conformité du dépôt local -* git checkout main --> bascule sur la branche main -* git pull --> mise à jour de la branche main dans le dépôt local -* A ce stade, tout le monde est synchro (même version de main pour tous) +## Récupérer le projet + +* Cloner le projet (Cf. ligne de commande : `git clone git@...` reçue par mail). +* Parcourir les fichiers avec votre éditeur préféré. + +## Prendre en charge l'issue + +* Ouvrir sa boîte à lettres, un courriel a été envoyé par la forge. +* Lire l'issue. +* Échanger éventuellement avec le commanditaire de l'issue (formateur) pour préciser la demande. +* Créer une MR avec sa branche sur la forge. +* Récupérer la nouvelle branche distante en local. +* Corriger l'erreur dans le fichier texte en question (cf contenu de l'issue). +* `git commit` +* `git push` +* Aller sur la forge. +* Activer la demande de fusion. +* Observer les mouvements sur la forge, les changements proposés dans le texte. +* Accepter la fusion. + +L'utilisateur ne peut pas effectuer la fusion car son rôle ne le permet pas dans le contexte de la formation. + +## Mettre à jour le dépôt local +* `git switch main` pour basculer sur la branche `main`. +* `git pull` pour mettre à jour de la branche main dans le dépôt local. +* A ce stade, tout le monde est synchro (même version de `main` pour tous). * les branches et MR créées à l'occasion de ce premier exerice peuvent être jetées. # Use case rebasage On veut illustrer ici la fonctionnalité de rebasage, sans conflit. -Une branche nécessite d'être rebasée lorsque la branche sur laquelle est elle basée (ici main) comporte des commits qu'elle ne connait pas. +Une branche nécessite d'être rebasée lorsque la branche sur laquelle est elle basée (ici `main`) comporte des commits qu'elle ne connait pas. + +Diapos : 72 à 80 -Diapos: 72 à 80 +## Prend en charge l'issue reçue (cf mail) -## (Utilisateur) prend en charge l'issue reçue (cf mail) -* ouverture de l'issue -* échange éventuel de commentaires -* création d'une MR et d'une branche sur la forge -* option: possibilité d'ajouter un voisin en reviewer du travail qui sera fait +* Ouvrir sa boîte à lettres, un courriel a été envoyé par la forge. +* Lire l'issue. +* Échanger éventuellement avec le commanditaire de l'issue (formateur) pour préciser la demande. +* Créer une MR avec sa branche sur la forge. +* option : possibilité d'ajouter un voisin en relecteur (*reviewer*) du travail qui sera fait. +* Récupérer la nouvelle branche distante en local. +* Corriger l'erreur dans le fichier texte en question (cf contenu de l'issue). +* Éventuellement dialogue avec celui qui a signalé l'issue. +* `git commit` +* `git push` +* Aller sur la forge. +* Activer la demande de fusion. -* récupération de la nouvelle branche (distante), en local -* Correction de l'erreur dans le fichier texte en question -* éventuellement dialogue avec celui qui a signalé l'issue -* commit -* push -* Connexion à la forge -* Activation de la demande de fusion +## Mettre à jour le dépôt local -## (Utilisateur) mise en conformité du dépôt local -* git checkout main --> bascule sur la branche main -* git pull --> mise à jour de la branche main dans le dépôt local -* A ce stade, tout le monde est synchro (même version de main pour tous) +* `git switch main` pour basculer sur la branche `main`. +* `git pull` pour mettre à jour de la branche main dans le dépôt local. +* A ce stade, tout le monde est synchro (même version de `main` pour tous). * les branches et MR créées à l'occasion de ce premier exerice peuvent être jetées. # Use case conflit + Nous allons volontairement créer une situation de conflit, que Git va vous demander de régler. -Diapos 64 à 66 +Diapos : 64 à 66 -Un conflit apparait lorsque deux modifications ont été faite au même endroit dans un fichier. +Un conflit apparait lorsque deux modifications ont été faites au même endroit dans un fichier. Git ne sait pas choisir qu'elle est la version à retenir, il va donc vous inviter à résoudre le conflit vous même. -## (Utilisateur) prend en charge l'issue reçue (cf mail) -* ouverture de l'issue -* échange éventuel de commentaires -* création d'une MR et d'une branche sur la forge - -* récupération de la nouvelle branche, en local -* Correction de l'erreur dans le fichier texte en question -* éventuellement dialogue avec celui qui a signalé l'issue -* commit -* push -* Connexion à la forge -* Activation de la demande de fusion +## Prend en charge l'issue reçue (cf mail) + +* Ouvrir sa boîte à lettres, un courriel a été envoyé par la forge. +* Lire l'issue. +* Échanger éventuellement avec le commanditaire de l'issue (formateur) pour préciser la demande. +* Créer une MR avec sa branche sur la forge. +* Récupérer la nouvelle branche distante en local. +* Corriger l'erreur dans le fichier texte en question (cf contenu de l'issue). +* Éventuellement dialogue avec celui qui a signalé l'issue. +* `git commit` +* `git push` +* Aller sur la forge. +* Activer la demande de fusion. -- GitLab From aadbfbd9f201652fe65ef37737092bedd119abf9 Mon Sep 17 00:00:00 2001 From: Olivier Maury <Olivier.Maury@inrae.fr> Date: Tue, 11 Jun 2024 11:14:52 +0200 Subject: [PATCH 6/8] Typo --- scenario_branches_formateur.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/scenario_branches_formateur.md b/scenario_branches_formateur.md index 29e2855..1884bdd 100644 --- a/scenario_branches_formateur.md +++ b/scenario_branches_formateur.md @@ -8,7 +8,7 @@ Le présent document est destiné au formateur afin de le guider de manière eff Trois cas d'utilisations sont déroulés : * use case idéal : une issue = une MR = une branche = un commit = un push = une PR -* use case rebasage : +* use case rebasage : * use case conflit : ## Préparation formation @@ -29,6 +29,11 @@ Trois cas d'utilisations sont déroulés : * Empêcher la modification de la branche "main" par les stagiaires : * *repository / protected branch* et sur main, bloquer les push (no one) +### Envoyer par courriel l'adresse du projet + +* URL du projet dans GitLab +* adresse du dépôt `git@...` pour `git clone`. + # Use case idéal ## (Formateur) @@ -42,7 +47,7 @@ Trois cas d'utilisations sont déroulés : * Montrer le contenu de la fusion, les changements, les commits associés. * Procèder à une revue de code sur les changements proposés (option). -* valider la fusion. +* Valider la fusion. * Déclenche la fusion. * S'il y a le temps, fermer toutes les issues, faire le ménage dans les branches et les MR en attente. @@ -82,8 +87,8 @@ Git ne sait pas choisir qu'elle est la version à retenir, il va donc vous invit * Activer la fusion précédente sans pull (en local, main est en retard, ainsi que la branche de l'issue) * Récupérer la nouvelle branche en local * Corriger l'erreur dans le même fichier texte -* commit -* push +* `git commit` +* `git push` * Aller sur la forge * Activer la demande de fusion * Constater l'impossibilité à cause d'un conflit (git ne sait pas choisir laquelle des deux versions conserver) @@ -104,4 +109,4 @@ git rebase origin/main git add . git commit -m "Fix conflict on issue Partie2_Chapitre2_bis" git rebase --continue -``` +``` \ No newline at end of file -- GitLab From 76be01acb46522e8c0f4904307739b50e306e01c Mon Sep 17 00:00:00 2001 From: Olivier Maury <olivier.maury@inrae.fr> Date: Wed, 12 Jun 2024 15:56:28 +0200 Subject: [PATCH 7/8] Remarques de Philippe --- retour_experiences.md | 8 +-- scenario_branches.md | 144 ------------------------------------------ 2 files changed, 2 insertions(+), 150 deletions(-) delete mode 100644 scenario_branches.md diff --git a/retour_experiences.md b/retour_experiences.md index 839c430..c933afe 100644 --- a/retour_experiences.md +++ b/retour_experiences.md @@ -138,13 +138,9 @@ Au bilan, encore une fois, déçu de ne pas avoir eu plus de monde. - Expliquer `git rebase` en dehors de la gestion de conflit. - Temps de réalisation des issues par le formateur trop long - Écrire un script pour créer les tickets automatiquement en fournissant les identifiants des élèves. -- besoin de simplifier les étapes pour rendre accessible le contenu qui est relativement complexe: - - issue / branche / édition / MR - - issue / branche / édition / rebase / MR - - issue / branche / édition / rebase + gestion conflit / MR - Chaque élève n'a pu se confronter à toutes les situations : changer le scénario : - 1. Ticket tâche simple : créer une branche, corriger une ligne en local, pousser. + 1. Ticket tâche simple : créer une demande de fusion et sa branche, corriger une ligne en local, pousser. 2. Le formateur traite son propre ticket et fusionne. - 3. Ticket tâche simple + rebase : créer une branche, (le formateur fait un commit sur *main* sans conflit), corriger une ligne en local, pousser, observer, fetch, rebase, pull + 3. Ticket tâche simple + rebase : créer une demande de fusion et sa branche, (le formateur fait un commit sur *main* sans conflit), corriger une ligne en local, pousser, observer, fetch, rebase, pull 4. Ticket conflit - Écrire un dérouler pour le formateur avec les points d'arrêt vers le support. diff --git a/scenario_branches.md b/scenario_branches.md deleted file mode 100644 index af13e7b..0000000 --- a/scenario_branches.md +++ /dev/null @@ -1,144 +0,0 @@ -# Scénario GitLab « branches » - -## Action Formateur (à faire avant la formation) - -### Création d'une copie du projet exercice_session3 - -[Créer une bifurcation (*fork*)](https://forgemia.inra.fr/git-gitlab-paca/exercice_session3/-/forks/new) et définir - -* **nom du projet :** exercice_session3_labo -* **espace de nommage :** au choix -* **description :** démo session 3, pour groupe ... , date ... -* **visibilité :** private - -### Configuration du nouveau projet - -* Casser le lien avec le projet source dans le menu *General settings / Advanced / Fork relationship* -* Déclarer les membres en fonction des présents (Manage/Members), en rôle "Developper" -* Définir le mode de fussion dans le menu *General settings / Merge request* : *Merge commit with semi-linear history* -* Empêcher la modification de la branche "main" par les stagiaires : - * *repository / protected branch* et sur main, bloquer les push (no one) - -# But de l'exercice -A la place d'un code, on a mis du texte faisant référence à des évènements de l'histoire de France. - -Des erreurs ont été faites volontairement. - -Le jeu sera de les corriger, tout en adoptant les bonnes pratiques concernant l'usage des branches - -La bonne pratique est ici de créer une issue et à partir de cette issue, créer une branche dans laquelle on va faire la correction. A la fin, il y a autant de branches que d'issues. Chaque branche avec sa correction est ensuite fusionnée dans la branche principale, nommée main. - -De manière générale, on rappelle que la branche main doit être la branche stable, c'est à dire celle qui porte le code le plus à jour et opérationnel. - -## Les issues - -Le formateur créé les issues en direct, en utilisant les templates fournis, qui contiennent les corrigés. - -Les templates sont nommés en fonction du fichier et du chapitre concerné. - - -## Tous les utilisateurs -* `git clone` du projet "fork" -* Découverte des fichiers - -## Par le formateur -* Affectation des issues -* Au passage, expliquer qu'il joue le rôle de chef de projet -* Il explique les règles de MR (pas sur main) et que ce sont des conventions à définir/appliquer dès le début du projet -* On choisit le modèle une branche main stable, des branches par issues pour faire évoluer le code. - - -# Use case idéal - -## Utilisateur en charge de l'issue Partie1_Chapitre1, les autres ne font rien -* ouverture de l'issue -* échange éventuel de commentaires avec le commanditaire de l'issue (formateur) -* création d'une MR et d'une branche sur la forge -* récupération de la nouvelle branche, en local -* correction de l'erreur dans le fichier texte en question -* `git commit` -* `git push` -* Connexion à la forge -* Activation de la demande de fusion - -## Tous les utilisateurs -* observent les mouvements sur la forge, les changements proposés dans le texte -* peuvent accepter la fusion - -## Le formateur -* montre le contenu de la fusion, les changements, les commits associés -* procède à une revue de code sur les changements proposés (option) -* valide la fusion -* déclenche la fusion - -## Tous les utilisateurs -* `git pull` --> mise à jour des dépôts locaux -* A ce stade, tout le monde est synchro (même dépôt pour tous) - -# Use case rebasage nécessaire -Deux utilisateurs vont faire des corrections sur des fichiers différents, mais la deuxième fusion va se retrouver bloquée parce que la branche à fusionner sera en retard par rapport au main. - -## Utilisateurs en charge des issues Partie2_Chapitre et 3, les autres ne font rien -* Ouverture de l'issue -* Échange éventuel de commentaires -* Création d'une MR et d'une branche sur la forge -* Récupération de la nouvelle branche, en local -* Correction de l'erreur dans le fichier texte en question -* Éventuellement dialogue avec celui qui a signalé l'issue -* `git commit` -* `git push` -* Connexion à la forge -* Activation de la demande de fusion - -## Formateur -* Constat que la troisième fusion ne peut être faite parce que le dépôt n'est plus à jour (il ne contient pas la fusion 2 par exemple) - -* Résolution du problème par rebasage (on embarque dans la branche locale ) -```bash -git checkout issue3 -git rebase origin/main -``` - -# Use case conflit -Deux utilisateurs vont modifier la même partie d'un fichier. git ne pourra pas arbitrer par lui même. On est dans un situation dite de conflit. - -## Utilisateur en charge issue Partie2_Chapitre2 -* Ouverture de l'issue -* Échange éventuel de commentaires -* Création d'une MR et d'une branche sur la forge -* Récupération de la nouvelle branche, en local -* Correction de l'erreur dans le fichier texte en question -* Éventuellement dialogue avec celui qui a signalé l'issue -* `git commit` -* `git push` -* Connexion à la forge -* Activation de la demande de fusion - -## Formateur -* Prise en charge de l'issue Partie2_Chapitre2_bis (création branche à faire avant le push de la branche de l'issue précédente) -* Activation de la fusion précédente sans pull (en local, main est en retard, ainsi que la branche de l'issue) -* récupération de la nouvelle branche en local -* Correction de l'erreur dans le même fichier texte -* `git commit` -* `git push` -* Connexion à la forge -* Activation de la demande de fusion -* Constat de l'impossibilité à cause d'un conflit (git ne sait pas choisir laquelle des deux versions conserver) -* On peut voir les marques du conflit depuis les outils de la forge -* On peut aussi (bonne pratique) gérer ce conflit localement - -```bash -git switch Partie2_Chapitre2_bis -git fetch -git rebase origin/main -``` -* Lire les messages retournés par git !! -* Ouvrir le fichier en conflit dans un éditeur -* Constater les marques de conflit -* Corriger (choisir le code à conserver, supprimer l'autre, supprimer les marques de conflit) - -```bash -git add . -git commit -m "Fix conflict on issue Partie2_Chapitre2_bis" -git rebase --continue -``` \ No newline at end of file -- GitLab From 0e89fea8a3dd9dda6565ce130ac2def992a3e304 Mon Sep 17 00:00:00 2001 From: Philippe Clastre <philippe.clastre@inra.fr> Date: Wed, 12 Jun 2024 16:27:10 +0200 Subject: [PATCH 8/8] =?UTF-8?q?suppression=20des=20fichiers=20de=20sc?= =?UTF-8?q?=C3=A9narios=20sur=20les=20branches=20pour=20les=20mettre=20dan?= =?UTF-8?q?s=20le=20projet=20exercice=5Fsession=5F3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- scenario_branches_formateur.md | 112 ------------------------------ scenario_branches_utilisateurs.md | 105 ---------------------------- 2 files changed, 217 deletions(-) delete mode 100644 scenario_branches_formateur.md delete mode 100644 scenario_branches_utilisateurs.md diff --git a/scenario_branches_formateur.md b/scenario_branches_formateur.md deleted file mode 100644 index 1884bdd..0000000 --- a/scenario_branches_formateur.md +++ /dev/null @@ -1,112 +0,0 @@ -# Scénario GitLab « branches » - -Pour mémoire, un document `scenario_branches_utilisateurs.md` doit être fourni aux apprenants. - -Il reprend les instructions à réaliser à chaque étape. - -Le présent document est destiné au formateur afin de le guider de manière efficace dans le suivi du scénario. - -Trois cas d'utilisations sont déroulés : -* use case idéal : une issue = une MR = une branche = un commit = un push = une PR -* use case rebasage : -* use case conflit : - -## Préparation formation - -### Création d'une copie du projet exercice_session3 - -[Créer une bifurcation (*fork*) de `exercice_session3`](https://forgemia.inra.fr/git-gitlab-paca/exercice_session3/-/forks/new) et définir - -* **nom du projet :** exercice_session3_labo -* **espace de nommage :** au choix -* **description :** démo session 3, pour groupe ... , date ... - -### Configuration du nouveau projet - -* Casser le lien avec le projet source dans le menu *General settings / Advanced / Fork relationship* -* Déclarer les membres en fonction des présents (Manage/Members), en rôle "Developper" -* Définir le mode de fussion dans le menu *General settings / Merge request* : *Merge commit with semi-linear history* -* Empêcher la modification de la branche "main" par les stagiaires : - * *repository / protected branch* et sur main, bloquer les push (no one) - -### Envoyer par courriel l'adresse du projet - -* URL du projet dans GitLab -* adresse du dépôt `git@...` pour `git clone`. - -# Use case idéal - -## (Formateur) - -* Créer et affecter des issues à chaque utilisateur (script à venir pour automatiser cette action car c'est un peu long). -* Au passage, expliquer qu'il joue le rôle de chef de projet. -* Expliquer les règles de MR (pas sur main) et que ce sont des conventions à définir/appliquer dès le début du projet. -* On choisit le modèle une branche main stable, et des branches par issues pour faire évoluer le code. - -## (Formateur) démo de fusion et ménage - -* Montrer le contenu de la fusion, les changements, les commits associés. -* Procèder à une revue de code sur les changements proposés (option). -* Valider la fusion. -* Déclenche la fusion. -* S'il y a le temps, fermer toutes les issues, faire le ménage dans les branches et les MR en attente. - -# Use case rebasage - -On veut illustrer ici la fonctionnalité de rebasage, sans conflit. - -Diapos : 72 à 80 - -## (Formateur) Création des issues - -* Créer des issues et affecter aux utilisateurs. -* En créer aussi une pour lui, afin de faire la démo d'accompagnement. - -## (Formateur) Démo rebasage - -* Constat que la troisième fusion ne peut être faite parce que le dépôt n'est plus à jour (il ne contient pas la fusion 2 par exemple). -* Résoudre le problème par rebasage (on embarque dans la branche locale). - -```bash -git switch issue3 -git rebase origin/main -``` - -# Use case conflit - -Nous allons volontairement créer une situation de conflit, que Git va vous demander de régler. - -Diapos : 64 à 66 - -Un conflit apparait lorsque deux modifications ont été faites au même endroit dans un fichier. -Git ne sait pas choisir qu'elle est la version à retenir, il va donc vous inviter à résoudre le conflit vous même. - -## (Formateur) Démo résolution de conflit - -* Prendre en charge l'issue Partie2_Chapitre2_bis (création branche à faire avant le push de la branche de l'issue précédente) -* Activer la fusion précédente sans pull (en local, main est en retard, ainsi que la branche de l'issue) -* Récupérer la nouvelle branche en local -* Corriger l'erreur dans le même fichier texte -* `git commit` -* `git push` -* Aller sur la forge -* Activer la demande de fusion -* Constater l'impossibilité à cause d'un conflit (git ne sait pas choisir laquelle des deux versions conserver) -* On peut voir les marques du conflit depuis les outils de la forge. -* On peut aussi (bonne pratique) gérer ce conflit localement. - -```bash -git switch Partie2_Chapitre2_bis -git fetch -git rebase origin/main -``` -* Lire les messages retournés par git !! -* Ouvrir le fichier en conflit dans un éditeur -* Constater les marques de conflit -* Corriger (choisir le code à conserver, supprimer l'autre, supprimer les marques de conflit) - -```bash -git add . -git commit -m "Fix conflict on issue Partie2_Chapitre2_bis" -git rebase --continue -``` \ No newline at end of file diff --git a/scenario_branches_utilisateurs.md b/scenario_branches_utilisateurs.md deleted file mode 100644 index 9cf2746..0000000 --- a/scenario_branches_utilisateurs.md +++ /dev/null @@ -1,105 +0,0 @@ -# Scénario GitLab « branches » - -# Présentation des principes des exercices -Un projet a été créé par le formateur et va servir de dépôt martyre. - -Vous allez donc pouvoir récupérer ce projet, et y apporter des modifications. - -Le projet en question contient plusieurs fichiers textes avec du contenu. En l'occurrence, il s'agit d'extraits racontant certains évènement de l'histoire de France. - -Dans la vraie vie, vous y rencontreriez probablement du code informatique. - -Dans ces différents textes, des erreurs ont été faites volontairement. - -Le jeu sera de les corriger, tout en adoptant les bonnes pratiques concernant l'usage des branches. - -La bonne pratique est ici de créer une issue (l'animateur s'en occupe) et à partir de cette issue chacun pourra créer une branche dans laquelle il va faire la correction. A la fin, il y a autant de branches que d'utilisateur et que d'issues. Chaque branche avec sa correction est ensuite proposée à la fusion (Merge request) dans la branche principale, nommée `main`. - -De manière générale, on rappelle que la branche `main` doit être la branche stable, c'est à dire celle qui porte le code le plus à jour et opérationnel. - -## Les issues - -Le formateur va créer les issues en direct. Les utilisateurs recevront des mails avec un lien vers l'issue dans la forge. - -# Use case idéal - -## Récupérer le projet - -* Cloner le projet (Cf. ligne de commande : `git clone git@...` reçue par mail). -* Parcourir les fichiers avec votre éditeur préféré. - -## Prendre en charge l'issue - -* Ouvrir sa boîte à lettres, un courriel a été envoyé par la forge. -* Lire l'issue. -* Échanger éventuellement avec le commanditaire de l'issue (formateur) pour préciser la demande. -* Créer une MR avec sa branche sur la forge. -* Récupérer la nouvelle branche distante en local. -* Corriger l'erreur dans le fichier texte en question (cf contenu de l'issue). -* `git commit` -* `git push` -* Aller sur la forge. -* Activer la demande de fusion. -* Observer les mouvements sur la forge, les changements proposés dans le texte. -* Accepter la fusion. - -L'utilisateur ne peut pas effectuer la fusion car son rôle ne le permet pas dans le contexte de la formation. - -## Mettre à jour le dépôt local -* `git switch main` pour basculer sur la branche `main`. -* `git pull` pour mettre à jour de la branche main dans le dépôt local. -* A ce stade, tout le monde est synchro (même version de `main` pour tous). -* les branches et MR créées à l'occasion de ce premier exerice peuvent être jetées. - -# Use case rebasage -On veut illustrer ici la fonctionnalité de rebasage, sans conflit. - -Une branche nécessite d'être rebasée lorsque la branche sur laquelle est elle basée (ici `main`) comporte des commits qu'elle ne connait pas. - -Diapos : 72 à 80 - -## Prend en charge l'issue reçue (cf mail) - -* Ouvrir sa boîte à lettres, un courriel a été envoyé par la forge. -* Lire l'issue. -* Échanger éventuellement avec le commanditaire de l'issue (formateur) pour préciser la demande. -* Créer une MR avec sa branche sur la forge. -* option : possibilité d'ajouter un voisin en relecteur (*reviewer*) du travail qui sera fait. -* Récupérer la nouvelle branche distante en local. -* Corriger l'erreur dans le fichier texte en question (cf contenu de l'issue). -* Éventuellement dialogue avec celui qui a signalé l'issue. -* `git commit` -* `git push` -* Aller sur la forge. -* Activer la demande de fusion. - -## Mettre à jour le dépôt local - -* `git switch main` pour basculer sur la branche `main`. -* `git pull` pour mettre à jour de la branche main dans le dépôt local. -* A ce stade, tout le monde est synchro (même version de `main` pour tous). -* les branches et MR créées à l'occasion de ce premier exerice peuvent être jetées. - -# Use case conflit - -Nous allons volontairement créer une situation de conflit, que Git va vous demander de régler. - -Diapos : 64 à 66 - -Un conflit apparait lorsque deux modifications ont été faites au même endroit dans un fichier. -Git ne sait pas choisir qu'elle est la version à retenir, il va donc vous inviter à résoudre le conflit vous même. - -## Prend en charge l'issue reçue (cf mail) - -* Ouvrir sa boîte à lettres, un courriel a été envoyé par la forge. -* Lire l'issue. -* Échanger éventuellement avec le commanditaire de l'issue (formateur) pour préciser la demande. -* Créer une MR avec sa branche sur la forge. -* Récupérer la nouvelle branche distante en local. -* Corriger l'erreur dans le fichier texte en question (cf contenu de l'issue). -* Éventuellement dialogue avec celui qui a signalé l'issue. -* `git commit` -* `git push` -* Aller sur la forge. -* Activer la demande de fusion. - -- GitLab