Git, modifs suite au cours de 2024 (#568)

* issues

* no readme

* historique

Author: linogaliana

content/git/exogit.qmd

@@ -34,6 +34,13 @@ la branche en question disparaît :
 
 ![](https://inseefrlab.github.io/formation-bonnes-pratiques-git-R/slides/img/ghflow.png)
 
+<details>
+
+<summary>
+
+Des _workflows_ plus complexes existent pour les projets de grande envergure.
+
+</summary>
 
 Il existe des *workflows* plus complexes, notamment le `Git Flow` que j'utilise
 pour développer ce cours. [Ce tutoriel](https://www.atlassian.com/fr/git/tutorials/comparing-workflows/gitflow-workflow), très bien fait, 
@@ -45,6 +52,8 @@ Cette fois, une branche intermédiaire, par exemple une branche `development`,
 intègre des modifications à tester avant de les intégrer dans la version 
 officielle (`main`).
 
+</details>
+
 ::: {.tip}
 Vous pourrez trouvez des dizaines d’articles et d’ouvrages sur ce sujet dont chacun prétend avoir trouvé la meilleure organisation du travail (_Git flow_, _GitHub flow_, _GitLab flow_...). Ne lisez pas trop ces livres et articles sinon vous serez perdus (un peu comme avec les magazines destinés aux jeunes parents...).
 
@@ -81,7 +90,7 @@ En revanche, l'intégration des dernières modifications de `main` vers une bran
 
 Imaginons deux personnes qui collaborent sur un projet, Alice et Bob. Bob a mis de côté le projet quelques jours. Il veut récupérer les avancées faites par Alice pendant cette période. Celle-ci a fait évoluer le projet, supposons avec un seul _commit_ puisque cela ne change rien. 
 
-![](https://inseefrlab.github.io/formation-bonnes-pratiques-git-R/slides/img/ff.png){#fig-history-simple}
+![Historique de Bob en retard (cas simple)](https://inseefrlab.github.io/formation-bonnes-pratiques-git-R/slides/img/ff.png){#fig-history-simple}
 
 L'historique de Bob est cohérent avec celui sur `Github`, il lui manque juste le dernier _commit_ en bleu (@fig-history-simple). Il suffit donc à Bob de récupérer ce _commit_ en local avant de commencer à éditer ses fichiers.
 
@@ -95,16 +104,18 @@ Maintenant, imaginons le cas plus compliqué où Bob avait fait évoluer son cod
 
 Son historique local diverge donc de l'historique distant:
 
-![](https://inseefrlab.github.io/formation-bonnes-pratiques-git-R/slides/img/ff.png){#fig-history-complicated}
+![Historique de Bob en retard (cas plus compliqué)](https://inseefrlab.github.io/formation-bonnes-pratiques-git-R/slides/img/divergence.png){#fig-history-complicated}
 
 Les derniers commits ne sont pas les mêmes. `Git` ne peut pas résoudre de lui-même la divergence. C'est à Bob de trancher sur la version qu'il préfère. Deux stratégies pour réconcilier les historiques sont accessibles:
 
 * Le _merge_ ;
 * Le _rebase_.
 
-![](https://inseefrlab.github.io/formation-bonnes-pratiques-git-R/slides/img/merge.png){#fig-history-merge}
+La première méthode, la plus simple, est le _merge_. 
 
-Le rapatriement des modifications d'Alice dans l'historique de Bob crée un premier commit de merge. Les fichiers en question présenteront alors des balises permettant d'identifier la divergence de version et la source de celle-ci. Dans le fichier brut, cela donnera
+![Historique de Bob en retard: résolution par _merge_](https://inseefrlab.github.io/formation-bonnes-pratiques-git-R/slides/img/merge.png){#fig-history-merge}
+
+Le rapatriement des modifications d'Alice dans l'historique de Bob crée un premier commit de _merge_. Les fichiers en question présenteront alors des balises permettant d'identifier la divergence de version et la source de celle-ci. Dans le fichier brut, cela donnera
 
   ```python
   import pandas as pd
@@ -124,20 +135,23 @@ Le rapatriement des modifications d'Alice dans l'historique de Bob crée un prem
 
 Une fois les versions réconciliées, il ne reste plus qu'à faire un nouveau _commit_. Cette histoire réconcilie les versions d'Alice et Bob. L'inconvénient est qu'elle rend l'historique non linéaire (voir la [documentation d'Atlassian](https://www.atlassian.com/fr/git/tutorials/using-branches/git-merge) pour plus de détails) mais c'est `Git` qui a géré automatiquement ce sujet en créant une branche temporaire. Jusqu'à récemment, ceci était le comportement par défaut de `Git`. 
 
-Une autre approche est accessible, le _rebase_. 
+Une autre approche est accessible, le _rebase_. _In fine_ ceci va correspondre à cet historique, propre. 
 
 ![](https://inseefrlab.github.io/formation-bonnes-pratiques-git-R/slides/img/rebase1.png){#fig-history-rebase1}
 
-`Git` effectue trois étapes: 
+Néanmoins ceci implique des étapes intermédiaires qui consistent à réécrire l'historique, ce qui est déjà une opération avancée. En fait, `Git` effectue trois étapes: 
 
 1. Supprime temporairement le _commit_ local
 2. Réalise un _fast forward merge_ maintenant que le _commit_ local n'est plus là
 3. Rajoute le commit local au bout de l'historique
 
 ![](https://inseefrlab.github.io/formation-bonnes-pratiques-git-R/slides/img/rebase2.png){#fig-history-rebase2}
 
-Le _commit_ local a changé d'identité, ce qui explique son nouveau SHA. Cette approche présente l'avantage de garder un historique linéaire. Néanmoins, elle peut avoir des effects de bord et est donc à utiliser avec précaution (plus d'explications dans [la documentation de `Git`](https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Rebaser-Rebasing#s_rebase_peril))
+Le _commit_ local a changé d'identité, ce qui explique son nouveau SHA. Cette approche présente l'avantage de garder un historique linéaire. Néanmoins, elle peut avoir des effects de bord et est donc à utiliser avec précaution (plus d'explications dans [la documentation de `Git`](https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Rebaser-Rebasing#s_rebase_peril)). Quand on débute, et même après, il est recommandé de privilégier la méthode _merge_. Pour cela, en ligne de commande, il faut taper la commande
 
+```shell
+git config pull.rebase false
+```
 
 # Mise en pratique
 
@@ -150,7 +164,7 @@ Cet exercice se fait par groupe de trois ou quatre. Il y aura deux rôles dans c
 - Une personne aura la responsabilité d'être **mainteneur**
 - Deux à trois personnes seront **développeurs**. 
 
-1️⃣ Le.la mainteneur.e crée un dépôt sur `Github` avec un `README` et un `.gitignore`. Il/Elle donne des droits au(x) développeur.euse(s) du projet (`Settings > Manage Access > Invite a collaborator`).
+1️⃣ Le.la mainteneur.e crée un dépôt sur `Github` __sans cliquer sur l'option `Add a README`__. Créer un `.gitignore` selon le modèle `Python`. Il/Elle donne des droits au(x) développeur.euse(s) du projet (`Settings > Manage Access > Invite a collaborator`).
 
 2️⃣ Chaque membre du projet, crée une copie locale du projet (un _clone_). Si vous avez un trou de mémoire, vous pouvez retourner au chapitre précédent pour vérifier la démarche.
 

content/git/introgit.qmd

@@ -969,7 +969,7 @@ Le prochain exercice vise à illustrer le principe des branches en inventant un
 ::: {.exercise}
 ## Exercice 9: Créer une nouvelle branche et l'intégrer dans `main`
 
-1️⃣ Ouvrir une *issue* sur `Github`. Signaler qu'il serait bien d'ajouter un emoji chat dans le README. Dans la partie de droite, cliquer sur la petite roue à côté de `Label` et cliquer sur `Edit Labels`. Créer un label `Markdown`. Normalement, le label a été ajouté.
+1️⃣ Ouvrir une *issue* sur `Github` (cf. explications ci-dessus sur le principe des _issues_). Signaler qu'il serait bien d'ajouter un emoji chat dans le `README`. Dans la partie de droite, cliquer sur la petite roue à côté de `Label` et cliquer sur `Edit Labels`. Créer un label `Markdown`. Normalement, le label a été ajouté.
 
 2️⃣ Retournez sur votre dépôt local. Vous allez créer une branche nommée
 `issue-1`