relecture julien presque finie...

branches.md

@@ -14,9 +14,9 @@ commit donné, de réaliser plusieurs branches en parallèle.  Les branches
 peuvent ensuite être fusionnées, abandonnées ou même supprimées.
 
 L'utilisation des branches est très naturelle avec git et permet d'organiser le
-déroulement du projet. Souvent, on utilise une branche principale "master" qui
+déroulement du projet. Souvent, on utilise une branche principale `master` qui
 "doit toujours fonctionner" et, pour chaque fonctionnalité à ajouter, on dérive
-une nouvelle branche que l'on fusionne ensuite dans le master une fois la
+une nouvelle branche que l'on fusionne ensuite dans le `master` une fois la
 fonctionnalité réalisée (ou partiellement réalisée) et testée.
 
 ![](branches_01.svg)
@@ -55,7 +55,7 @@ Les nouveaux commits sont alors effectués pour la branche sélectionnée.
 
 ![](branches_05.svg)
 
-Le master est une branche comme les autres qu'on peut également sélectionnée.
+Le `master` est une branche comme les autres qu'on peut également sélectionnée.
 
 ![](branches_06.png)
 
@@ -143,11 +143,11 @@ supprimés sur le serveur seront de nouveau envoyés au prochain push).
 
 ## 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
+Souvent, on crée des commits au fur et à mesure, pour sauvegarder 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 pour cela : regrouper des commits, les déplacer, etc...  Ces
 fonctionnalités ne sont pas traitées dans ce tutoriel (voir la documentation
 sur les `git rebase`).
 
@@ -157,27 +157,38 @@ sur les `git rebase`).
 Résumé des commandes git précédentes :
 
 ---|---|
-`git branch` | TODO |
-`git log --graph --all --oneline --decorate` | |
-`git ls-remote` | |
-`git branch ...` | |
-`git checkout ...` | |
-`git merge ...` | |
-`git push --set-upstream ...` | |
-`git branch -d ...` | |
-`git push --delete ...` | |
+`git branch` | afficher la liste des branches |
+`git log --graph --oneline --decorate` | afficher le graph des commits |
+`git ls-remote` | afficher la liste des branches distantes |
+`git branch <nom>` | créer une nouvelle branche locale |
+`git checkout <branche>` | sélectionne une branche |
+`git merge <branche>` | fusionne une branche dans la branche courante |
+`git push --set-upstream <remote> <branche>` | envoie la branche courante dans une branche distante |
+`git branch -d <branche>` | supprime une branche locale (enlève l'étiquette) |
+`git push --delete <remote> <branche>` | supprime une branche distante |
 
 Quelques conseils de méthode de travail :
 
-- avoir une branche master "qui marche tout le temps"
+- essayez d'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.
+  dans le `master` une fois les modifications commitées
 - utiliser des branches ne vaccine pas contre les conflits, donc pensez à faire
-  quand même le point avec vos collègues régulièrement.
+  quand même le point avec vos collègues régulièrement
 
 ## Exercice
 
-TODO
+- clonez un dépôt distant dans deux dépôts locaux
+- créez une nouvelle branche "b1", faites quelques commits dans b1 puis
+  fusionnez-les dans le master
+- envoyez la branche b1 sur le serveur et vérifiez que vous la récupérez bien
+  dans le second dépôt local
+- créez une branche "b2" à partir du commit précédant le master courant, faites
+  quelques commits dans b2 puis fusionnez-les dans le master
+- fusionnez le master dans b1 et vérifiez le graphe des commits avec le client
+  git console et avec un client graphique 
+- envoyez la branche b2 sur le serveur puis supprimez-la sur le dépôt local et
+  sur le dépôt distant
+
 
 * * * * *
 

depot_distant.md

@@ -169,7 +169,15 @@ gérer vos dépôts distants
 
 ## Exercice
 
-- TODO
+- créez un dépôt sur le serveur gogs et récupérez-le dans un dépôt local
+- ajoutez/committez/pushez quelques fichiers et vérifiez sur le site gogs que
+  les modifications sont bien sur le serveur
+- clonez votre dépôt distant dans un second dépôt local; committez/pushez
+  depuis ce second dépôt puis synchronisez le premier dépôt local et vérifiez
+que vous y récupérez bien les modifications réalisées dans le second
+- modifiez une même ligne d'un même fichier en parallèle sur les deux dépôts
+  locaux; vérifiez que vous avez bien un conflit, résolvez-le et synchronisez
+tout le monde
 
 * * * * *
 

depot_local.md

@@ -241,7 +241,13 @@ Quelques conseils de méthode de travail :
 
 ## Exercice
 
-- TODO
+- créez un nouveau dépôt local, ajoutez des fichiers et faites quelques
+  commits; affichez l'état du dépôt à chaque étape
+- renommez et supprimez quelques fichiers
+- affichez l'historique des commits et revenez dans un état précédent du dépot
+- ajoutez une étiquette à un ancien commit et vérifiez que vous la voyez dans
+  l'historique des commits ou avec un client git graphique
+- testez les suppressions de commits
 
 * * * * *
 

forks.md

@@ -11,23 +11,24 @@ output:
 Imaginons que Julien propose un dépôt public, visible par tout le monde, mais
 non modifiable (pour éviter que n'importe qui y fasse n'importe quoi).  Si
 Fabien (à qui il arrive parfois de faire n'importe quoi) veut proposer une
-modification, il peut alors copier le dépôt de Julien (fork), faire ses
+modification, il peut alors copier (forker) le dépôt de Julien, faire ses
 modifications dans son dépôt, puis les soumettre à Julien (pull request), qui
 choisira ou non de les intégrer dans le dépôt initial (upstream).
 
 Le fork est un mode de fonctionnement très répandu dans le monde de
-l'open-source (github entre autres).
-Le serveur gogs du SCOSI possède également une partie publique mais visible
-après connexion (donc réservée aux étudiants et personnels de l'université).
+l'open-source (github entre autres).  Le serveur gogs de l'université possède
+également une partie publique propice aux forks (cette partie publique est
+cependant réservée aux personnes ayant des identifiants à l'université).
 
-Attention : pour les intervenants réguliers et de confiance, il est plus simple
+Remarque : pour les intervenants réguliers et de confiance, il est plus simple
 de les autoriser à modifier directement le dépôt principal, en les ajoutant
-comme collaborateurs (les deux systèmes sont complémentaires). 
+comme collaborateurs. Les deux systèmes (forks et collaboration) sont
+complémentaires. 
 
 ## Forker un dépôt distant
 
 Le dépôt de Julien est déjà sur le serveur, dans la partie publique. Fabien se
-connecte sur le site gogs du SCOSI.  
+connecte sur le site gogs de l'université.  
 
 ![](forks_01.png)
 
@@ -61,8 +62,8 @@ Fabien peut ensuite cloner son nouveau dépôt...
 
 ## Envoyer un pull request
 
-Un pull request est une demande d'intégrer une modification d'un dépôt forké
-dans le dépôt initial (upstream).
+Un pull request permet de demander d'intégrer d'une modification d'un dépôt
+forké dans le dépôt initial (upstream).
 
 Jusqu'ici, Fabien a forké le dépôt de Julien et fait des modifications sur son
 dépôt forké. Pour soumettre ses modifications, il va sur la page correspondant
@@ -70,7 +71,7 @@ dépôt forké. Pour soumettre ses modifications, il va sur la page correspondan
 
 ![](forks_07.png)
 
-Il met un message pour Julien, expliquant ses modifications (ou pas).
+Il met un message pour Julien, expliquant ses modifications (ou pas d'ailleurs).
 
 ![](forks_08.png)
 
@@ -89,7 +90,7 @@ Fabien puis finalement accepter (ou refuser) les modifications.
 
 ![](forks_j11.png)
 
-Si le pull request est accepté, la modification est fusionné dans le dépôt.
+Si le pull request est accepté, la modification est fusionnée dans le dépôt.
 
 ![](forks_j12.png)
 
@@ -98,30 +99,35 @@ Elle apparait alors dans la liste des commits.
 ![](forks_j13.png)
 
 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. 
+faut pas oublier de la fusionner dans le master, sur le dépôt upstream.
+
+En cas de conflit, le pull request doit être intégré manuellement (voir section
+suivante).
 
 ## 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é, il suffit de l'ajouter comme dépôt distant (généralement, on
-utilise le nom "upstream") :
+indépendamment.  Pour récupérer les nouvelles 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é :
+On peut ensuite récupérer les évolutions du dépôt upstream et les fusionner
+dans le dépôt forké :
 
 ```
 git fetch upstream
 git merge upstream/master
 ```
 
-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
+Cette gestion des dépôts distants est très puissante. Elle permet, par exemple,
+de créer, pour un même projet, un dépôt distant public et un dépôt distant privé
+(éventuellement sur des serveurs différents) et de les synchroniser. 
+
+Ainsi, pour gérer un pull request manuellement (par
 exemple pour fusionner dans une branche différente que celle du pull request) :
 
 ```
@@ -138,17 +144,18 @@ git merge fork_fabien/master
 Résumé des commandes git précédentes :
 
 ---|---|
-`git remote add ...` | TODO |
-`git fetch ...` | |
-`git merge ...` | |
+`git remote add <nom> <url>` | ajoute un dépôt distant |
+`git fetch <nom>` | récupère les commits d'un dépôt distant |
 
 Quelques conseils de méthode de travail :
 
-- TODO
+- ajoutez les membres du projet comme collaborateurs du dépôt distant
+- pour les dépôts publics, utilisez les pull requests pour récupérer les
+  éventuelles contributions de la communauté
 
 ## Exercice
 
-TODO
+- TODO
 
 * * * * *