diff --git a/gitbranch.tex b/gitbranch.tex
new file mode 100644
index 0000000000000000000000000000000000000000..9526a288ede608965bb04a733f94fc69475f1f33
--- /dev/null
+++ b/gitbranch.tex
@@ -0,0 +1,476 @@
+\documentclass{IutSlideBeamerNew}
+
+\title{Git}
+\subtitle{Principes et utilisation pour les projets tuteurés\\
+(et les autres projets...)}
+\date{5 septembre 2013}
+
+\AtBeginSubsection[]
+{
+% \beamertemplateshadingbackground{monbleu}{white}
+ \frame<beamer>
+ {
+ \frametitle{Sommaire}
+ \tableofcontents[currentsection,currentsubsection]
+ }
+% \beamertemplatesolidbackgroundcolor{white}
+}
+
+\usepackage{gitcommon}
+
+\begin{document}
+
+\frame{\titlepage}
+
+%======================================================================
+
+%\frame{\frametitle{Sommaire}\tableofcontents[part=1]}
+\frame{\frametitle{Sommaire}\tableofcontents}
+
+%======================================================================
+
+%\part{En route}
+
+%======================================================================
+
+\section{Les branches}
+
+%======================================================================
+
+\subsection{Présentation}
+
+%======================================================================
+
+\frame{\frametitle{Introduction}
+ \begin{itemize}
+ \item
+ La manipulation des branches est certainement une des
+ fonctionnalités les plus puissantes sous git
+ \item
+ Elle est particulièrement simple et rapide par rapport aux autres
+ VCS, où les branches sont généralement difficiles à gérer
+ \item
+ Sous git, la création d'une branche est un processus léger, ce qui
+ encourage son utilisation
+ \item
+ Une \emph{branche} représente une partie de l'arborescence
+ créée par les différents commits contenus dans un dépôt
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Représentation arborescente}
+ \begin{itemize}
+ \item
+ Chaque commit créé possède au moins un père : le commit dont il
+ est issu
+ \item
+ Il existe ainsi une filiation entre les différents commits d'un
+ dépôt, représentée sous forme d'arbre
+ \end{itemize}
+ \begin{center}
+ \includegraphics[scale=.4]{arbre.eps}
+ \end{center}
+}
+
+%======================================================================
+
+\frame{\frametitle{Branche \ext{master}}
+ \begin{itemize}
+ \item
+ Rappel : la création d'un dépôt git entraîne automatiquement la
+ création d'une branche par défaut, appelée \ex{master}
+ \item
+ Techniquement, cette branche correspond à une variable \ex{master}
+ pointant toujours vers le dernier commit réalisé
+ \end{itemize}
+ \begin{center}
+ \includegraphics[scale=.4]{arbremaster.eps}
+ \end{center}
+}
+
+%======================================================================
+
+\frame{\frametitle{Intérêt de nouvelles branches}
+ \begin{itemize}
+ \item
+ Il est possible de créer de nouvelles branches pour faire évoluer,
+ \textit{simultanément}, le développement dans des directions
+ différentes
+ \begin{itemize}
+ \item
+ développement collaboratif (= plusieurs développeurs)
+ \item
+ correction de bugs
+ \item
+ ajout de fonctionnalités
+ \item
+ etc.
+ \end{itemize}
+ \item
+ Un moyen simple de savoir sur quelle branche on se trouve\\
+ \mygit{git branch}{gitbranch1.txt}
+ \item
+ Le symbole \ex{*} désigne la branche courante (utile lorsque
+ plusieurs branches existent)
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Création d'une nouvelle branche}
+ \begin{itemize}
+ \item
+ Pour créer une nouvelle branche, ajouter un nom de branche à la
+ commande précédente\\
+ \mygitplus{git branch nouveau}\\
+ \mygit{git branch}{gitbranch2.txt}
+ \item
+ Cette commande ne fait que créer une nouvelle branche, elle ne
+ permet pas de basculer vers cette nouvelle branche
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Création d'une nouvelle branche}
+ \begin{itemize}
+ \item
+ La création d'une nouvelle branche entraîne la création d'une
+ nouvelle variable représentant cette branche
+ \end{itemize}
+ \begin{center}
+ \includegraphics[scale=.4]{arbremasternouv.eps}
+ \end{center}
+}
+
+%======================================================================
+
+
+\frame{\frametitle{Le pointeur \ext{HEAD}}
+ \begin{itemize}
+ \item
+ Pour savoir dans quelle branche le dépôt se situe, git utilise un
+ pointeur spécial appelé \ex{HEAD}
+ \item
+ Cette variable pointe toujours vers (le dernier commit de) la
+ branche courante
+ \end{itemize}
+ \begin{center}
+ \includegraphics[scale=.4]{arbrehead.eps}
+ \end{center}
+}
+
+%======================================================================
+
+\frame{\frametitle{Passage d'une branche à une autre}
+ \begin{itemize}
+ \item
+ La commande permettant de changer de branche est \ex{git checkout
+ \emph{branche}}, soit dans l'exemple courant\\
+ \mygitplus{git checkout nouveau}\\
+ \mygit{git branch}{gitbranch3.txt}
+ \end{itemize}
+ \begin{center}
+ \includegraphics[scale=.4]{arbrehead2.eps}
+ \end{center}
+}
+
+%======================================================================
+
+\frame{\frametitle{Passage d'une branche à une autre}
+ \begin{itemize}
+ \item
+ Lors du passage d'une branche à une autre, git restaure le
+ répertoire de travail dans l'état correspondant à la branche
+ sélectionnée (uniquement pour les fichiers suivis par git)
+ \item
+ Attention : on ne peut pas changer de branche s'il reste
+ des modifications en attente dans le répertoire de travail
+ \item
+ Pour créer une branche tout en s'y déplaçant\\
+ \mygit{git branch}{gitbranch1.txt}
+ \mygitplus{git checkout -b nouveau}\\
+ \mygit{git branch}{gitbranch3.txt}
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Introduction}
+ \begin{itemize}
+ \item
+
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Fusion de branches}
+ \begin{itemize}
+ \item
+ Les commandes \ex{merge} et \ex{rebase}
+ \end{itemize}
+}
+
+%======================================================================
+
+\subsection{Exemples d'utilisation}
+
+%======================================================================
+
+\frame{\frametitle{Introduction}
+ \begin{itemize}
+ \item
+ Afin de bien comprendre les particularités des différentes
+ stratégies liées aux branches
+ \begin{enumerate}
+ \item
+ on part d'une situation initiale correspondant à un dépôt
+ contenant uniquement une branche master avec 3 commits
+ \item
+ on simule un travail, correspondant à l'ajout d'une nouvelle
+ fonctionnalité tout en corrigeant un bug
+ \item
+ on applique une des 5 stratégies présentées
+ \item
+ on présente le résultat obtenu
+ \end{enumerate}
+ \item
+ Toutes les stratégies sont techniquement correctes
+ \item
+ Les résultats obtenus varient naturellement en fonction de la
+ stratégie appliquée
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Introduction}
+ \framesubtitle{Détail de la simulation}
+ \begin{itemize}
+ \item
+ On crée une nouvelle branche \ex{nouvfonc} correspondant à l'ajout
+ d'une nouvelle fonctionnalité dans laquelle on ajoute 2 commits
+ \item
+ On revient parallèlement dans la branche \ex{master} pour y faire
+ une correction de bug
+ \item
+ On souhaite ensuite fusionner \ex{nouvfonc} dans \ex{master} et
+ supprimer ensuite la branche \ex{nouvfonc}
+ \end{itemize}
+
+ \textbf{\huge Important}
+ \begin{itemize}
+ \item
+ Insérer ici une image de la situation de départ
+ \item
+ Reprendre les images de chaque stratégie et encercler en rouge les
+ 2 commits de la nouvelle fonctionnalité
+ \end{itemize}
+}
+
+%======================================================================
+
+
+\frame{\frametitle{Introduction}
+ \framesubtitle{Détail des stratégies étudiées}
+ \begin{enumerate}
+ \item
+ \ex{checkout master, rebase nouvfonc, delete branch nouvfonc}
+ \item
+ \ex{checkout master, merge nouvfonc, delete branch nouvfonc}
+ \item
+ \ex{checkout nouvfonc, rebase master, checkout master, merge
+ nouvfonc, delete branch nouvfonc}
+ \item
+ \ex{checkout nouvfonc, rebase master, checkout master, merge
+ -{}-no-ff nouvfonc, delete branch nouvfonc}
+ \item
+ \ex{checkout master, merge nouvfonc -{}-no-ff, delete branch
+ nouvfonc}
+ \end{enumerate}
+}
+
+%======================================================================
+
+\newcommand{\branchstrategie}[4]{
+\frame{\frametitle{#1}
+ \begin{tabular}{lp{3cm}}
+ \begin{minipage}[b]{.5\linewidth}
+ {\small
+ #2
+ }
+ \end{minipage}
+ &
+ \centerline{\includegraphics[scale=.5]{#3}}
+ \end{tabular}
+ #4
+}}
+
+%======================================================================
+
+\branchstrategie{Stratégie 1}
+{
+ \ex{git checkout master}\\
+ \ex{git rebase nouvfonc}\\
+ \ex{git branch -d nouvfonc}
+}
+{strat1.png}
+{
+ \begin{itemize}
+ \item
+ Tout est linéaire, le commit de la branche dont on est parti étant
+ en dernier
+ \item
+ On ne voit pas bien les commits correspondant à la
+ nouvelle fonctionnalité
+ \end{itemize}
+}
+
+%======================================================================
+
+\branchstrategie{Stratégie 2}
+{
+ \ex{git checkout master}\\
+ \ex{git merge nouvfonc}\\
+ \ex{git branch -d nouvfonc}
+}
+{strat2.png}
+{
+ \begin{itemize}
+ \item
+ Le commit du changement de titre paraît à part, ce qui n'est pas
+ encore trop gênant
+ \item
+ On a l'impression que les premiers commits sont sur la même lancée
+ que la branche de nouvelle fonctionnalité, ce qui induit en erreur
+ : ce n'est pas clair
+ \end{itemize}
+}
+
+%======================================================================
+
+\branchstrategie{Stratégie 3}
+{
+ \ex{git checkout nouvfonc}\\
+ \ex{git rebase master}\\
+ \ex{git checkout master}\\
+ \ex{git merge nouvfonc}\\
+ \ex{git branch -d nouvfonc}
+}
+{strat3.png}
+{
+ \begin{itemize}
+ \item
+ Tout est linéaire, le commit de la branche dont on est parti étant
+ en dernier
+ \item
+ On ne voit pas bien les commits correspondant à la nouvelle
+ fonctionnalité (idem stratégie 1 donc)
+ \end{itemize}
+}
+
+%======================================================================
+
+\branchstrategie{Stratégie 4}
+{
+ \ex{git checkout nouvfonc}\\
+ \ex{git rebase master}\\
+ \ex{git checkout master}\\
+ \ex{git merge -{}-no-ff nouvfonc}\\
+ \ex{git branch -d nouvfonc}
+}
+{strat4.png}
+{
+ \begin{itemize}
+ \item
+ Les deux commits correspondant à la nouvelle fonctionnalité
+ apparaissent clairement.
+ \item
+ C'est le schéma le plus lisible.
+ \end{itemize}
+}
+
+%======================================================================
+
+\branchstrategie{Stratégie 5}
+{
+ \ex{git checkout master}\\
+ \ex{git merge nouvfonc -{}-no-ff}\\
+ \ex{git branch -d nouvfonc}
+}
+{strat5.png}
+{
+ \begin{itemize}
+ \item
+ Idem à la stratégie 2, ce n'est pas le ff qui s'est fait dans ce
+ cas.
+ \end{itemize}
+}
+
+%======================================================================
+
+% \frame{\frametitle{Stratégie 1}
+% \begin{tabular}{lp{3cm}}
+% \begin{minipage}[b]{.5\linewidth}
+% {\small
+% \ex{git checkout master}\\
+% \ex{git rebase nouvfonc}\\
+% \ex{git branch -d nouvfonc}
+% }
+% \end{minipage}
+% &
+% \centerline{\includegraphics[scale=.5]{strat1.png}}
+% \end{tabular}
+
+% \begin{itemize}
+% \item
+% Tout est linéaire, le commit de la branche dont on est parti étant
+% en dernier
+% \item
+% On ne voit pas bien les commits correspondant à la
+% nouvelle fonctionnalité
+% \end{itemize}
+% }
+
+%======================================================================
+
+\subsection{Travail collaboratif}
+
+%======================================================================
+
+\frame{\frametitle{Introduction}
+ \begin{itemize}
+ \item
+ Le travail de plusieurs personnes sur un même projet fait
+ automatiquement appel à de la gestion de branches
+ \item
+ Chaque personne travaille en effet sur une branche de son propre
+ dépôt
+ \item
+ La réconciliation du travail de ces différentes personnes se fait
+ en fusionnant les branches correspondantes
+ \item
+ Plusieurs stratégies peuvent alors être mises en place pour
+ effectuer cette fusion
+ \end{itemize}
+}
+
+%======================================================================
+
+\subsection{Recommandations}
+
+%======================================================================
+
+\frame{\frametitle{}
+ \begin{itemize}
+ \item
+
+ \end{itemize}
+}
+
+%======================================================================
+
+\end{document}
diff --git a/gitcommon.sty b/gitcommon.sty
new file mode 100644
index 0000000000000000000000000000000000000000..7f42c7532e6860fb8f72af82138035729d89ed38
--- /dev/null
+++ b/gitcommon.sty
@@ -0,0 +1,244 @@
+\NeedsTeXFormat{LaTeX2e}[1995/12/01]
+\ProvidesPackage{gitcommon}[1/04/2014]
+
+% Depuis git 1.8.5 : @ devient un alias de HEAD
+
+
+% Introduire des passage de git GUI dans les démonstrations, à la façon
+% de http://vimeo.com/16395537
+%
+% Après avoir regardé cette vidéo, je deviens également persuadé qu'il
+% est en fait intéressant d'introduire la notion de branche, dans
+% l'esprit de ce qui est fait dans la vidéo, à savoir en présentant un
+% cas d'usage (bugfix + fonctionnalité). Il faut alors trancher sur ce
+% qu'il faut préconiser -> merge tout seul ou rebase + merge --no-ff
+% Du coup, les explications sur le travail collaboratif deviennent
+% également plus simple, le plus gros sur les branches (voire les
+% conflits également) ayant déjà été introduit auparavent.
+
+
+% -------------------------------------------------------------------
+
+% Par ailleurs :
+% -------------
+
+% Dérouler plusieurs scénarios (cas d'usage) en montrant les différences
+% obtenues à la fin de chaque stratégie. Le contexte : un dépôt
+% contenant uniquement la branche master avec 3 commits (par exemple) à
+% l'intérieur. La manip :
+
+% - On crée une nouvelle branche correspondant à l'ajout d'une nouvelle
+% fonctionnalités (nouvfonc) dans laquelle on ajoute 2 commits
+% - On revient dans la branche master pour y faire un bugfix
+% - On souhaite maintenant fusionner nouvfonc dans master et supprimer
+% ensuite la branche
+
+% Montrer la situation courante sous forme d'arbre. On peut appliquer
+% plusieurs stratégies :
+
+% 1) M: rebase N, delete branch N
+% 2) M: merge N, delete branch N
+% 3) N: rebase M, M: merge N, delete branch N
+% 4) N: rebase M, M: merge --no-ff N, delete branch N
+
+% -> Montrer le résultat final à chaque fois sous forme d'arbre.
+% -> À compléter avec le paragraphe suivant qui contient un lien
+% proposant une discussion à ce sujet
+% -------------------------------------------------------------------
+
+% Important : une bonne ressource avec enfin une bonne discussion sur
+% les avantages et les inconvénients à utiliser soit merge soit
+% rebase. De quoi faire...
+% http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/
+
+% -------------------------------------------------------------------
+
+% Encore une ressource dont il faudrait extraire la partie la plus
+% intéressante :
+% http://fr.slideshare.net/rschwietzke/git-the-incomplete-overview
+
+% On explique en particulier ici, comme à d'autres endroits, qu'il vaut
+% mieux faire un git pull --rebase plutôt qu'un pull normal. À vérifier
+% et à tester pour le coup.
+
+% On y explique aussi qu'il vaut mieux éviter le ff au niveau du merge :
+% il est ainsi préconisé d'utiliser plutôt un git merge --no-ff. Et ça,
+% ça reste à creuser pour bien comprendre les différences.
+
+
+% Allez, encore une ressources avec tout un tas de choses sympas :
+% http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/fr/book.html
+% (git magique)
+
+% Encore une ressource avec des notions plus élaborées portant sur les
+% problématiques de développement collaboratif :
+% http://git.or.cz/course/
+
+% Important !! Pour une démo avec un dépôt bare créé en local
+% - mkdir test.git
+% - cd test.git
+% - git init --bare --shared=all
+% - cd ..
+% - chmod -R g+w test.git
+
+% À revoir :
+% - outils graphiques windows ?
+% - interfaçage Eclipse / Netbeans ?
+% - des exemples de commandes « sympas »
+% -> présenter git stash (à la fin, en add-ons, pas prévu
+% particulièrement pour primo présentation
+% http://www.eyrolles.com/Chapitres/9782212134384/page-1_Hertzog.pdf
+%
+% -> Oui, très sympa le stash. À creuser !!
+% http://sametmax.com/soyez-relax-faites-vous-un-petit-git-stash/
+
+% http://zackperdue.com/tutorials/super-useful-need-to-know-git-commands
+% http://ndpsoftware.com/git-cheatsheet.html (interactive git)
+% http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/fr/book.pdf
+% et en particulier des commandes comme $ git diff "@{yesterday}"
+% ou git whatchanged --since="2 weeks ago"
+% http://mislav.uniqpath.com/2010/07/git-tips/
+
+% Des commandes utiles : http://pioupioum.fr/tag/git/
+
+% Le site de référence pour la documentation egit/eclipse :
+% http://wiki.eclipse.org/EGit/User_Guide#Github_Tutorial
+
+% Ajout de commandes supplémentaires :
+
+% - checkout, en particulier pour aller rechercher la version d'un
+% fichier dans un état donné :
+
+% - git checkout <file> : restaure l'état du fichier depuis l'index
+% (i.e. supprime toutes les modifications effectuées sur ce fichier
+% depuis le dernier commit le concernant)
+
+% - git checkout <commit> <file> : restaure l'état du fichier depuis
+% le commit désigné. (éventuellement HEAD à la place du commit)
+
+% - ces deux exemples n'effectuent pas de changement de branche ou de
+% HEAD d'une façon générale (car il y a un fichier en paramètre,
+% dans le cas contraire HEAD est modifié).
+
+% - remote : à la demande de Gérôme. Va également probablement s'avérer
+% nécessaire pour initier le lien entre eclipse et un dépôt
+% redmine. L'un dans l'autre...
+
+% Une commande intéressante : git push -u origin master
+% Elle permet de positionner le tracking et ainsi d'utiliser les
+% commandes push et pull par la suite sans argument
+
+% D'ailleurs, github propose :
+% touch README.md
+% git init
+% git add README.md
+% git commit -m "first commit"
+% git remote add origin https://github.com/loirotte/yoplaboum.git
+% git push -u origin master
+
+% Pour le LORIA, on préférera :
+% git remote add origin selgringo:/var/git/ra2012.git
+
+% À faire : un QCM sur git, avec questions / réponses, qui pourrait
+% également faire office de pense-bête pour les commandes utiles, avec
+% des détails permettant de comprendre finement les choses...
+
+% L'idée du QCM est assez bonne, il faut la développer et certainement
+% fourni immédiatement une version avec les réponses qui vont bien
+% dessus. Ça me semble vraiment intéressant et presque essentiel pour la
+% bonne compréhension du sujet. Et maintenant, qu'est-ce qu'on fait
+% exactement ? Ce qui serait amusant, c'est que ce que je suis en
+% train de taper soit analysé... Pour le coup, oui, ce n'est pas un
+% programme qui est en cours d'élaboration, mais bien plutôt un texte
+% libre permettant d'illustrer le reportage. Et puis, c'est l'occasion
+% de voir emacs à l'oeuvre.
+
+% À ajouter aussi : des screenshots correspondants à l'utilisation du
+% plugin egit à partir d'eclipse avec les problématique d'intégration à
+% partir du redmine de l'IUT
+
+% Ajouter, encore une fois, un certain nombre de commandes pratiques et
+% utiles à partir de git, comme certaines qui sont typiquement à
+% l'intérieur des outils relatifs à Arche : je pense en particulier à
+% des commandes git clean et à git checkout sur des versions
+% particulières de repository.
+
+% À déposer sur le dépôt redmine de l'IUT : que faut-il versionner
+% d'ailleurs à ce propos ? Le PDF résultat ou les sources ? Ça peut être
+% problématique, car il faut dans ce cas isoler tous les packages
+% nécessaires relatifs à la compilation LaTeX. On peut faire ça pour
+% les collègues, mais qui va finalement télécharger tout ça pour le
+% recompiler ? On peut se le demander...
+
+% Sur les cas d'usage, on peut citer git flow, commandes de haut niveau
+% pour un développement professionnel :
+% https://github.com/nvie/gitflow
+
+% Gestion de plusieurs repository (git ou autres ) : mr (multiple
+% repository)
+% http://joeyh.name/code/mr/
+
+\newcommand{\exccc}[3]{\emboiter[4pt, inner sep=1.5pt]{#1}{{\fontsize{7}{7}\textcolor{#2}{\ttfamily{}~#3~}}}}
+\newcommand{\excct}[3]{\emboiter[4pt, inner sep=1pt]{#1}{{\textcolor{#2}{\,#3\,}}}}
+
+\definecolor{clcreation}{HTML}{FF9966}
+\definecolor{clajout}{HTML}{33A3A3}
+\definecolor{cloperation}{HTML}{9966CC}
+\definecolor{clinterrogation}{HTML}{B3B300}
+\definecolor{clsynchro}{HTML}{FF3333}
+\definecolor{clgray}{HTML}{bbbbbb}
+
+\definecolor{climportant}{HTML}{E1BF74}
+
+%\newcommand{\impt}[1]{\excct{climportant}{black}{#1}}
+\newcommand{\impt}[1]{\colorbox{yellow!50}{#1}}
+%\usepackage{soul}
+%\newcommand{\impt}[1]{\hl{#1}}
+
+\newcommand{\gitall}[0]{
+ \exccc{clcreation}{white}{Création}
+ \exccc{clajout}{white}{Ajout}
+ \exccc{clinterrogation}{white}{Interrogation}
+ \exccc{cloperation}{white}{Opérations}
+ \exccc{clsynchro}{white}{Synchronisation}
+}
+\newcommand{\gitcrea}[0]{
+ \exccc{clcreation}{white}{Création}
+ \exccc{clgray}{white}{Ajout}
+ \exccc{clgray}{white}{Interrogation}
+ \exccc{clgray}{white}{Opérations}
+ \exccc{clgray}{white}{Synchronisation}
+}
+
+\newcommand{\gitajout}[0]{
+ \exccc{clgray}{white}{Création}
+ \exccc{clajout}{white}{Ajout}
+ \exccc{clgray}{white}{Interrogation}
+ \exccc{clgray}{white}{Opérations}
+ \exccc{clgray}{white}{Synchronisation}
+}
+
+\newcommand{\gitop}[0]{
+ \exccc{clgray}{white}{Création}
+ \exccc{clgray}{white}{Ajout}
+ \exccc{clgray}{white}{Interrogation}
+ \exccc{cloperation}{white}{Opérations}
+ \exccc{clgray}{white}{Synchronisation}
+}
+
+\newcommand{\gitinter}[0]{
+ \exccc{clgray}{white}{Création}
+ \exccc{clgray}{white}{Ajout}
+ \exccc{clinterrogation}{white}{Interrogation}
+ \exccc{clgray}{white}{Opérations}
+ \exccc{clgray}{white}{Synchronisation}
+}
+
+\newcommand{\gitsync}[0]{
+ \exccc{clgray}{white}{Création}
+ \exccc{clgray}{white}{Ajout}
+ \exccc{clgray}{white}{Interrogation}
+ \exccc{clgray}{white}{Opérations}
+ \exccc{clsynchro}{white}{Synchronisation}
+}
+
diff --git a/gitconnect.tex b/gitconnect.tex
new file mode 100644
index 0000000000000000000000000000000000000000..a7b48ef994b1e0d67c99ce7569dbee5bb701506a
--- /dev/null
+++ b/gitconnect.tex
@@ -0,0 +1,472 @@
+\documentclass{IutSlideBeamerNew}
+
+\title{Git}
+\subtitle{Principes et utilisation pour les projets tuteurés\\
+(et les autres projets...)}
+\date{5 septembre 2013}
+
+\AtBeginSubsection[]
+{
+% \beamertemplateshadingbackground{monbleu}{white}
+ \frame<beamer>
+ {
+ \frametitle{Sommaire}
+ \tableofcontents[currentsection,currentsubsection]
+ }
+% \beamertemplatesolidbackgroundcolor{white}
+}
+
+\usepackage{gitcommon}
+
+\begin{document}
+
+\frame{\titlepage}
+
+%======================================================================
+
+%\frame{\frametitle{Sommaire}\tableofcontents[part=1]}
+\frame{\frametitle{Sommaire}\tableofcontents}
+
+%======================================================================
+
+%\part{En route}
+
+%======================================================================
+
+\section{Gestion des projets à l'IUT}
+
+%======================================================================
+
+\subsection{Authentification SSH}
+
+%======================================================================
+
+\frame{\frametitle{Problématique}
+ \begin{itemize}
+ \item
+ De nombreux serveurs Git utilisent une authentification par clés
+ publiques SSH
+ \item
+ Si le répertoire \ex{\textasciitilde/.ssh} existe et qu'il
+ contient des fichiers \ex{id\_rsa} et \ex{id\_rsa.pub}, une clé
+ existe déjà~!
+ \item
+ Sinon, il faut en générer une pour pouvoir communiquer avec les
+ serveurs...
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Génération de clé SSH RSA}
+ \begin{itemize}
+ \item
+ Pour générer une clé, utiliser \ex{ssh-keygen}
+ \begin{itemize}
+ \item
+ sous Linux : en standard dans le package \ex{openssh-client}
+ \item
+ sous Windows : installer MSysGit
+ \item
+ sous Mac : en standard dans MacOS
+ \end{itemize}
+ \item
+ Lors de la génération, une \emph{passphrase} est demandée
+ \begin{itemize}
+ \item
+ c'est une sorte de mot de passe (ne pas reprendre le mot de
+ passe de connexion)
+ \item
+ cette \emph{passphrase} sera demandée lors des connexions SSH
+ \end{itemize}
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Utilisation d'une clé SSH}
+ \begin{itemize}
+ \item
+ Pour pouvoir communiquer \emph{via} SSH avec un serveur, il est
+ nécessaire d'y déposer sa clé publique (le contenu du fichier
+ \ex{id\_rsa.pub})
+ \item
+ Les serveurs proposent généralement d'effectuer ce dépôt
+ \emph{via} une interface Web
+ \item
+ À chaque connexion SSH, la \emph{passphrase} sera demandée
+ \item
+ Pour éviter de taper la \emph{passphrase} à chaque fois, utiliser
+ \ex{ssh-agent}
+ \begin{itemize}
+ \item
+ sous Linux et Mac : en tapant \ex{ssh-add}
+ \item
+ sous Windows : voir
+ \url{https://help.github.com/articles/working-with-ssh-key-passphrases}
+ \end{itemize}
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Clé SSH et multi-comptes}
+ \begin{itemize}
+ \item
+ Lorsqu'on est susceptible de se connecter depuis plusieurs
+ ordinateurs (ou OS) à un serveur Git, plusieurs solutions
+ \begin{itemize}
+ \item
+ générer une clé SSH sur chacun de ses comptes et importer chaque
+ clé publique sur le serveur
+ \item
+ générer une clé SSH sur le premier compte, la copier sur les
+ autres comptes et importer la partie publique sur le serveur
+ \end{itemize}
+ \item
+ Il peut être sain de travailler avec plusieurs clés SSH et ainsi
+ ne pas mettre tous ses \oe{}ufs dans le même panier...
+ \end{itemize}
+}
+
+%======================================================================
+
+% \section{Gérer un dépôt Git sur github}
+
+% %======================================================================
+
+% \frame{\frametitle{Inscription et configuration}
+% \begin{itemize}
+% \item
+% \emph{Github} : \url{https://github.com/}
+% \item
+% Inscription : choisir un compte gratuit
+% \item
+% Ajouter sa clé RSA publique en passant par l'icône \emph{Account
+% settings}
+% \item
+% Au besoin, la créer
+% \begin{itemize}
+% \item
+% sous Linux : les indications sont fournies par Github
+% \item
+% sous Windows : utiliser puttygen
+% \end{itemize}
+% \end{itemize}
+% }
+
+% %======================================================================
+
+% \frame{\frametitle{Configuration}
+% \begin{itemize}
+% \item
+% À l'initiative d'une seule personne, le créateur du projet
+% \item
+% Création d'un dépôt public avec un simple nom
+% \item
+% Suivre les indications fournies par le site !
+% \item
+% Effectuer la configuration globale sur votre machine (si non déjà
+% effectuée)
+% \item
+% Réaliser les étapes d'initialisation du dépôt décrites
+% \item
+% Le dépôt est créé (vérifier sous Github)
+% \item
+% Ajouter les collaborateurs (\emph{Admin\,/\, collaborators})
+% \end{itemize}
+% }
+
+% %======================================================================
+
+% \frame{\frametitle{Rallier un projet existant}
+% \begin{itemize}
+% \item
+% Recommandé, y compris pour le créateur du projet
+% \item
+% Aller sur la page consacrée au projet
+% \item
+% Choisir le protocole SSH parmi ceux proposés
+% \item
+% Copier l'URL associée
+% \item
+% Taper\\
+% \mygit{git clone git@github.com:dosch/test.git}{gitclone.txt}
+% \end{itemize}
+% }
+
+% %======================================================================
+
+\subsection{Gérer un projet sur Redmine (IUT)}
+
+%======================================================================
+
+\frame{\frametitle{Informations générales}
+ \begin{itemize}
+ \item
+ Adresse du serveur, accessible également depuis l'extérieur\\
+ \url{https://redmine.iutnc.univ-lorraine.fr}
+ \item
+ Tous les projets doivent être gérés et rendus sur ce serveur
+ \item
+ Les tuteurs s'y rendront donc pour les récupérer...
+ \item
+ Il est nécessaire de s'y connecter \textbf{rapidement} une
+ première fois pour y rentrer ses informations personnelles
+ \item
+ Cette étape est \textbf{nécessaire} pour que les projets tuteurés
+ puissent être complètement créés et renseignés sur Redmine
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Informations générales}
+ \framesubtitle{Gestion des projets Redmine}
+ \begin{itemize}
+ \item
+ Depuis la rentrée 2013, les étudiants possèdent automatiquement et
+ par défaut un projet s'appelant «~Projet de \emph{prénom nom}~»
+ \item
+ Il est conseillé de laisser ce projet \textbf{inutilisé} et de se
+ créer des sous-projets pour chaque nouveau projet à gérer
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Informations générales}
+ \framesubtitle{Création des projets Redmine}
+ \begin{itemize}
+ \item
+ Cliquer sur «~Nouveau sous-projet~» (en haut à droite)
+ \item
+ Saisir les informations demandées, et en particulier
+ \begin{itemize}
+ \item
+ le \emph{nom} du projet : titre libre (concis autant que possible)
+ \item
+ l'\emph{identifiant} : doit être \textbf{unique} sur Redmine,
+ en considérant \textbf{tous} les projets de \textbf{tous} les
+ étudiants\\
+ $\to$ utiliser son login en préfixe, à des fins de lisibilité et
+ d'organisation (ex : \ex{dosch-\emph{nom\_projet}})
+ \end{itemize}
+ \item
+ Ajouter ensuite les autres membres du projet (s'il y en a) en
+ cliquant sur \emph{Configuration / Membres} en leur attribuant
+ le rôle «~développeur~»
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Informations générales}
+ \framesubtitle{Création des projets Redmine}
+ \begin{itemize}
+ \item
+ Utiliser cette procédure pour se créer un projet correspondant au
+ projet tuteuré à l'initiative \textbf{d'un seul} des membres du
+ groupe
+ \begin{itemize}
+ \item
+ création du projet Redmine sur son compte Redmine
+ \item
+ ajout des autres membres du groupe
+ \item
+ communication des informations relatives au projet aux autres
+ membres du projet tuteuré
+ \end{itemize}
+ \item
+ Il est naturellement possible de se créer d'autres projets Redmine
+ pour gérer d'autres projets que le projet tuteuré
+ \item
+ Il est même possible de se créer des projets à usage purement
+ personnels : permet la sauvegarde et le \emph{versionning}
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Première connexion au serveur}
+ \begin{itemize}
+ \item
+ S'assurer d'avoir une clé SSH
+ \item
+ Se connecter une première fois sur le serveur Redmine
+ \item
+ Saisir ses informations personnelles
+ \item
+ Y importer sa ou ses clés publiques
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Gestion des projets}
+ \begin{itemize}
+ \item
+ Chaque projet tuteuré doit être géré par un projet Redmine
+ comprenant
+ \begin{itemize}
+ \item
+ un journal des événements du projet
+ \item
+ un outil de gestion de tickets (gestion des bugs,
+ fonctionnalités à implanter, répartition des rôles...)
+ \item
+ un porte-documents (pour y déposer de la documentation externe)
+ \item
+ un wiki (pour y gérer la documentation interne)
+ \item
+ ...et un dépôt git !
+ \end{itemize}
+ \item
+ Les projets Redmine sont à créer à l'initiative d'un des membres
+ du projet tuteuré (voir précédemment)
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Accès à un dépôt Git sous Redmine}
+ \begin{itemize}
+ \item
+ Les dépôts Git sont accessibles \emph{via} SSH à\\
+ \ex{git@webetu.iutnc.univ-lorraine.fr:\emph{idprojet}}\\
+ où \ex{\emph{idprojet}} est l'identifiant du projet sous Redmine
+ \item
+ Aucun \emph{login} n'est donc nécessaire, l'authentification se
+ fait grâce à la clé SSH...
+ \item
+ Un premier utilisateur devra configurer le dépôt
+ \item
+ L'initialisation faite, les autres utilisateurs pourront cloner le
+ projet
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Communication avec un dépôt Git sous Redmine}
+ \begin{itemize}
+ \item
+ Le premier utilisateur doit
+ \begin{enumerate}
+ \item
+ créer un dépôt local Git et y faire au moins un \emph{commit}\\
+ \ex{cd projet}\\
+ \ex{git init}\\
+ \ex{git add .}\\
+ \ex{git commit -m "Premier commit"}
+ \item
+ le propager vers le dépôt Git sous Redmine\\
+ {\fontsize{2.5mm}{1em}\selectfont \ex{git remote add origin
+ git@webetu.iutnc.univ-lorraine.fr:\emph{idprojet}}}\\
+ \ex{git push -u origin master}
+ \end{enumerate}
+ \item
+ Les autres membres ont juste besoin de cloner le dépôt\\
+ \ex{\fontsize{3mm}{1em}\selectfont git clone
+ git@webetu.iutnc.univ-lorraine.fr:\emph{idprojet}}\\
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Utilisation de Git dans le cadre du projet}
+ \begin{itemize}
+ \item
+ Git est utilisable
+ \begin{itemize}
+ \item
+ en ligne de commande
+ \item
+ intégré aux menus systèmes (sous Windows)
+ \item
+ sous Emacs ($\geq$ 24.3) avec l'excellent package \ex{magit}
+ \item
+ \emph{via} les IDE traditionnels (Eclipse, Netbeans, Xcode...)
+ \end{itemize}
+ \item
+ Sous Eclipse
+ \begin{itemize}
+ \item
+ Git est accessible \emph{via} le plugin Egit
+ \item
+ les commandes les plus courantes sont alors disponibles dans des
+ menus tels que
+ \begin{itemize}
+ \item
+ Team
+ \item
+ Compare with
+ \item
+ Replace with
+ \end{itemize}
+ \end{itemize}
+ \end{itemize}
+}
+
+%======================================================================
+
+% \frame{\frametitle{Redmine IUT}
+% \begin{itemize}
+% \item
+% Création d'un nouveau sous-projet
+% \begin{enumerate}
+% \item
+% Depuis l'interface Web, création d'un nouveau sous-projet
+% \item
+% Depuis éclipse, création d'une nouvelle application ou
+% positionnement sur une application existante à raccorder au
+% projet Redmine
+% \item
+% Click droit sur le projet, choisir l'entrée \emph{Team} et
+% \emph{Share project...}
+% \item
+% Choisir un projet de type git
+% \item
+% Choisir la case à cocher «~Use ou create repository in parent
+% folder of project~»
+% \item
+% Cliquer sur le bouton «~Create repository~», permetant de créer
+% le dépôt à la racine du projet, en dépit de l'avertissement
+% recommandant de ne pas le faire
+% \item
+% Ajouter un fichier \ex{.gitignore}.
+% En première approche, ce fichier peut contenir les lignes
+% suivantes :
+% %\mylistinginput{.gitignore.sample}
+% \item
+% Faire un premier commit : dans un premier temps, sélectionner
+% tous les fichiers proposés (22 \emph{a priori})
+% \item
+% Aller dans le menu contextuel, entrée \ex{Team / Remote / Push}
+% \item
+% Dans la boîte de dialogue,
+% \ex{git@webetu.iuta.univ-nancy2.fr:xxx}, où \ex{xxx} correspond
+% à l'identifiant du projet précédemment créé sous Redmine
+% \item
+% Sauf que les deux items ci-dessus ne fonctionnent pas.
+% À la place; taper en ligne de commande\\
+% \ex{git remote add hwa git@webetu.iuta.univ-nancy2.fr:hwa}\\
+% \ex{git push hwa master}
+% \item
+% Les push suivants peuvent être réalisés en passant par le menu
+% contextuel, en choisissant \ex{Team / Remote / Push} (cocher la
+% case \emph{Save specifications in specification} la première
+% fois)
+% % \item
+% % Pas encore le top : rien n'est sauvegardé pour des manipulations
+% % en ligne de commande. Il faut soit trouver le moyen de gérer
+% % tout ça depuis eclipse, le mieux surtout si on est Windows, soit
+% % initier quelque chose en ligne de commande qui sera récupéré
+% % ensuite depuis eclipse
+% \end{enumerate}
+% \end{itemize}
+% }
+
+%======================================================================
+
+\end{document}
diff --git a/gitmain.tex b/gitmain.tex
index 514fd68f6f177ea39326c4a2f188bde4e333415a..10c6a81b31ca02896c90c74770e6b16601df824b 100644
--- a/gitmain.tex
+++ b/gitmain.tex
@@ -16,247 +16,7 @@
% \beamertemplatesolidbackgroundcolor{white}
}
-% Depuis git 1.8.5 : @ devient un alias de HEAD
-
-
-% Introduire des passage de git GUI dans les démonstrations, à la façon
-% de http://vimeo.com/16395537
-%
-% Après avoir regardé cette vidéo, je deviens également persuadé qu'il
-% est en fait intéressant d'introduire la notion de branche, dans
-% l'esprit de ce qui est fait dans la vidéo, à savoir en présentant un
-% cas d'usage (bugfix + fonctionnalité). Il faut alors trancher sur ce
-% qu'il faut préconiser -> merge tout seul ou rebase + merge --no-ff
-% Du coup, les explications sur le travail collaboratif deviennent
-% également plus simple, le plus gros sur les branches (voire les
-% conflits également) ayant déjà été introduit auparavent.
-
-
-% -------------------------------------------------------------------
-
-% Par ailleurs :
-% -------------
-
-% Dérouler plusieurs scénarios (cas d'usage) en montrant les différences
-% obtenues à la fin de chaque stratégie. Le contexte : un dépôt
-% contenant uniquement la branche master avec 3 commits (par exemple) à
-% l'intérieur. La manip :
-
-% - On crée une nouvelle branche correspondant à l'ajout d'une nouvelle
-% fonctionnalités (nouvfonc) dans laquelle on ajoute 2 commits
-% - On revient dans la branche master pour y faire un bugfix
-% - On souhaite maintenant fusionner nouvfonc dans master et supprimer
-% ensuite la branche
-
-% Montrer la situation courante sous forme d'arbre. On peut appliquer
-% plusieurs stratégies :
-
-% 1) M: rebase N, delete branch N
-% 2) M: merge N, delete branch N
-% 3) N: rebase M, M: merge N, delete branch N
-% 4) N: rebase M, M: merge --no-ff N, delete branch N
-
-% -> Montrer le résultat final à chaque fois sous forme d'arbre.
-% -> À compléter avec le paragraphe suivant qui contient un lien
-% proposant une discussion à ce sujet
-% -------------------------------------------------------------------
-
-% Important : une bonne ressource avec enfin une bonne discussion sur
-% les avantages et les inconvénients à utiliser soit merge soit
-% rebase. De quoi faire...
-% http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/
-
-% -------------------------------------------------------------------
-
-% Encore une ressource dont il faudrait extraire la partie la plus
-% intéressante :
-% http://fr.slideshare.net/rschwietzke/git-the-incomplete-overview
-
-% On explique en particulier ici, comme à d'autres endroits, qu'il vaut
-% mieux faire un git pull --rebase plutôt qu'un pull normal. À vérifier
-% et à tester pour le coup.
-
-% On y explique aussi qu'il vaut mieux éviter le ff au niveau du merge :
-% il est ainsi préconisé d'utiliser plutôt un git merge --no-ff. Et ça,
-% ça reste à creuser pour bien comprendre les différences.
-
-
-% Allez, encore une ressources avec tout un tas de choses sympas :
-% http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/fr/book.html
-% (git magique)
-
-% Encore une ressource avec des notions plus élaborées portant sur les
-% problématiques de développement collaboratif :
-% http://git.or.cz/course/
-
-% Important !! Pour une démo avec un dépôt bare créé en local
-% - mkdir test.git
-% - cd test.git
-% - git init --bare --shared=all
-% - cd ..
-% - chmod -R g+w test.git
-
-% À revoir :
-% - outils graphiques windows ?
-% - interfaçage Eclipse / Netbeans ?
-% - des exemples de commandes « sympas »
-% -> présenter git stash (à la fin, en add-ons, pas prévu
-% particulièrement pour primo présentation
-% http://www.eyrolles.com/Chapitres/9782212134384/page-1_Hertzog.pdf
-%
-% -> Oui, très sympa le stash. À creuser !!
-% http://sametmax.com/soyez-relax-faites-vous-un-petit-git-stash/
-
-% http://zackperdue.com/tutorials/super-useful-need-to-know-git-commands
-% http://ndpsoftware.com/git-cheatsheet.html (interactive git)
-% http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/fr/book.pdf
-% et en particulier des commandes comme $ git diff "@{yesterday}"
-% ou git whatchanged --since="2 weeks ago"
-% http://mislav.uniqpath.com/2010/07/git-tips/
-
-% Des commandes utiles : http://pioupioum.fr/tag/git/
-
-% Le site de référence pour la documentation egit/eclipse :
-% http://wiki.eclipse.org/EGit/User_Guide#Github_Tutorial
-
-% Ajout de commandes supplémentaires :
-
-% - checkout, en particulier pour aller rechercher la version d'un
-% fichier dans un état donné :
-
-% - git checkout <file> : restaure l'état du fichier depuis l'index
-% (i.e. supprime toutes les modifications effectuées sur ce fichier
-% depuis le dernier commit le concernant)
-
-% - git checkout <commit> <file> : restaure l'état du fichier depuis
-% le commit désigné. (éventuellement HEAD à la place du commit)
-
-% - ces deux exemples n'effectuent pas de changement de branche ou de
-% HEAD d'une façon générale (car il y a un fichier en paramètre,
-% dans le cas contraire HEAD est modifié).
-
-% - remote : à la demande de Gérôme. Va également probablement s'avérer
-% nécessaire pour initier le lien entre eclipse et un dépôt
-% redmine. L'un dans l'autre...
-
-% Une commande intéressante : git push -u origin master
-% Elle permet de positionner le tracking et ainsi d'utiliser les
-% commandes push et pull par la suite sans argument
-
-% D'ailleurs, github propose :
-% touch README.md
-% git init
-% git add README.md
-% git commit -m "first commit"
-% git remote add origin https://github.com/loirotte/yoplaboum.git
-% git push -u origin master
-
-% Pour le LORIA, on préférera :
-% git remote add origin selgringo:/var/git/ra2012.git
-
-% À faire : un QCM sur git, avec questions / réponses, qui pourrait
-% également faire office de pense-bête pour les commandes utiles, avec
-% des détails permettant de comprendre finement les choses...
-
-% L'idée du QCM est assez bonne, il faut la développer et certainement
-% fourni immédiatement une version avec les réponses qui vont bien
-% dessus. Ça me semble vraiment intéressant et presque essentiel pour la
-% bonne compréhension du sujet. Et maintenant, qu'est-ce qu'on fait
-% exactement ? Ce qui serait amusant, c'est que ce que je suis en
-% train de taper soit analysé... Pour le coup, oui, ce n'est pas un
-% programme qui est en cours d'élaboration, mais bien plutôt un texte
-% libre permettant d'illustrer le reportage. Et puis, c'est l'occasion
-% de voir emacs à l'oeuvre.
-
-% À ajouter aussi : des screenshots correspondants à l'utilisation du
-% plugin egit à partir d'eclipse avec les problématique d'intégration à
-% partir du redmine de l'IUT
-
-% Ajouter, encore une fois, un certain nombre de commandes pratiques et
-% utiles à partir de git, comme certaines qui sont typiquement à
-% l'intérieur des outils relatifs à Arche : je pense en particulier à
-% des commandes git clean et à git checkout sur des versions
-% particulières de repository.
-
-% À déposer sur le dépôt redmine de l'IUT : que faut-il versionner
-% d'ailleurs à ce propos ? Le PDF résultat ou les sources ? Ça peut être
-% problématique, car il faut dans ce cas isoler tous les packages
-% nécessaires relatifs à la compilation LaTeX. On peut faire ça pour
-% les collègues, mais qui va finalement télécharger tout ça pour le
-% recompiler ? On peut se le demander...
-
-% Sur les cas d'usage, on peut citer git flow, commandes de haut niveau
-% pour un développement professionnel :
-% https://github.com/nvie/gitflow
-
-% Gestion de plusieurs repository (git ou autres ) : mr (multiple
-% repository)
-% http://joeyh.name/code/mr/
-
-\newcommand{\exccc}[3]{\emboiter[4pt, inner sep=1.5pt]{#1}{{\fontsize{7}{7}\textcolor{#2}{\ttfamily{}~#3~}}}}
-\newcommand{\excct}[3]{\emboiter[4pt, inner sep=1pt]{#1}{{\textcolor{#2}{\,#3\,}}}}
-
-\definecolor{clcreation}{HTML}{FF9966}
-\definecolor{clajout}{HTML}{33A3A3}
-\definecolor{cloperation}{HTML}{9966CC}
-\definecolor{clinterrogation}{HTML}{B3B300}
-\definecolor{clsynchro}{HTML}{FF3333}
-\definecolor{clgray}{HTML}{bbbbbb}
-
-\definecolor{climportant}{HTML}{E1BF74}
-
-%\newcommand{\impt}[1]{\excct{climportant}{black}{#1}}
-\newcommand{\impt}[1]{\colorbox{yellow!50}{#1}}
-%\usepackage{soul}
-%\newcommand{\impt}[1]{\hl{#1}}
-
-\newcommand{\gitall}[0]{
- \exccc{clcreation}{white}{Création}
- \exccc{clajout}{white}{Ajout}
- \exccc{clinterrogation}{white}{Interrogation}
- \exccc{cloperation}{white}{Opérations}
- \exccc{clsynchro}{white}{Synchronisation}
-}
-\newcommand{\gitcrea}[0]{
- \exccc{clcreation}{white}{Création}
- \exccc{clgray}{white}{Ajout}
- \exccc{clgray}{white}{Interrogation}
- \exccc{clgray}{white}{Opérations}
- \exccc{clgray}{white}{Synchronisation}
-}
-
-\newcommand{\gitajout}[0]{
- \exccc{clgray}{white}{Création}
- \exccc{clajout}{white}{Ajout}
- \exccc{clgray}{white}{Interrogation}
- \exccc{clgray}{white}{Opérations}
- \exccc{clgray}{white}{Synchronisation}
-}
-
-\newcommand{\gitop}[0]{
- \exccc{clgray}{white}{Création}
- \exccc{clgray}{white}{Ajout}
- \exccc{clgray}{white}{Interrogation}
- \exccc{cloperation}{white}{Opérations}
- \exccc{clgray}{white}{Synchronisation}
-}
-
-\newcommand{\gitinter}[0]{
- \exccc{clgray}{white}{Création}
- \exccc{clgray}{white}{Ajout}
- \exccc{clinterrogation}{white}{Interrogation}
- \exccc{clgray}{white}{Opérations}
- \exccc{clgray}{white}{Synchronisation}
-}
-
-\newcommand{\gitsync}[0]{
- \exccc{clgray}{white}{Création}
- \exccc{clgray}{white}{Ajout}
- \exccc{clgray}{white}{Interrogation}
- \exccc{clgray}{white}{Opérations}
- \exccc{clsynchro}{white}{Synchronisation}
-}
-
+\usepackage{gitcommon}
\begin{document}
@@ -1444,882 +1204,6 @@
%======================================================================
-\section{Les branches}
-
-%======================================================================
-
-\subsection{Présentation}
-
-%======================================================================
-
-\frame{\frametitle{Introduction}
- \begin{itemize}
- \item
- La manipulation des branches est certainement une des
- fonctionnalités les plus puissantes sous git
- \item
- Elle est particulièrement simple et rapide par rapport aux autres
- VCS, où les branches sont généralement difficiles à gérer
- \item
- Sous git, la création d'une branche est un processus léger, ce qui
- encourage son utilisation
- \item
- Une \emph{branche} représente une partie de l'arborescence
- créée par les différents commits contenus dans un dépôt
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Représentation arborescente}
- \begin{itemize}
- \item
- Chaque commit créé possède au moins un père : le commit dont il
- est issu
- \item
- Il existe ainsi une filiation entre les différents commits d'un
- dépôt, représentée sous forme d'arbre
- \end{itemize}
- \begin{center}
- \includegraphics[scale=.4]{arbre.eps}
- \end{center}
-}
-
-%======================================================================
-
-\frame{\frametitle{Branche \ext{master}}
- \begin{itemize}
- \item
- Rappel : la création d'un dépôt git entraîne automatiquement la
- création d'une branche par défaut, appelée \ex{master}
- \item
- Techniquement, cette branche correspond à une variable \ex{master}
- pointant toujours vers le dernier commit réalisé
- \end{itemize}
- \begin{center}
- \includegraphics[scale=.4]{arbremaster.eps}
- \end{center}
-}
-
-%======================================================================
-
-\frame{\frametitle{Intérêt de nouvelles branches}
- \begin{itemize}
- \item
- Il est possible de créer de nouvelles branches pour faire évoluer,
- \textit{simultanément}, le développement dans des directions
- différentes
- \begin{itemize}
- \item
- développement collaboratif (= plusieurs développeurs)
- \item
- correction de bugs
- \item
- ajout de fonctionnalités
- \item
- etc.
- \end{itemize}
- \item
- Un moyen simple de savoir sur quelle branche on se trouve\\
- \mygit{git branch}{gitbranch1.txt}
- \item
- Le symbole \ex{*} désigne la branche courante (utile lorsque
- plusieurs branches existent)
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Création d'une nouvelle branche}
- \begin{itemize}
- \item
- Pour créer une nouvelle branche, ajouter un nom de branche à la
- commande précédente\\
- \mygitplus{git branch nouveau}\\
- \mygit{git branch}{gitbranch2.txt}
- \item
- Cette commande ne fait que créer une nouvelle branche, elle ne
- permet pas de basculer vers cette nouvelle branche
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Création d'une nouvelle branche}
- \begin{itemize}
- \item
- La création d'une nouvelle branche entraîne la création d'une
- nouvelle variable représentant cette branche
- \end{itemize}
- \begin{center}
- \includegraphics[scale=.4]{arbremasternouv.eps}
- \end{center}
-}
-
-%======================================================================
-
-
-\frame{\frametitle{Le pointeur \ext{HEAD}}
- \begin{itemize}
- \item
- Pour savoir dans quelle branche le dépôt se situe, git utilise un
- pointeur spécial appelé \ex{HEAD}
- \item
- Cette variable pointe toujours vers (le dernier commit de) la
- branche courante
- \end{itemize}
- \begin{center}
- \includegraphics[scale=.4]{arbrehead.eps}
- \end{center}
-}
-
-%======================================================================
-
-\frame{\frametitle{Passage d'une branche à une autre}
- \begin{itemize}
- \item
- La commande permettant de changer de branche est \ex{git checkout
- \emph{branche}}, soit dans l'exemple courant\\
- \mygitplus{git checkout nouveau}\\
- \mygit{git branch}{gitbranch3.txt}
- \end{itemize}
- \begin{center}
- \includegraphics[scale=.4]{arbrehead2.eps}
- \end{center}
-}
-
-%======================================================================
-
-\frame{\frametitle{Passage d'une branche à une autre}
- \begin{itemize}
- \item
- Lors du passage d'une branche à une autre, git restaure le
- répertoire de travail dans l'état correspondant à la branche
- sélectionnée (uniquement pour les fichiers suivis par git)
- \item
- Attention : on ne peut pas changer de branche s'il reste
- des modifications en attente dans le répertoire de travail
- \item
- Pour créer une branche tout en s'y déplaçant\\
- \mygit{git branch}{gitbranch1.txt}
- \mygitplus{git checkout -b nouveau}\\
- \mygit{git branch}{gitbranch3.txt}
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Introduction}
- \begin{itemize}
- \item
-
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Fusion de branches}
- \begin{itemize}
- \item
- Les commandes \ex{merge} et \ex{rebase}
- \end{itemize}
-}
-
-%======================================================================
-
-\subsection{Exemples d'utilisation}
-
-%======================================================================
-
-\frame{\frametitle{Introduction}
- \begin{itemize}
- \item
- Afin de bien comprendre les particularités des différentes
- stratégies liées aux branches
- \begin{enumerate}
- \item
- on part d'une situation initiale correspondant à un dépôt
- contenant uniquement une branche master avec 3 commits
- \item
- on simule un travail, correspondant à l'ajout d'une nouvelle
- fonctionnalité tout en corrigeant un bug
- \item
- on applique une des 5 stratégies présentées
- \item
- on présente le résultat obtenu
- \end{enumerate}
- \item
- Toutes les stratégies sont techniquement correctes
- \item
- Les résultats obtenus varient naturellement en fonction de la
- stratégie appliquée
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Introduction}
- \framesubtitle{Détail de la simulation}
- \begin{itemize}
- \item
- On crée une nouvelle branche \ex{nouvfonc} correspondant à l'ajout
- d'une nouvelle fonctionnalité dans laquelle on ajoute 2 commits
- \item
- On revient parallèlement dans la branche \ex{master} pour y faire
- une correction de bug
- \item
- On souhaite ensuite fusionner \ex{nouvfonc} dans \ex{master} et
- supprimer ensuite la branche \ex{nouvfonc}
- \end{itemize}
-
- \textbf{\huge Important}
- \begin{itemize}
- \item
- Insérer ici une image de la situation de départ
- \item
- Reprendre les images de chaque stratégie et encercler en rouge les
- 2 commits de la nouvelle fonctionnalité
- \end{itemize}
-}
-
-%======================================================================
-
-
-\frame{\frametitle{Introduction}
- \framesubtitle{Détail des stratégies étudiées}
- \begin{enumerate}
- \item
- \ex{checkout master, rebase nouvfonc, delete branch nouvfonc}
- \item
- \ex{checkout master, merge nouvfonc, delete branch nouvfonc}
- \item
- \ex{checkout nouvfonc, rebase master, checkout master, merge
- nouvfonc, delete branch nouvfonc}
- \item
- \ex{checkout nouvfonc, rebase master, checkout master, merge
- -{}-no-ff nouvfonc, delete branch nouvfonc}
- \item
- \ex{checkout master, merge nouvfonc -{}-no-ff, delete branch
- nouvfonc}
- \end{enumerate}
-}
-
-%======================================================================
-
-\newcommand{\branchstrategie}[4]{
-\frame{\frametitle{#1}
- \begin{tabular}{lp{3cm}}
- \begin{minipage}[b]{.5\linewidth}
- {\small
- #2
- }
- \end{minipage}
- &
- \centerline{\includegraphics[scale=.5]{#3}}
- \end{tabular}
- #4
-}}
-
-%======================================================================
-
-\branchstrategie{Stratégie 1}
-{
- \ex{git checkout master}\\
- \ex{git rebase nouvfonc}\\
- \ex{git branch -d nouvfonc}
-}
-{strat1.png}
-{
- \begin{itemize}
- \item
- Tout est linéaire, le commit de la branche dont on est parti étant
- en dernier
- \item
- On ne voit pas bien les commits correspondant à la
- nouvelle fonctionnalité
- \end{itemize}
-}
-
-%======================================================================
-
-\branchstrategie{Stratégie 2}
-{
- \ex{git checkout master}\\
- \ex{git merge nouvfonc}\\
- \ex{git branch -d nouvfonc}
-}
-{strat2.png}
-{
- \begin{itemize}
- \item
- Le commit du changement de titre paraît à part, ce qui n'est pas
- encore trop gênant
- \item
- On a l'impression que les premiers commits sont sur la même lancée
- que la branche de nouvelle fonctionnalité, ce qui induit en erreur
- : ce n'est pas clair
- \end{itemize}
-}
-
-%======================================================================
-
-\branchstrategie{Stratégie 3}
-{
- \ex{git checkout nouvfonc}\\
- \ex{git rebase master}\\
- \ex{git checkout master}\\
- \ex{git merge nouvfonc}\\
- \ex{git branch -d nouvfonc}
-}
-{strat3.png}
-{
- \begin{itemize}
- \item
- Tout est linéaire, le commit de la branche dont on est parti étant
- en dernier
- \item
- On ne voit pas bien les commits correspondant à la nouvelle
- fonctionnalité (idem stratégie 1 donc)
- \end{itemize}
-}
-
-%======================================================================
-
-\branchstrategie{Stratégie 4}
-{
- \ex{git checkout nouvfonc}\\
- \ex{git rebase master}\\
- \ex{git checkout master}\\
- \ex{git merge -{}-no-ff nouvfonc}\\
- \ex{git branch -d nouvfonc}
-}
-{strat4.png}
-{
- \begin{itemize}
- \item
- Les deux commits correspondant à la nouvelle fonctionnalité
- apparaissent clairement.
- \item
- C'est le schéma le plus lisible.
- \end{itemize}
-}
-
-%======================================================================
-
-\branchstrategie{Stratégie 5}
-{
- \ex{git checkout master}\\
- \ex{git merge nouvfonc -{}-no-ff}\\
- \ex{git branch -d nouvfonc}
-}
-{strat5.png}
-{
- \begin{itemize}
- \item
- Idem à la stratégie 2, ce n'est pas le ff qui s'est fait dans ce
- cas.
- \end{itemize}
-}
-
-%======================================================================
-
-% \frame{\frametitle{Stratégie 1}
-% \begin{tabular}{lp{3cm}}
-% \begin{minipage}[b]{.5\linewidth}
-% {\small
-% \ex{git checkout master}\\
-% \ex{git rebase nouvfonc}\\
-% \ex{git branch -d nouvfonc}
-% }
-% \end{minipage}
-% &
-% \centerline{\includegraphics[scale=.5]{strat1.png}}
-% \end{tabular}
-
-% \begin{itemize}
-% \item
-% Tout est linéaire, le commit de la branche dont on est parti étant
-% en dernier
-% \item
-% On ne voit pas bien les commits correspondant à la
-% nouvelle fonctionnalité
-% \end{itemize}
-% }
-
-%======================================================================
-
-\subsection{Travail collaboratif}
-
-%======================================================================
-
-\frame{\frametitle{Introduction}
- \begin{itemize}
- \item
- Le travail de plusieurs personnes sur un même projet fait
- automatiquement appel à de la gestion de branches
- \item
- Chaque personne travaille en effet sur une branche de son propre
- dépôt
- \item
- La réconciliation du travail de ces différentes personnes se fait
- en fusionnant les branches correspondantes
- \item
- Plusieurs stratégies peuvent alors être mises en place pour
- effectuer cette fusion
- \end{itemize}
-}
-
-%======================================================================
-
-\subsection{Recommandations}
-
-%======================================================================
-
-\frame{\frametitle{}
- \begin{itemize}
- \item
-
- \end{itemize}
-}
-
-%======================================================================
-
-\section{Gestion des projets à l'IUT}
-
-%======================================================================
-
-\subsection{Authentification SSH}
-
-%======================================================================
-
-\frame{\frametitle{Problématique}
- \begin{itemize}
- \item
- De nombreux serveurs Git utilisent une authentification par clés
- publiques SSH
- \item
- Si le répertoire \ex{\textasciitilde/.ssh} existe et qu'il
- contient des fichiers \ex{id\_rsa} et \ex{id\_rsa.pub}, une clé
- existe déjà~!
- \item
- Sinon, il faut en générer une pour pouvoir communiquer avec les
- serveurs...
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Génération de clé SSH RSA}
- \begin{itemize}
- \item
- Pour générer une clé, utiliser \ex{ssh-keygen}
- \begin{itemize}
- \item
- sous Linux : en standard dans le package \ex{openssh-client}
- \item
- sous Windows : installer MSysGit
- \item
- sous Mac : en standard dans MacOS
- \end{itemize}
- \item
- Lors de la génération, une \emph{passphrase} est demandée
- \begin{itemize}
- \item
- c'est une sorte de mot de passe (ne pas reprendre le mot de
- passe de connexion)
- \item
- cette \emph{passphrase} sera demandée lors des connexions SSH
- \end{itemize}
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Utilisation d'une clé SSH}
- \begin{itemize}
- \item
- Pour pouvoir communiquer \emph{via} SSH avec un serveur, il est
- nécessaire d'y déposer sa clé publique (le contenu du fichier
- \ex{id\_rsa.pub})
- \item
- Les serveurs proposent généralement d'effectuer ce dépôt
- \emph{via} une interface Web
- \item
- À chaque connexion SSH, la \emph{passphrase} sera demandée
- \item
- Pour éviter de taper la \emph{passphrase} à chaque fois, utiliser
- \ex{ssh-agent}
- \begin{itemize}
- \item
- sous Linux et Mac : en tapant \ex{ssh-add}
- \item
- sous Windows : voir
- \url{https://help.github.com/articles/working-with-ssh-key-passphrases}
- \end{itemize}
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Clé SSH et multi-comptes}
- \begin{itemize}
- \item
- Lorsqu'on est susceptible de se connecter depuis plusieurs
- ordinateurs (ou OS) à un serveur Git, plusieurs solutions
- \begin{itemize}
- \item
- générer une clé SSH sur chacun de ses comptes et importer chaque
- clé publique sur le serveur
- \item
- générer une clé SSH sur le premier compte, la copier sur les
- autres comptes et importer la partie publique sur le serveur
- \end{itemize}
- \item
- Il peut être sain de travailler avec plusieurs clés SSH et ainsi
- ne pas mettre tous ses \oe{}ufs dans le même panier...
- \end{itemize}
-}
-
-%======================================================================
-
-% \section{Gérer un dépôt Git sur github}
-
-% %======================================================================
-
-% \frame{\frametitle{Inscription et configuration}
-% \begin{itemize}
-% \item
-% \emph{Github} : \url{https://github.com/}
-% \item
-% Inscription : choisir un compte gratuit
-% \item
-% Ajouter sa clé RSA publique en passant par l'icône \emph{Account
-% settings}
-% \item
-% Au besoin, la créer
-% \begin{itemize}
-% \item
-% sous Linux : les indications sont fournies par Github
-% \item
-% sous Windows : utiliser puttygen
-% \end{itemize}
-% \end{itemize}
-% }
-
-% %======================================================================
-
-% \frame{\frametitle{Configuration}
-% \begin{itemize}
-% \item
-% À l'initiative d'une seule personne, le créateur du projet
-% \item
-% Création d'un dépôt public avec un simple nom
-% \item
-% Suivre les indications fournies par le site !
-% \item
-% Effectuer la configuration globale sur votre machine (si non déjà
-% effectuée)
-% \item
-% Réaliser les étapes d'initialisation du dépôt décrites
-% \item
-% Le dépôt est créé (vérifier sous Github)
-% \item
-% Ajouter les collaborateurs (\emph{Admin\,/\, collaborators})
-% \end{itemize}
-% }
-
-% %======================================================================
-
-% \frame{\frametitle{Rallier un projet existant}
-% \begin{itemize}
-% \item
-% Recommandé, y compris pour le créateur du projet
-% \item
-% Aller sur la page consacrée au projet
-% \item
-% Choisir le protocole SSH parmi ceux proposés
-% \item
-% Copier l'URL associée
-% \item
-% Taper\\
-% \mygit{git clone git@github.com:dosch/test.git}{gitclone.txt}
-% \end{itemize}
-% }
-
-% %======================================================================
-
-\subsection{Gérer un projet sur Redmine (IUT)}
-
-%======================================================================
-
-\frame{\frametitle{Informations générales}
- \begin{itemize}
- \item
- Adresse du serveur, accessible également depuis l'extérieur\\
- \url{https://redmine.iutnc.univ-lorraine.fr}
- \item
- Tous les projets doivent être gérés et rendus sur ce serveur
- \item
- Les tuteurs s'y rendront donc pour les récupérer...
- \item
- Il est nécessaire de s'y connecter \textbf{rapidement} une
- première fois pour y rentrer ses informations personnelles
- \item
- Cette étape est \textbf{nécessaire} pour que les projets tuteurés
- puissent être complètement créés et renseignés sur Redmine
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Informations générales}
- \framesubtitle{Gestion des projets Redmine}
- \begin{itemize}
- \item
- Depuis la rentrée 2013, les étudiants possèdent automatiquement et
- par défaut un projet s'appelant «~Projet de \emph{prénom nom}~»
- \item
- Il est conseillé de laisser ce projet \textbf{inutilisé} et de se
- créer des sous-projets pour chaque nouveau projet à gérer
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Informations générales}
- \framesubtitle{Création des projets Redmine}
- \begin{itemize}
- \item
- Cliquer sur «~Nouveau sous-projet~» (en haut à droite)
- \item
- Saisir les informations demandées, et en particulier
- \begin{itemize}
- \item
- le \emph{nom} du projet : titre libre (concis autant que possible)
- \item
- l'\emph{identifiant} : doit être \textbf{unique} sur Redmine,
- en considérant \textbf{tous} les projets de \textbf{tous} les
- étudiants\\
- $\to$ utiliser son login en préfixe, à des fins de lisibilité et
- d'organisation (ex : \ex{dosch-\emph{nom\_projet}})
- \end{itemize}
- \item
- Ajouter ensuite les autres membres du projet (s'il y en a) en
- cliquant sur \emph{Configuration / Membres} en leur attribuant
- le rôle «~développeur~»
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Informations générales}
- \framesubtitle{Création des projets Redmine}
- \begin{itemize}
- \item
- Utiliser cette procédure pour se créer un projet correspondant au
- projet tuteuré à l'initiative \textbf{d'un seul} des membres du
- groupe
- \begin{itemize}
- \item
- création du projet Redmine sur son compte Redmine
- \item
- ajout des autres membres du groupe
- \item
- communication des informations relatives au projet aux autres
- membres du projet tuteuré
- \end{itemize}
- \item
- Il est naturellement possible de se créer d'autres projets Redmine
- pour gérer d'autres projets que le projet tuteuré
- \item
- Il est même possible de se créer des projets à usage purement
- personnels : permet la sauvegarde et le \emph{versionning}
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Première connexion au serveur}
- \begin{itemize}
- \item
- S'assurer d'avoir une clé SSH
- \item
- Se connecter une première fois sur le serveur Redmine
- \item
- Saisir ses informations personnelles
- \item
- Y importer sa ou ses clés publiques
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Gestion des projets}
- \begin{itemize}
- \item
- Chaque projet tuteuré doit être géré par un projet Redmine
- comprenant
- \begin{itemize}
- \item
- un journal des événements du projet
- \item
- un outil de gestion de tickets (gestion des bugs,
- fonctionnalités à implanter, répartition des rôles...)
- \item
- un porte-documents (pour y déposer de la documentation externe)
- \item
- un wiki (pour y gérer la documentation interne)
- \item
- ...et un dépôt git !
- \end{itemize}
- \item
- Les projets Redmine sont à créer à l'initiative d'un des membres
- du projet tuteuré (voir précédemment)
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Accès à un dépôt Git sous Redmine}
- \begin{itemize}
- \item
- Les dépôts Git sont accessibles \emph{via} SSH à\\
- \ex{git@webetu.iutnc.univ-lorraine.fr:\emph{idprojet}}\\
- où \ex{\emph{idprojet}} est l'identifiant du projet sous Redmine
- \item
- Aucun \emph{login} n'est donc nécessaire, l'authentification se
- fait grâce à la clé SSH...
- \item
- Un premier utilisateur devra configurer le dépôt
- \item
- L'initialisation faite, les autres utilisateurs pourront cloner le
- projet
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Communication avec un dépôt Git sous Redmine}
- \begin{itemize}
- \item
- Le premier utilisateur doit
- \begin{enumerate}
- \item
- créer un dépôt local Git et y faire au moins un \emph{commit}\\
- \ex{cd projet}\\
- \ex{git init}\\
- \ex{git add .}\\
- \ex{git commit -m "Premier commit"}
- \item
- le propager vers le dépôt Git sous Redmine\\
- {\fontsize{2.5mm}{1em}\selectfont \ex{git remote add origin
- git@webetu.iutnc.univ-lorraine.fr:\emph{idprojet}}}\\
- \ex{git push -u origin master}
- \end{enumerate}
- \item
- Les autres membres ont juste besoin de cloner le dépôt\\
- \ex{\fontsize{3mm}{1em}\selectfont git clone
- git@webetu.iutnc.univ-lorraine.fr:\emph{idprojet}}\\
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Utilisation de Git dans le cadre du projet}
- \begin{itemize}
- \item
- Git est utilisable
- \begin{itemize}
- \item
- en ligne de commande
- \item
- intégré aux menus systèmes (sous Windows)
- \item
- sous Emacs ($\geq$ 24.3) avec l'excellent package \ex{magit}
- \item
- \emph{via} les IDE traditionnels (Eclipse, Netbeans, Xcode...)
- \end{itemize}
- \item
- Sous Eclipse
- \begin{itemize}
- \item
- Git est accessible \emph{via} le plugin Egit
- \item
- les commandes les plus courantes sont alors disponibles dans des
- menus tels que
- \begin{itemize}
- \item
- Team
- \item
- Compare with
- \item
- Replace with
- \end{itemize}
- \end{itemize}
- \end{itemize}
-}
-
-%======================================================================
-
-% \frame{\frametitle{Redmine IUT}
-% \begin{itemize}
-% \item
-% Création d'un nouveau sous-projet
-% \begin{enumerate}
-% \item
-% Depuis l'interface Web, création d'un nouveau sous-projet
-% \item
-% Depuis éclipse, création d'une nouvelle application ou
-% positionnement sur une application existante à raccorder au
-% projet Redmine
-% \item
-% Click droit sur le projet, choisir l'entrée \emph{Team} et
-% \emph{Share project...}
-% \item
-% Choisir un projet de type git
-% \item
-% Choisir la case à cocher «~Use ou create repository in parent
-% folder of project~»
-% \item
-% Cliquer sur le bouton «~Create repository~», permetant de créer
-% le dépôt à la racine du projet, en dépit de l'avertissement
-% recommandant de ne pas le faire
-% \item
-% Ajouter un fichier \ex{.gitignore}.
-% En première approche, ce fichier peut contenir les lignes
-% suivantes :
-% %\mylistinginput{.gitignore.sample}
-% \item
-% Faire un premier commit : dans un premier temps, sélectionner
-% tous les fichiers proposés (22 \emph{a priori})
-% \item
-% Aller dans le menu contextuel, entrée \ex{Team / Remote / Push}
-% \item
-% Dans la boîte de dialogue,
-% \ex{git@webetu.iuta.univ-nancy2.fr:xxx}, où \ex{xxx} correspond
-% à l'identifiant du projet précédemment créé sous Redmine
-% \item
-% Sauf que les deux items ci-dessus ne fonctionnent pas.
-% À la place; taper en ligne de commande\\
-% \ex{git remote add hwa git@webetu.iuta.univ-nancy2.fr:hwa}\\
-% \ex{git push hwa master}
-% \item
-% Les push suivants peuvent être réalisés en passant par le menu
-% contextuel, en choisissant \ex{Team / Remote / Push} (cocher la
-% case \emph{Save specifications in specification} la première
-% fois)
-% % \item
-% % Pas encore le top : rien n'est sauvegardé pour des manipulations
-% % en ligne de commande. Il faut soit trouver le moyen de gérer
-% % tout ça depuis eclipse, le mieux surtout si on est Windows, soit
-% % initier quelque chose en ligne de commande qui sera récupéré
-% % ensuite depuis eclipse
-% \end{enumerate}
-% \end{itemize}
-% }
-
-%======================================================================
-
\section{Git : et encore...}
%======================================================================