Skip to content
Snippets Groups Projects
Commit 0c6aa221 authored by Philippe Dosch's avatar Philippe Dosch
Browse files

Splits slides into 3 different parts and introduces a common shared file

parent 96ecc8f1
Branches
No related tags found
No related merge requests found
Expand all Hide whitespace changes
Inline Side-by-side
gitbranch.tex 0 → 100644
+ 476
− 0
View file @ 0c6aa221
\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}
gitcommon.sty 0 → 100644
+ 244
− 0
View file @ 0c6aa221
\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}
}
gitconnect.tex 0 → 100644
+ 472
− 0
View file @ 0c6aa221
\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}
gitmain.tex
+ 1
− 1117
View file @ 0c6aa221
This diff is collapsed.
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment