Merge branch 'master' of https://gogs.univ-littoral.fr/jdehos/tutoriel_git

branches.md

@@ -8,15 +8,15 @@ output:
 
 # Branches 
 
-Lorsque l'on crée successivement des commits, ceux-ci sont ajoutés les uns à la
+Lorsque l'on fait des commits successifs, ceux-ci sont ajoutés les uns à la
 suite des autres, sur une même branche.  Git permet également, à partir d'un
 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)
@@ -27,7 +27,7 @@ La commande `git branch` permet d'afficher les branches.
 
 ![](branches_01.png)
 
-On peut avoir plus d'information avec la commande `git log --graph --all --oneline --decorate`.
+On peut avoir plus d'information avec la commande `git log --graph --oneline --decorate`.
 
 ![](branches_21.png)
 
@@ -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)
 
@@ -105,7 +105,8 @@ La commande `git ls-remote` permet de lister les branches distantes.
 ## Terminer une branche locale
 
 Pour terminer une branche locale (c'est-à-dire supprimer l'étiquette
-correspondante), il faut d'abord sélectionner une autre branche...
+correspondante dans le dépôt local), il faut d'abord sélectionner une autre
+branche...
 
 ![](branches_13a.png)
 
@@ -120,7 +121,8 @@ correspondante), il faut d'abord sélectionner une autre branche...
 ## Terminer une branche distante
 
 Pour terminer une branche distante (c'est-à-dire supprimer l'étiquette
-correspondante), il faut utiliser la commande `git push --delete ...`
+correspondante sur le serveur), il faut utiliser la commande `git push --delete
+...`
 
 ![](branches_16.png)
 
@@ -130,7 +132,7 @@ correspondante), il faut utiliser la commande `git push --delete ...`
 
 Généralement, vouloir supprimer un commit déjà envoyé sur le serveur est une
 mauvaise idée.  En effet, en plus de perdre les données sauvegardées, cela peut
-casser les commits d'un collègue qui aurait déjà récupéré et continué les
+casser les commits d'un collaborateur qui aurait déjà récupéré et continué les
 commits en question, donc il vaut mieux committer des corrections.
 
 Mais si c'est vraiment ce que vous voulez faire, voici la procédure (pensez
@@ -141,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`).
 
@@ -155,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,31 @@ 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 1
+
+- associez-vous à un ou deux collègues : l'un d'entre vous va créer un dépôt
+  public, les autres vont le forker et soumettre des pull-requests
 
-## Exercice
+## Exercice 2
 
-TODO
+- créez deux dépôts distants, l'un publique, l'autre privé
+- clonez le dépôt privé, faites-y quelques commits et pushez le tout
+- toujours dans le dépôt privé local, créez une branche "public", fusionnez-y
+  le master et pushez-la sur le dépôt distant privé et sur le dépôt distant
+public
+- faites un nouveau commit dans le master, fusionnez-le dans la branche
+  "public" et pushez le tout
+- clonez le dépôt public et mettez-le à jour avec la branche "public" du dépôt
+  distant privé
 
 * * * * *