relecture (jusque branches)

branches.md

@@ -139,6 +139,17 @@ supprimés sur le serveur seront de nouveau envoyés au prochain push).
 
 ![](branches_18.png)
 
+## Réécrire l'historique
+
+Souvent, on crée des commits au fur et à mesure du travail pour fixer et
+partager les modifications. Mais pour certaines applications, on peut vouloir
+un graphe de commits "plus propre", où les commits doivent suivre une structure
+prédéterminée, ou au contraire les réorganiser a posteriori. Git offre des
+fonctionnalités pour cela : regrouper des commits, les déplacer...  Ces
+fonctionnalités ne sont pas traitées dans ce tutoriel (voir la documentation
+sur les `git rebase`).
+
+
 ## Résumé et méthode de travail
 
 Résumé des commandes git précédentes :
@@ -156,7 +167,7 @@ Résumé des commandes git précédentes :
 
 Quelques conseils de méthode de travail :
 
-- utilisez une branche master "qui marche"
+- avoir une branche master "qui marche tout le temps"
 - pour chaque tâche du projet, créez une branche dédiée, que vous fusionnerez
   dans le master une fois la tâche réalisée.
 - utiliser des branches ne vaccine pas contre les conflits, donc pensez à faire

depot_distant.md

@@ -9,19 +9,19 @@ output:
 # Dépôt distant 
 
 Git permet de synchroniser un dépôt local avec un dépôt distant (sur un
-serveur).  Ceci permet d'envoyer les commits locaux sur le serveur et de
-récupérer les commits du serveur dans le dépôt local. 
+serveur).  Ceci permet d'envoyer les commits locaux sur le serveur et,
+réciproquement, de récupérer les commits du serveur dans un dépôt local.
 Lorsqu'un dépôt local est synchronisé avec un serveur, une étiquette
 supplémentaire (`origin/master`) est utilisée pour indiquer le dernier commit
 du serveur.
 
 Il existe des serveurs comme github qui permettent d'héberger
 gratuitement des dépôts publics (visibles par tout le monde).
-Le serveur gogs du SCOSI vous permet d'héberger des dépôts publics ou privés.
+Le serveur gogs de l'université vous permet d'héberger des dépôts publics ou privés.
 Il dispose d'une page web vous permettant de gérer vos projets. Pour cela,
 allez à l'adresse
 [https://gogs.univ-littoral.fr](https://gogs.univ-littoral.fr) et entrez vos
-identifiants du portail ULCO :
+identifiants du portail :
 
 ![](depot_distant_01.png)
 
@@ -49,8 +49,8 @@ section suivante).
 ![](depot_distant_05.png)
 
 Le site du serveur gogs vous permet de configurer différents paramètres
-concernant votre projet. Il permet notamment d'indiquer les collègues qui
-participent au projet et qui peuvent donc cloner et modifier le dépôt (cliquez
+concernant votre dépôt. Par exemple pour un dépôt privé, vous pouvez indiquer
+les personnes que vous autorisez à récupérer et à modifier le dépôt (cliquez
 "settings" puis "collaboration" puis entrez et ajoutez le login).
 
 ![](depot_distant_15.png)
@@ -58,11 +58,10 @@ participent au projet et qui peuvent donc cloner et modifier le dépôt (cliquez
 ## Cloner un dépôt distant vers un nouveau dépôt local
 
 La commande `git clone ...` permet de récupérer un dépôt distant sur votre
-machine (cf image ci-dessous). 
-
+machine. C'est la méthode la plus simple pour récupérer un dépôt. 
 Pour éviter d'avoir à retaper votre login sans arrêt, pensez à l'ajouter après
-le "https://" lors du clone. Vous pouvez également l'ajouter plus tard, dans le
-fichier `.git/config`. 
+le "https://" lors du clone (vous pouvez également l'ajouter plus tard, dans le
+fichier `.git/config`). 
 
 ![](depot_distant_06.png)
 
@@ -82,9 +81,6 @@ puis `git push -u origin master`.
 
 ![](depot_distant_07b.svg)
 
-Si vous avez le choix, faites plutôt un clone (méthode de la section
-précédente) : c'est plus simple et le résultat sera exactement le même.
-
 ## Récupérer (tirer) les commits d'un dépôt distant
 
 La commande `git pull` permet de récupérer les éventuelles modifications sur le
@@ -112,14 +108,14 @@ Les commits/fichiers envoyés sur le serveur sont alors visibles sur la page web
 
 ![](depot_distant_10.png)
 
-Vous pouvez également voir le contenu de votre dépôt avec un client
+Vous pouvez également voir le contenu de votre dépôt avec un client git
 graphique.
 
 ![](depot_distant_11.png)
 
 ## Résoudre des conflits
 
-Imaginez que vous avez modifié et commité un fichier, et que vous voulez
+Imaginons que vous avez modifié et commité un fichier, et que vous voulez
 l'envoyer sur le serveur. Pour cela, il faut d'abord faire un `git pull` avant
 le `git push` au cas où l'un de vos collaborateurs aurait envoyer une
 modification sur le serveur entre temps. 
@@ -166,14 +162,14 @@ Quelques conseils de méthode de travail :
 
 - utilisez la page
   [https://gogs.univ-littoral.fr](https://gogs.univ-littoral.fr) pour créer et
-gérer vos dépôts distants.
-- récupérez vos nouveaux dépôts distant avec `git clone`
-- récupérez les modifications du serveur avec `git pull`
-- faites un `git pull` avant d'envoyer vos nouveaux commits sur le serveur (`git push`)
+gérer vos dépôts distants
+- récupérez vos dépôts distants avec `git clone`
+- récupérez les modifications du serveur régulièrement (avec `git pull`)
+- faites un `git pull` avant d'envoyer vos nouveaux commits sur le serveur (avec `git push`)
 
 ## Exercice
 
-TODO
+- TODO
 
 * * * * *
 

depot_local.md

@@ -13,8 +13,8 @@ dossier classique que l'on demande à git de versionner (journaliser).
 
 Un dépôt git contient l'ensemble des commits (versions sauvegardées du projet).
 Ces commits peuvent être marqués par des étiquettes. Il existe deux étiquettes
-prédéfinies et gérées par git : `master` (dernier commit) et `HEAD` (commit
-courant, correspondant à l'état courant des fichiers).
+prédéfinies et gérées par git : `master` (dernier commit) et `HEAD`
+(commit/état courant des fichiers).
 
 ## Initialiser un dépôt
 
@@ -39,12 +39,8 @@ peut rien casser.  N'hésitez donc pas à la lancer pour voir où vous en êtes.
 
 Il faut indiquer explicitement les fichiers que git doit journaliser.  
 
-Par exemple, imaginons qu'on ouvre un nouveau fichier `rapport_01.tex` dans
-notre projet.
-
-![](depot_local_03.png)
-
-On y écrit du code LaTeX.
+Par exemple, imaginons qu'on ouvre un nouveau fichier LaTeX `rapport_01.tex`
+dans notre projet.  
 
 ![](depot_local_04.png)
 
@@ -97,12 +93,12 @@ Vous pouvez le vérifier avec un `git status`.
 
 ![](depot_local_11.svg)
 
-Ainsi, un `git commit` crée un commit à partir de l'état pointé par HEAD
-et fait pointer master (et HEAD) sur ce nouveau commit.
+Ainsi, un `git commit` crée un commit à partir de l'état pointé par `HEAD`
+et fait pointer `master` (et `HEAD`) sur ce nouveau commit.
 
 ## Fichiers autogénérés et .gitignore
 
-Git est très pratique pour gérer des fichiers textes que l'on modifie
+Git est très utile pour gérer des fichiers textes que l'on modifie
 régulièrement. En revanche, il n'est pas adapté pour gérer des fichiers dans un
 format non-textuel (images, données compressées, documents word...).  Si on
 ajoute un tel fichier dans le dépôt alors à chaque modification, git stockera
@@ -110,8 +106,7 @@ une nouvelle copie complète (au lieu de stocker uniquement les lignes qui ont
 changé), ce qui est inefficace.
 
 D'autre part, il est inutile de versionner les fichiers autogénérés (créés
-automatiquement lors de la compilation du code). Par exemple, si on compile le
-code LaTeX de notre projet...
+automatiquement). Par exemple, si on compile le code LaTeX de notre projet...
 
 ![](depot_local_12.png)
 
@@ -178,26 +173,26 @@ Le "unstaged" correspond aux modifications courantes non commitées.
 ## Supprimer les modifications courantes
 
 La commande `git checkout -- . ` supprime les modifications courantes. Le dépôt revient
-alors dans l'état du dernier commit (master).
+alors dans l'état du dernier commit (`master`).
 
 ![](depot_local_checkout_01.svg)
 
 ## Revenir à un commit précédent (sans suppression)
 
 La commande `git checkout 7b3...` permet de revenir au commit "7b3...". On passe 
-ainsi dans un mode "détaché" (HEAD ne pointe plus sur un commit terminal).
+ainsi dans un mode "détaché" (`HEAD` ne pointe plus sur un commit terminal).
 
 ![](depot_local_checkout_02.svg)
 
 Au lieu d'utiliser le numéro de commit, on peut également utiliser les
-étiquettes. Par exemple, `git checkout master` pour aller au dernier commit
+étiquettes : par exemple `git checkout master` pour aller au dernier commit
 principal ou `git checkout HEAD~1` pour aller au commit précédent le commit
 courant.
 
 ## Marquer un commit
 
-La commande `git tag` permet de nommer des commits pour, par exemple, fixer une
-version ou pouvoir revenir plus facilement sur un commit particulier.
+La commande `git tag` permet de nommer des commits pour, par exemple, indiquer
+une version ou pour pouvoir revenir plus facilement à un commit particulier.
 
 ![](depot_local_22.png)
 
@@ -206,8 +201,8 @@ version ou pouvoir revenir plus facilement sur un commit particulier.
 ## Supprimer des commits précédents
 
 La commande `git reset 073...` revient au commit "073..." et annule tous les
-commits suivant (jusqu'à l'ancien master). Les modifications correspondants à
-ces commits sont conservées dans l'état courant (non commité).
+commits suivant (jusqu'à l'ancien `master`). Les modifications correspondant à
+ces commits sont regroupées dans l'état courant, non commité.
 
 ![](depot_local_checkout_04.svg)
 
@@ -223,30 +218,30 @@ Résumé des commandes git précédentes :
 
 ---|---|
 `git init` | initialise le dossier courant (nouveau dépôt git) |
-`git status` | TODO |
-`git add` | |
-`git commit -a` | |
-`git mv` | |
-`git rm` | |
-`git log` | |
-`git checkout -- .` | |
-`git checkout <commit/etiquette>` | |
-`git tag` | |
-`git reset` | |
-`git reset --hard` | |
+`git status` | affiche l'état courant des fichiers |
+`git add <fichiers>` | demande à git de versionner des fichiers |
+`git commit -a` | valide toutes les modifications courantes |
+`git mv <nom1> <nom2>` | renomme des fichiers versionnés |
+`git rm <fichiers>` | supprime des fichiers versionnés |
+`git log` | affiche la liste des commits |
+`git checkout -- .` | supprime les modifications courantes (revient au commit)|
+`git checkout <commit/etiquette>` | revient à un commit sans rien supprimer |
+`git tag` | affiche la liste des étiquettes |
+`git tag <etiquette>` | crée une nouvelle étiquette |
+`git reset <commit>` | supprime des commits et regroupe les modifications correspondantes dans l'état courant|
+`git reset --hard <commit>` | supprime des commits ainsi que les modifications correspondantes|
 
 Quelques conseils de méthode de travail :
 
-- privilégier les petits dépôts, correspondant à différents travaux, plutôt
-  qu'un gros dépôt regroupant tous les travaux de l'année
-- faire des commits réguliers et correspondant aux petites tâches successives 
-- éviter de commiter un projet cassé (par exemple, du code qui ne compile pas)
-- ne pas versionner les fichiers auto-générés
+- privilégiez les petits dépôts, correspondant à différents travaux, plutôt
+  qu'un gros dépôt regroupant tous vos travaux de l'année
+- faites des commits réguliers et correspondant aux petites tâches successives 
+- évitez de commiter un projet cassé (par exemple, du code qui ne compile pas)
+- ne versionnez pas les fichiers auto-générés
 
 ## Exercice
 
-
-TODO
+- TODO
 
 * * * * *
 

forks.md

@@ -100,29 +100,35 @@ Elle apparait alors dans la liste des commits.
 Si les modifications du fork ont été faites dans une nouvelle branche, il ne
 faut pas oublier de fusionner dans la branche master sur le dépôt upstream. 
 
-## Mettre à jour un dépôt forké
+## Mettre à jour un dépôt forké, spécifier manuellement les dépots distants
 
-Après un fork, les deux dépôts (fork et upstream) peuvent évoluer indépendamment.
-Pour récupérer les modifications du dépôt initial dans le dépôt forké, on
-l'ajoute comme "remote" (sous le nom "upstream") puis on peut récupérer les
-évolutions de upstream (fetch) et les fusionner dans le dépôt forké (merge).
+Après un fork, les deux dépôts (fork et upstream) peuvent évoluer
+indépendamment.  Pour récupérer les modifications du dépôt initial dans le
+dépôt forké, il suffit de l'ajouter comme dépôt distant (généralement, on
+utilise le nom "upstream") :
 
 ```
 git remote add upstream https://gogs.univ-littoral.fr/jdehos/tutoriel_git
+```
+
+On peut ensuite récupérer les évolutions de upstream et les fusionner dans le
+dépôt forké :
+
+```
 git fetch upstream
 git merge upstream/master
 ```
 
-## Gérer manuellement un pull request
-
-Pour gérer un pull request manuellement, il suffit, dans le dépôt principal,
-d'ajouter le dépôt forké comme remote puis de synchroniser avec fetch et merge.
-L'avantage de cette méthode est que l'on peut fusionner dans une branche
-différente que celle du pull request.
+Cette gestion des dépôts distants est très puissante. Elle permet, par exemple, de
+créer un dépôt public et un dépôt privé pour un même projet et de les
+synchroniser. Elle permet également de gérer un pull request manuellement (par
+exemple pour fusionner dans une branche différente que celle du pull request) :
 
 ```
 git remote add fork_fabien https://gogs.univ-littoral.fr/fteytaud/tutoriel_git
 git fetch fork_fabien
+git branch pull_request_fabien
+git checkout pull_request_fabien
 git merge fork_fabien/master
 ```
 

index.md

@@ -11,7 +11,7 @@ output:
 ## À qui s'adresse ce tutoriel ?
 - Objectif du tutoriel : apprendre à utiliser l'outil git et le [serveur
   gogs](https://gogs.univ-littoral.fr) mis en place par le
-[SCOSI](http://scosi.univ-littoral.fr/). 
+[SCOSI](http://scosi.univ-littoral.fr/) à l'[ULCO](http://univ-littoral.fr). 
 - Pré-requis : utilisation basique d'un ordinateur (et notamment du clavier).
 - Public visé : toute personne ayant à manipuler, journaliser ou partager des
   fichiers de texte brut (txt, LaTeX, python, matlab, R, java, CSV...). 
@@ -28,22 +28,22 @@ Git est conçu pour manipuler principalement des fichiers **au format texte**
 et PDF ne sont pas des fichiers au format texte et git est beaucoup moins
 intéressant pour manipuler ce genre de fichiers.
 
-Quelques fonctionnalités/utilisation de git/gogs :
+Quelques fonctionnalités/utilisations de git/gogs :
 
-- **journalisation** : « je modifie souvent mes fichiers et je peux revenir à
-  mes modifications précédentes, les annuler ou en tester plusieurs en
-parallèle »
+- **journalisation et branches** : « je modifie souvent mes fichiers et je peux
+  revenir à mes modifications précédentes, les annuler ou en tester plusieurs
+en parallèle »
 - **sauvegarde distante** : « quand je le souhaite, l'outil envoie une copie de
   sauvegarde de mes fichiers sur un serveur ».
 - **synchronisation** : « je travaille sur plusieurs postes différents et je
   peux synchroniser mes fichiers facilement entre les postes ».
 - **travail en équipe** : « mes collègues et moi travaillons sur des fichiers
   communs; les modifications de chacun sont retransmises aux autres; les
-éventuels conflits sont détectés (quand un fichier est modifié par deux
-personnes en même temps) ».
+éventuels conflits sont détectés ».
 - **projets publics ou privés** : « je peux créer des projets publics, visibles
-  par tout le monde sur internet (ou uniquement de l'université), et des
-projets privés, visibles et modifiables par les collègues que j'indique ».
+  par tout le monde (ou uniquement par les personnes identifiées à
+l'université), et des projets privés, visibles et modifiables par les personnes
+que j'indique ».
 
 ## Dans quels cas ne pas utiliser git/gogs ?
 - édition collaborative en temps-réel -> sharelatex
@@ -52,7 +52,7 @@ projets privés, visibles et modifiables par les collègues que j'indique ».
 
 ## Concepts de base
 
-## Notion de "version" (commit)
+### Notion de "version" (commit)
 
 Un "projet git" contient l'historique de toutes les modifications de chaque
 fichier.  On appelle "commit" un état sauvegardé de ces modifications (une
@@ -72,7 +72,7 @@ On peut ensuite rassembler ces modifications en fusionnant les branches :
 
 ![](concepts_commits_3.svg)
 
-## Notion de dépôt (repository)
+### Notion de dépôt (repository)
 
 On appelle dépôt tout l'historique des fichiers et des modifications de notre
 "projet git", c'est-à-dire l'ensemble des commits.