simplification de la partie git collaboratif (plus besoin de définir une stratégie par défaut)

Author: avouacr

slides/_git_collab.qmd

@@ -14,62 +14,40 @@
 
 {{< include applications_git/_application4a.qmd >}}
 
-## Divergence d'historiques : cas simple
-
-![](img/ff.png)
-
-
-- `Git` résout le problème via un [***fast-forward merge***]{.blue2}
-    - Le commit distant est rajouté à l'historique local
-    - Les dépôts sont synchronisés
-
-## Divergence d'historiques : cas compliqué
+## Divergence d'historiques : cas simple {auto-animate=true}
 
 ![](img/divergence.png)
 
+- Si les deux *commits* concernent des **parties séparées du projet**, un `pull` préalable suffit à résoudre le problème
+    
 
-- `Git` ne peut pas résoudre de lui même la divergence
-
-
-- Deux stratégies possibles
-    - Le [**merge**]{.blue2}
-    - Le [**rebase**]{.blue2}
-
-## 1ère possibilité : le *merge*
-
-![](img/merge.png)
-
+## Divergence d'historiques : cas simple {auto-animate=true}
 
-- `Git` crée un [**commit de merge**]{.blue2}
-    - Comportement par défaut (jusqu'à récemment)
+![](img/merge_commit_local.png)
 
+- `Git` fusionne les deux *commits* en un [***merge commit***]{.blue2}
+    - Les deux *commits* existent toujours dans l'historique !
+    - L'historique est réconcilié → on peut `push`
 
-- [**Inconvénient**]{.orange} : rend l'[**historique non-linéaire**]{.blue2} ([plus d'explications](https://www.atlassian.com/fr/git/tutorials/using-branches/git-merge))
+## Divergence d'historiques : cas simple {auto-animate=true}
 
-## 2ème possibilité : le *rebase* (1/2)
+![](img/merge_commit_remote.png)
 
-![](img/rebase1.png)
+- Le dépôt local et le dépôt distant sont synchronisés 🤗
 
+{{< include applications_git/_application4b.qmd >}}
 
-- `Git` effectue 3 étapes
-    - Supprime temporairement le commit local
-    - Réalise un *fast-forward merge*
-    - Rajoute le commit local au bout de l'historique
-
-## 2ème possibilité : le *rebase* (2/2)
-
-![](img/rebase2.png)
-
-
-- [**Avantage**]{.orange} : l'historique reste [**linéaire**]{.blue2}
-
+{{< include applications_git/_application5a.qmd >}}
 
-- [**Attention**]{.orange} : ne jamais *rebase* des commits déjà poussés sur un dépôt public ([plus d'explications](https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Rebaser-Rebasing#s_rebase_peril))
+## Divergence d'historiques : cas compliqué
 
+![](img/divergence.png)
 
-{{< include applications_git/_application4b.qmd >}}
+- Si les deux *commits* modifient les **mêmes parties du projet**, un `pull` ne suffit plus à résoudre le problème
+    - `Git` ne peut pas décider quelle version prioriser 🤔
+    - Il faut lui indiquer comment **résoudre le conflit**
 
-{{< include applications_git/_application5.qmd >}}
+{{< include applications_git/_application5b.qmd >}}
 
 
 ## Le modèle des branches {auto-animate=true}

slides/_git_fundamentals.qmd

@@ -135,7 +135,7 @@ L'utilisation de `Git` nécessite [__certaines notions préalables__]{.orange}:
 - Utilisation en ligne de commandes
 - Différentes [__interfaces graphiques__]{.blue2} (`RStudio`, `VS Code`...)
 
-## Concepts {auto-animate=true}
+## Concepts
 
 #### `Git`, `GitHub`, `GitLab`... quelles différences ?
 

slides/applications_git/_application0.qmd

@@ -37,7 +37,7 @@
 5. Cloner le dépôt distant sur votre environnement local (ici, le `RStudio` de la plateforme `LS3`):
     + `File` → `New project` → `Version Control` → `Git`
 6. [Générer un *token*](https://gitlab.insee.fr/-/user_settings/personal_access_tokens) (jeton d'authentification) sur `gitlab.insee.fr`
-7. Stocker le *token* sur `LS3` (ou un gestionnaire de mot de passe) :
+7. Stocker le *token* sur `LS3` :
     + `Mon Compte` -> `Git` -> `Token d'accès personnel pour Forge Git`
 8. Terminer la procédure de clonage en fournissant le nom d'utilisateur (IDEP) et le *token*
 :::
@@ -46,4 +46,4 @@
 
 :::
 
-❓ **Question** : qu'est ce qui différencie le projet cloné d'un projet quelconque ?
+❓ **Questions** : qu'est ce qui différencie le projet cloné d'un projet quelconque ?

slides/applications_git/_application4a.qmd

@@ -1,18 +1,18 @@
 ## Application 4 {.smaller}
 
 :::{.callout-tip collapse="true" icon=false}
-## Synchronisation des dépôts
+## Divergence d'historiques : cas simple
 
 ::: {.nonincremental}
 1. Se mettre par [__groupes de 3/4 personnes__]{.orange}:
     - Une personne aura la responsabilité d’être [**mainteneur**]{.blue2}
     - Deux à trois personnes seront [**développeurs**]{.blue2}
-2. Le mainteneur crée un dépôt sur `Github` / `Gitlab`. Il/Elle donne des droits au(x) développeur(s) du projet
-3. Créer une copie locale (clone) du projet sur son service `RStudio`
-4. Créer un fichier `<votre_nom>-<votre_prenom>.md`. Écrire dedans trois phrases de son choix sans ponctuation ni majuscules, puis `commit` et `push` les modifications
+2. Le mainteneur crée un dépôt sur `Github` / `Gitlab`. Il/Elle donne des **droits de niveau *maintainer*** aux membres du projet
+3. Chaque membre du groupe crée un nouveau service `RStudio` et clone le dépôt commun du groupe. Conseil : utiliser l'interface d'Onyxia pour cloner directement le dépôt avec le *token* intégré -> plus besoin de renseigner le *token* à chaque `push` !
+4. Créer un fichier `<votre_nom>-<votre_prenom>.md`. Écrire dedans quelques lignes de son choix, puis `commit` et `push` les modifications
 5. __À ce stade, une seule personne (la plus rapide) devrait ne pas avoir rencontré de rejet du `push`.__
-C’est normal ! Le premier ayant fait un `push` a modifié le dépôt commun ; les autres doivent intégrer ces modifications dans leur version locale (`pull`) avant d’avoir le droit de proposer un changement.
-6. Néanmoins, le `pull` renvoie également une erreur : `Git` ne parvient pas à résoudre la divergence d'historique. Essayons de comprendre le problème et les solutions possibles.
 :::
 
 :::
+
+❓ **Question** : pourquoi les autres membres ne peuvent pas `push` normalement ? Indice : le message d'erreur de `Git` donne la réponse !

slides/applications_git/_application4b.qmd

@@ -1,14 +1,12 @@
-## Application 4 {.smaller}
+## Application 4 (suite) {.smaller}
 
 :::{.callout-tip collapse="true" icon=false}
-## Synchronisation des dépôts
+## Divergence d'historiques : cas simple
 
 ::: {.nonincremental}
-7. Dans notre cas, on va conserver le précédent défaut (le *commit* de *merge*). Comme l'interface `RStudio` ne permet pas (encore) de sélectionner la stratégie de `pull`, on va préciser la configuration voulue via une commande passée dans le terminal
-    + `git config pull.rebase false`
-8. Pour ceux dont le `push` a été refusé, effectuer un `pull` des modifications distantes via l'interface `RStudio`
-9. Effectuer à nouveau un `push` de vos modifications locales
-10. Les derniers membres du groupe devront refaire les étapes précédentes, potentiellement plusieurs fois, pour pouvoir `push` leurs modifications locales
+7. Pour ceux dont le `push` a été refusé, effectuer un `pull` des modifications distantes via l'interface `RStudio`
+8. Effectuer à nouveau un `push` de vos modifications locales
+9. Les derniers membres du groupe devront refaire les étapes précédentes, potentiellement plusieurs fois, pour pouvoir `push` leurs modifications locales
 :::
 
 :::

slides/applications_git/_application5.qmd

@@ -0,0 +1,15 @@
+## Application 5 {.smaller}
+
+:::{.callout-tip collapse="true" icon=false}
+## Divergence d'historiques : cas compliqué
+
+::: {.nonincremental}
+1. Avant de commencer cette application, chaque membre du groupe doit avoir réussi à `push` ses modifications de l'application précédente (éventuellement après plusieurs tentatives selon le nombre de membres du groupe)
+2. Le mainteneur modifie le contenu de son fichier, puis `commit` et `push` les modifications
+3. **Sans faire de `pull` préalable**, les autres membres modifient chacun de leur côté **le contenu du fichier du mainteneur**, puis `commit` et `push` les modifications
+4. Le `push` est rejeté pour la même raison que dans l'application précédente : les dépôts ne sont plus synchronisés, il faut `pull` les changements distants au préalable. Mais **cette fois, le `pull` est également rejeté** 😱
+:::
+
+:::
+
+❓ **Question** : pourquoi le `pull` est cette fois impossible ?

slides/applications_git/_application5a.qmd

@@ -0,0 +1,15 @@
+## Application 5 (suite) {.smaller}
+
+:::{.callout-tip collapse="true" icon=false}
+## Divergence d'historiques : résolution de conflits
+
+::: {.nonincremental}
+1. Ouvrir le fichier concerné, et analyser la structure d'un conflit
+2. Résoudre le conflit en choisissant quelle information retenir : le local ? le distant ? les deux ? aucun des deux ? 
+3. **Un conflit est considéré comme résolvable par `Git` dès lors que toutes les lignes de balise ont disparu**. Pour finir la résolution, `commit`/`push` les modifications
+4. Comme dans l'application précédente, seul le membre le plus rapide parvient à `push`. Les autres doivent répéter l'opération autant de fois qu'il y a de conflits.
+:::
+
+:::
+
+❓ **Question** : comment limiter au maximum la survenue des conflits d'historique en pratique ?