slides pas finis

Makefile

@@ -1,19 +1,32 @@
-MD_FILES = $(shell find -name "*.md")
+MD_FILES = index.md installation.md depot_local.md depot_distant.md branches.md forks.md  
 HTML_FILES = $(MD_FILES:.md=.html)
 
-all: $(HTML_FILES)
+.PHONY: all clean publish
+
+all: tmp $(HTML_FILES) slides.html
+	@echo ok
+
+tmp :
 	mkdir -p tmp
-	cp $(HTML_FILES) ./templates/template.css images/*.png images/*.svg ./tmp/
+	cp ./templates/template.css images/*.png images/*.svg ./tmp/
 
 before.html: before.md
 	pandoc --css template.css -o $@ $<
 
 %.html: %.md before.html 
 	pandoc --template templates/template.html --css template.css --toc --toc-depth 2 --include-before before.html -o $@ $<
+	cp $@ tmp
+
+slides.md : $(MD_FILES)
+	cat before_slides.md $^ > $@
+
+slides.html: slides.md  
+	pandoc  --slide-level 2 --css slidy.css --template templates/template_slidy.html --toc --toc-depth 2 -t slidy -s -o $@ $<
+	cp $@ ./templates/slidy.css ./templates/slidy.js tmp
 
 publish:
 	scp ./tmp/* yangra.univ-littoral.fr:public-html/enseignements/tutoriel_git/
 
 clean:
-	rm -rf $(HTML_FILES) ./tmp
+	rm -rf $(HTML_FILES) slides.md slides.html ./tmp
 

before.md

@@ -5,4 +5,5 @@
 - [Dépôt distant](depot_distant.html) 
 - [Branches](branches.html) 
 - [Forks](forks.html) 
+- [Slides](slides.html) 
 

branches.md

@@ -4,6 +4,10 @@ title: "Branches"
 date: 2016-03-25
 ---
 
+# Branches
+
+##
+
 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
@@ -23,11 +27,15 @@ La commande `git branch` permet d'afficher les branches.
 
 ![](branches_01.png)
 
+*  *  *  *
+
 On peut avoir plus d'information avec la commande `git log --graph --oneline --decorate`.
 
 ![](branches_21.png)
 
-Sur le graphe des commits, on indique la branche courant avec un `*`.
+*  *  *  *
+
+Sur le graphe des commits, on indique la branche courante avec un `*`.
 
 ![](branches_02.svg)
 
@@ -47,6 +55,8 @@ La commande `git checkout ...` permet de sélectionner une branche.
 
 ![](branches_04.svg)
 
+*  *  *  *
+
 Les nouveaux commits sont alors effectués pour la branche sélectionnée.
 Par exemple, si on modifie le fichier `paper.tex` et qu'on commite ensuite :
 
@@ -54,6 +64,8 @@ Par exemple, si on modifie le fichier `paper.tex` et qu'on commite ensuite :
 
 ![](branches_05.svg)
 
+*  *  *  *
+
 Le `master` est une branche comme les autres qu'on peut également sélectionner.
 
 ![](branches_06.png)
@@ -70,11 +82,15 @@ la branche qu'il faut intégrer dans la branche courante.
 
 ![](branches_07.svg)
 
+*  *  *  *
+
 Un nouveau commit, correspondant à la fusion, est alors créé. On peut le 
 vérifier avec un `git log`...
 
 ![](branches_09.png)
 
+*  *  *  *
+
 ... ou avec un client graphique.
 
 ![](branches_10.png)
@@ -87,12 +103,16 @@ l'envoyer également sur le serveur, il faut utiliser la commande `git push
 associées et il suffira ensuite d'un push classique de la branche locale pour
 l'envoyer sur le serveur.
 
+*  *  *  *
+
 Par exemple, pour créer et envoyer la branche `intro_papier` sur le dépôt distant `origin` :
 
 ![](branches_11.png)
 
 ![](branches_08.svg)
 
+*  *  *  *
+
 On peut également voir sur le site Gogs que la branche a bien été créée sur le 
 serveur.
 
@@ -114,6 +134,8 @@ branche...
 
 ![](branches_09.svg)
 
+*  *  *  *
+
 ... puis utiliser la commande `git branch -d ...`.
 
 ![](branches_13b.png)
@@ -154,9 +176,7 @@ 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 :
+## Résumé 
 
 ---|---|
 `git branch` | affiche la liste des branches |
@@ -169,7 +189,7 @@ Résumé des commandes Git précédentes :
 `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 :
+## Conseils 
 
 - 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

depot_distant.md

@@ -4,6 +4,10 @@ title: "Dépôt distant"
 date: 2016-03-31
 ---
 
+# 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,
 réciproquement, de récupérer les commits du serveur dans un dépôt local.
@@ -11,6 +15,8 @@ Lorsqu'un dépôt local est synchronisé avec un serveur, Git crée et utilise u
 étiquette prédéfinie supplémentaire (`origin/master`) 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 de l'université
 vous permet d'héberger des dépôts publics mais également des dépôts privés.  Il
@@ -20,6 +26,8 @@ entrez vos identifiants :
 
 ![](depot_distant_01.png)
 
+*  *  *  *
+
 Une fois identifié(e), le site vous affiche une page d'accueil (derniers
 commits, dépôts actifs...) :
 
@@ -32,16 +40,22 @@ cliquez « Nouveau dépôt ».
 
 ![](depot_distant_03.png)
 
+*  *  *  *
+
 Entrez le nom du dépôt distant à créer, puis cliquez « Créer un dépôt ».
 
 ![](depot_distant_04.png)
 
+*  *  *  *
+
 Le dépôt distant est alors créé et une page vous indique comment le récupérer
 localement. Attention, il y a une méthode plus simple que celle indiquée (cf.
 [section suivante](#cloner-un-dépôt-distant-vers-un-nouveau-dépôt-local)).
 
 ![](depot_distant_05.png)
 
+*  *  *  *
+
 Le site du serveur Gogs vous permet de configurer différents paramètres
 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
@@ -67,6 +81,8 @@ Si vous avez déjà créé et modifié un dépôt local...
 
 ![](depot_distant_07a.svg)
 
+*  *  *  *
+
 ... alors vous pouvez le synchroniser avec un dépôt distant.  Pour cela, il
 faut lancer les commandes :
 
@@ -75,13 +91,13 @@ dépôt local, un dépôt distant qu'on appellera `origin`) ;
 2. `git push -u origin master`  (pour envoyer, dans le dépôt distant `origin`, la
 branche `master` du dépôt local).
 
-Ces deux commandes synchronisent le dépôt
-distant et le dépôt local ; il n'est plus nécessaire de les relancer ensuite.
-
 ![](depot_distant_07b.png)
 
 ![](depot_distant_07b.svg)
 
+Ces deux commandes synchronisent le dépôt
+distant et le dépôt local ; il n'est plus nécessaire de les relancer ensuite.
+
 ## 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
@@ -100,16 +116,22 @@ Après des commits locaux...
 
 ![](depot_distant_09a.svg)
 
+*  *  *  *
+
 ... la commande `git push` permet d'envoyer vos commits locaux sur le serveur.
 
 ![](depot_distant_09b.png)
 
 ![](depot_distant_09b.svg)
 
+*  *  *  *
+
 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 Git
 graphique.
 
@@ -127,6 +149,8 @@ le `master` du serveur pointe sur un commit différent du `master` local.
 
 ![](depot_distant_12a.svg)
 
+*  *  *  *
+
 Il faut donc fusionner ces modifications, c'est-à-dire créer un nouveau commit
 rassemblant les modifications de `master` et de `origin/master` puis
 envoyer ce nouveau commit sur le serveur.  Git est souvent capable de faire ces
@@ -136,38 +160,44 @@ cas d'une fusion avec conflit :
 
 ![](depot_distant_12.png)
 
+*  *  *  *
+
 On est donc dans un état non commité et contenant un conflit à résoudre.
 
 ![](depot_distant_12b.svg)
 
+*  *  *  *
+
 Pour résoudre le conflit, il suffit d'ouvrir le fichier en cause et de
 remplacer les zones marquées par le contenu que vous voulez obtenir. 
 Il existe des outils graphiques comme `meld` qui peuvent vous y aider.
 
 ![](depot_distant_13.png)
 
+*  *  *  *
+
 Une fois le fichier corrigé, vous pouvez commiter...
 
 ![](depot_distant_14a.png)
 
 ![](depot_distant_14a.svg)
 
+*  *  *  *
+
 ... et pusher vers le serveur.
 
 ![](depot_distant_14b.png)
 
 ![](depot_distant_14b.svg)
 
-## Résumé et méthode de travail
-
-Résumé des commandes Git précédentes :
+## Résumé 
 
 ---|---|
 `git clone` | récupère un dépôt distant |
 `git pull` | récupère les modifications du dépôt distant et les intègre dans le dépôt local |
 `git push` | envoie les commits du dépôt local sur le dépôt distant |
 
-Quelques conseils de méthode de travail :
+## Conseils
 
 - Utilisez la page
   [https://gogs.univ-littoral.fr](https://gogs.univ-littoral.fr) pour créer et

depot_local.md

@@ -4,6 +4,10 @@ title: "Dépôt local"
 date: 2016-03-31
 ---
 
+# Dépôt local
+
+## 
+
 L'élément de base d'un projet Git est le dépôt. Il s'agit simplement d'un
 dossier classique que l'on demande à Git de versionner (journaliser).
 
@@ -41,13 +45,17 @@ dans notre projet.
 
 ![](depot_local_04.png)
 
-Et on affiche l'état du dépôt.
+*  *  *  *
+
+On affiche l'état du dépôt.
 
 ![](depot_local_05.png)
 
 Git nous indique que le fichier `papier.tex` existe bien dans le dossier
 (ainsi qu'un fichier de sauvegarde), mais qu'il ne fait pas partie du dépôt. 
 
+*  *  *  *
+
 Pour ajouter un fichier au dépôt, il faut utiliser la commande `git add`. 
 
 ![](depot_local_06.png)
@@ -57,6 +65,8 @@ commits (journalisation), ce qu'on peut vérifier avec un `git status`.
 
 ![](depot_local_07.png)
 
+*  *  *  *
+
 Si on représente le graphe des commits correspondant à notre projet,
 on a pour l'instant qu'un état courant non validé.
 
@@ -73,6 +83,8 @@ La commande à lancer pour valider toutes les modifications est `git commit -a`.
 
 ![](depot_local_08.png)
 
+*  *  *  *
+
 Git lance alors l'éditeur de texte pour le message de commit.
 Le message est pré-rempli avec des informations concernant le commit. Ces
 informations vous permettent de vérifier que le commit correspond bien à ce que
@@ -86,6 +98,8 @@ train de valider puis enregistrez et quittez.
 
 ![](depot_local_09.png)
 
+*  *  *  *
+
 Git crée alors le nouveau commit, qui valide ici le fichier `papier.tex`.
 
 ![](depot_local_10.png)
@@ -94,6 +108,8 @@ Vous pouvez le vérifier avec un `git status`.
 
 ![](depot_local_11.png)
 
+*  *  *  *
+
 Si on représente le graphe des commits, on a désormais un état validé (un
 commit), qui correspond actuellement au `master` (dernier commit) et au `HEAD`
 (état courant des fichiers).
@@ -103,14 +119,19 @@ commit), qui correspond actuellement au `master` (dernier commit) et au `HEAD`
 ## Fichiers autogénérés et .gitignore
 
 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
+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
 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). 
+
+*  *  *  *
 
-D'autre part, il est inutile de versionner les fichiers autogénérés (créés
-automatiquement). Par exemple, si on compile le code LaTeX de notre projet...
+Par exemple, si on compile le code LaTeX de notre projet...
 
 ![](depot_local_12.png)
 
@@ -118,7 +139,9 @@ automatiquement). Par exemple, si on compile le code LaTeX de notre projet...
 
 ![](depot_local_13.png)
 
-Pour les ignorer lors des `git status`, il suffit de les indiquer dans un
+*  *  *  *
+
+Pour ignorer des fichiers lors des `git status`, il suffit de les indiquer dans un
 fichier `.gitignore`, dans le répertoire principal du projet. Dans le
 `.gitignore`, on peut indiquer des noms de fichier complets (par exemple,
 `papier.pdf`) ou utiliser des motifs de noms (par exemple, `*.log`).
@@ -129,11 +152,15 @@ On vérifie qu'ils n'apparaissent plus lors des `git status`.
 
 ![](depot_local_15.png)
 
+*  *  *  *
+
 Sur le graphe des commits, on a maintenant un nouvel état courant `HEAD` non
 commité, le `master` correspondant toujours au dernier commit.
 
 ![](depot_local_15.svg)
 
+*  *  *  *
+
 Il est courant d'ajouter le `.gitignore` au dépôt, ainsi qu'un
 fichier `README.md` qui servira de page d'accueil au format
 [markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).
@@ -159,6 +186,8 @@ d'une commande (par exemple ici, `git help mv`).
 
 ![](depot_local_17.svg)
 
+*  *  *  *
+
 De même, la commande `git rm` permet de supprimer un fichier versionné.
 
 ![](depot_local_18.png)
@@ -176,11 +205,15 @@ Ce qui correspond au graphe suivant.
 
 ![](depot_local_log.svg)
 
+*  *  *  *
+
 La commande `git log` (ou `git log --abbrev-commit`) permet d'afficher
 l'historique des commits.
 
 ![](depot_local_20b.png)
 
+*  *  *  *
+
 On peut également le voir avec un client graphique comme `gitg`.
 
 ![](depot_local_21.png)
@@ -214,6 +247,8 @@ La commande `git tag` permet d'étiqueter des commits.
 
 ![](depot_local_checkout_03a.svg)
 
+*  *  *  *
+
 Ces étiquettes permettent d'indiquer des versions du projet et de revenir plus
 facilement à un commit particulier.
 
@@ -229,6 +264,8 @@ correspondantes**, qui sont alors regroupées dans l'état courant, non commité
 
 ![](depot_local_checkout_04.svg)
 
+*  *  *  *
+
 La commande `git reset --hard 13a...` est équivalente à la commande précédente
 sauf qu'elle **supprime les modifications correspondantes**.
 Les fichiers sont donc remis dans l'état du commit « 13a... », et `master` et
@@ -236,9 +273,7 @@ Les fichiers sont donc remis dans l'état du commit « 13a... », et `master
 
 ![](depot_local_checkout_05.svg)
 
-## Résumé et méthode de travail
-
-Résumé des commandes Git précédentes :
+## Résumé 
 
 ---|---|
 `git init` | initialise le dossier courant (nouveau dépôt Git) |
@@ -257,7 +292,7 @@ Résumé des commandes Git précédentes :
 `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 :
+## Conseils 
 
 - 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.

forks.md

@@ -4,6 +4,10 @@ title: "Forks"
 date: 2016-03-25
 ---
 
+# Forks
+
+##
+
 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
@@ -27,22 +31,32 @@ connecte sur le site Gogs de l'université.
 
 ![](forks_01.png)
 
+*  *  *  *
+
 Il explore la zone publique et sélectionne le dépôt de Julien.
 
 ![](forks_02.png)
 
+*  *  *  *
+
 Il demande de forker le projet.
 
 ![](forks_03.png)
 
+*  *  *  *
+
 Ce qui lui crée un nouveau dépôt...
 
 ![](forks_04.png)
 
+*  *  *  *
+
 ... qui est une copie du dépôt initial.
 
 ![](forks_05.png)
 
+*  *  *  *
+
 Fabien peut ensuite cloner son nouveau dépôt...
 
 ![](forks_06a.png)
@@ -66,10 +80,14 @@ 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 d'ailleurs).
 
 ![](forks_08.png)
 
+*  *  *  *
+
 Le pull request est alors enregistré.
 
 ![](forks_09.png)
@@ -80,15 +98,21 @@ De son côté, Julien reçoit le pull request de Fabien, pour le dépôt initial
 
 ![](forks_j10.png)
 
+*  *  *  *
+
 Il peut alors regarder les modifications proposées, échanger des messages avec
 Fabien puis finalement accepter (ou refuser) les modifications.
 
 ![](forks_j11.png)
 
+*  *  *  *
+
 Si le pull request est accepté, la modification est fusionnée dans le dépôt.
 
 ![](forks_j12.png)
 
+*  *  *  *
+
 Elle apparait alors dans la liste des commits. 
 
 ![](forks_j13.png)
@@ -122,6 +146,8 @@ Cette gestion des dépôts distants est très puissante. Elle permet, par exempl
 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. 
 
+*  *  *  *
+
 Autre exemple, Julien peut gérer manuellement un pull request de Fabien dans 
 une branche spéciale. Pour cela, il lui suffit d'ajouter et de récupérer le
 dépôt distant de Fabien (par exemple sous le nom `fork_fabien`) et de créer une
@@ -141,15 +167,13 @@ git merge fork_fabien/master
 ```
 
 
-## Résumé et méthode de travail
-
-Résumé des commandes git précédentes :
+## Résumé 
 
 ---|---|
 `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 :
+## Conseils
 
 - 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

index.md

@@ -3,6 +3,8 @@ title: "Introduction"
 date: 2016-03-31
 ---
 
+# Introduction
+
 ## À 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
@@ -44,9 +46,7 @@ que j'indique ».
 - partage de fichiers « au plus simple » → dropbox, seafile, serveur FTP/HTTP...
 - fichiers dans un format non textuel (word, excel, PDF...) 
 
-## Concepts de base
-
-### Notion de « version » (commit)
+## Notion de « version » (commit)
 
 Un « projet Git » contient l'historique de toutes les modifications sauvegardées
 de chaque fichier.  On appelle « commit » un état sauvegardé de ces modifications
@@ -66,7 +66,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.

installation.md

@@ -3,14 +3,20 @@ title: "Installation et configuration"
 date: 2016-03-25
 ---
 
+# Installation et configuration
+
+## 
+
 Pour utiliser Git, il vous faut un client Git (et une connexion internet si
 vous voulez utiliser des dépôts distants).
 
 ## Ligne de commandes vs interface graphique
 
-Il existe deux types de client Git : le client console (en ligne de commandes)
-et les [clients
-graphiques](https://git-scm.com/book/fr/v2/Git-dans-d%E2%80%99autres-environnements-Interfaces-graphiques)
+Il existe deux types de client Git : 
+
+- le client console (en ligne de commandes) 
+
+- les [clients graphiques](https://git-scm.com/book/fr/v2/Git-dans-d%E2%80%99autres-environnements-Interfaces-graphiques)
 (par exemple : gitg, giggle, qgit, gitk, git-gui, github-desktop...).
 
 [La communauté conseille souvent d'utiliser le client

templates/template.css

@@ -3070,4 +3070,7 @@ h1 { font-size: 200%; }
 h2 { font-size: 175%; }
 h3 { font-size: 150%; }
 h4 { font-size: 125%; }
-
+hr {
+  margin: 0;
+  border: 0;
+}

templates/template.html

@@ -72,9 +72,6 @@ $endfor$
                 </div>
 
                 <div class="span$if(toc)$9$else$12$endif$">
-$if(title)$
-<h1>$title$</h1>
-$endif$
 
 $body$
                 </div>