\documentclass[usepdftitle=false]{beamer}

\usepackage[frenchb]{babel}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{datetime}
\usepackage{eurosym}
\usepackage[]{url}
\usepackage[babel=true]{csquotes}
\usepackage{listings}
\usepackage{fancyvrb}
\usepackage{xcolor}
\hypersetup{
pdfauthor={Thibaud Duhautbout - Rémy Huet},
pdftitle={Formation Picaosft : La gestion de version avec Git},
pdfsubject={Formation niveau 2 : concepts avancés},
pdfkeywords={git, gestion de version, VCS},
pdfproducer={Latex},
}

\beamertemplatenavigationsymbolsempty
\setbeamercolor{orangebox}{bg=orange,fg=black}
\setbeamercolor{terminal}{bg=darkgray,fg=white}

\definecolor{myGreen}{HTML}{0f8e1d}

\newdateformat{nombres}{\THEDAY-\THEMONTH-\THEYEAR}
\def\seplength{.3\topsep}

% Dans le cas d'une compilation pour la présentation, on active les
% pauses dans les slides (inutiles pour la version support à diffuser)
\newcommand{\Pause}{%
\ifdef{\Release}
  {\pause}
  {}
}

\title[Formation Git\_v2]{Formation Picasoft : La gestion de version avec Git (niveau 2)}
\titlegraphic{\includegraphics[scale=.1]{picasoft_logo.png}}
\author[T. Duhautbout - R. Huet]{Thibaud {\sc Duhautbout} \\ Rémy {\sc Huet}}
\institute[Picasoft]{Association Picasoft}
\date[24/10/2018]{Mercredi 24 octobre 2018}

\usetheme{AnnArbor}
\usecolortheme{crane}

\fvset{fontsize=\tiny,commandchars=\\\{\}}

\AtBeginSection[]
{
	\begin{frame}
		\tableofcontents[currentsection, hideothersubsections]
	\end{frame}
}

\begin{document}

\begin{frame}
	\titlepage
\end{frame}

\section{Petits rappels}

\begin{frame}[fragile]
	\frametitle{Gestion de version de base}
	\framesubtitle{Valider et vérifier ses changements}
	\begin{block}{Init, status, add, commit}
		\begin{itemize}
			\item \verb+git init+ : création d'un dépôt;
			\item \verb+git status+ : visualisation du statut du dépôt;
			\item \verb+git add+ : ajout de fichiers dans la zone de validation;
			\item \verb+git commit -m ``message''+ : validation des changements.
		\end{itemize}
	\end{block}
	\begin{block}{Diff, log}
		\begin{itemize}
			\item \verb+git log+ : afficher l'historique des commits;
			\item \verb+git diff+ : changements par rapport à la zone de validation;
			\item \verb+git diff <commit>+ : changements depuis un commit;
			\item \verb+git diff <commit1> <commit2>+ : changements entre deux commits.
		\end{itemize}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Gestion de version de base}
	\framesubtitle{Mettre de côté ou annuler ses changements}
	\begin{block}{Stash}
		\begin{itemize}
			\item \verb+git stash+ : mettre ses changements sur la pile stash;
			\item \verb+git stash pop+ : récupérer le dernier stash.
		\end{itemize}
	\end{block}
	\begin{block}{Checkout}
		\begin{itemize}
			\item \verb+git checkout <commit>+ : remettre son dépôt dans un état antérieur (de manière provisoire et réversible);
			\item \verb+git checkout master+ : revenir au dernier commit;
			\item \verb+git checkout -- <fichier/dossier>+ : remettre le fichier/dossier dans l'état du dernier commit (irréversible).
		\end{itemize}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Gestion de version de base}
	\framesubtitle{Les remotes}
	\begin{block}{Clone, pull, push}
		\begin{itemize}
			\item Utilisation du GitLab de l'UTC (\url{https://gitlab.utc.fr});
			\item \verb+git clone <url>+ : récupération d'un dépôt depuis le remote;
			\item \verb+git pull+ : récupérer des cangements depuis le dépôt en ligne;
			\item \verb+git push+ : pousser des changements sur le dépôt en ligne.
		\end{itemize}
	\end{block}
\end{frame}

\begin{frame}
	\frametitle{Avant de commencer}
	Des questions ?
\end{frame}

\section{Amélioration de son espace de travail}
\subsection{Génération de clé ssh}
\begin{frame}
	\frametitle{Générer sa paire de clés}
	\framesubtitle{Utilité et théorie}
	\begin{block}{Pourquoi ?}
		Une sorte de \enquote{mot de passe} stocké sur la machine, qui permet de s'authentifier à un serveur ssh.
		Dans notre cas, permettra de se passer de login et de mot de passe pour l'authentification à la remote.
	\end{block}
	\begin{block}{Comment ça marche ?}
		\begin{itemize}
			\item Algorithme RSA;
			\item Une clé publique destinée à être partagée au monde;
			\item Une clé privée permettant de certifier que l'on est la personne à qui appartient la clé publique.
		\end{itemize}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Générer sa paire de clés}
	\framesubtitle{Comment faire ?}
	\begin{beamercolorbox}[rounded=true,shadow=true]{terminal}
\begin{Verbatim}
$ ssh-keygen -b 4096 \Pause
Generating public/private rsa key pair.
Enter file in which to save the key (/home/remy/.ssh/id_rsa):\Pause
Enter passphrase (empty for no passphrase):\Pause
Enter same passphrase again:\Pause
The key fingerprint is:
SHA256:B8IbOIXrMqGEgYOKhqnbelKKbzN35XqlVK/IfUnGQJQ remy@remy-HP-ZBook-15-G2
The key's randomart image is:
+---[RSA 4096]----+
|o    ..  ...     |
|=   .+    E      |
|=+  o.+ ..       |
|*o. .. + .o      |
|+. o  . S..+     |
|o + .   o.. =    |
|.= o   = = + .   |
|= * . . * o o    |
|.*.+ ..o   .     |
+----[SHA256]-----+
\end{Verbatim}
	\end{beamercolorbox}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Utilisation}
	\begin{itemize}
		\item Ajout de la clé publique sur GitLab
	\end{itemize}
	Pour indiquer à git qu'il faut utilisaer \verb+ssh+ plutôt que \verb+https+ pour se connecter au remote, on utilise une uri différente lors du \verb+clone+

	Par exemple, pour récupérer le repo de la formation niveau 1, on tapera \verb+git clone git@gitlab.utc.fr:picasoft/formations/A18/git-v1+
\end{frame}

\section{Les branches}

\subsection{Principe}

\begin{frame}{Principe}

	\begin{block}{}
	\enquote{Git permet de maintenir plusieurs versions différentes en parallèle}
	\begin{flushright}
		\textit{Nous, il y a deux semaines}
	\end{flushright}
	\end{block}

	\Pause

	Concrètement, tous les commits ne sont pas nécessairement sur la même \textbf{branche} de l'arbre.

	\begin{center}
	\includegraphics[width=.7\linewidth]{./imgs/branches.eps}
	\end{center}

	\textit{Le sens des flèches n'est pas chronologique ! Chaque commit pointe vers son père.}

\end{frame}

\begin{frame}{Création d'une divergence -- cas 1}
	\begin{center}
		\includegraphics[width=.4\linewidth]{./imgs/divergence.png}
	\end{center}

	\begin{block}{Analyse}
		\begin{itemize}
			\item C2 et C3 ont tous les deux C1 comme père;
			\item C2 et C3 introduisent des modifications différentes après C1;
			\item ici, C2 et C3 sont sur \textbf{deux branches différentes de C1};
		\end{itemize}
	\end{block}
\end{frame}

\begin{frame}{Création d'une divergence -- cas 2}
	\begin{center}
		\includegraphics[width=.3\linewidth]{./imgs/divergence_2.png}
	\end{center}

	\begin{block}{Analyse}
		\begin{itemize}
			\item C4 et C5 ont tous les deux C3 comme père;
			\item C4 et C5 introduisent des modifications différentes après C3;
			\item C4 est sur une branche \textbf{différente de C3};
			\item C5 est sur \textbf{la même branche que C3}.
		\end{itemize}
	\end{block}
\end{frame}

\begin{frame}{Création d'une divergence}
	\begin{block}{}
		\centering
		\enquote{Mais pourquoi est-ce qu'on fait ça ?}
	\end{block}

	\Pause

	\begin{itemize}
		\item pour isoler les travaux en cours
		\item pour enregistrer des versions spécifiques
	\end{itemize}

	\Pause

	\begin{block}{}
		\centering
		\enquote{Et c'est quoi la différence entre le cas 1 et le cas 2 ?}
	\end{block}

	\Pause

	En théorie, pas grand chose à part la couleur :
	\begin{itemize}
		\item c'est une divergence dans les deux cas;
		\item dans le cas 1, il est encore possible de faire un commit sur la branche jaune après C1.
	\end{itemize}
	En pratique avec git :
	\begin{itemize}
		\item ça dépend des modifications apportées et du sens que vous donnez à vos branches.
	\end{itemize}

\end{frame}

\begin{frame}{Création d'une divergence -- illustration}
	\begin{center}
	\includegraphics[width=.6\linewidth]{./imgs/branches.eps}
	\end{center}

	\begin{block}{Exemple}
		\begin{itemize}
			\item C0 et C1 sont sur une branche \enquote{stable} : tout est relu
			\Pause
			\item C2 introduit des modifications non relues à un endroit
			\item C3 introduit des modifications non relues à un autre endroit
			\Pause
			\item C4 avance à partir de C3 mais c'est incomplet, donc nouvelle branche
			\Pause
			\item C5 poursuit les modifications de C3
			\item C6 poursuit les modifications de C4
		\end{itemize}
	\end{block}
\end{frame}

\subsection{Application}

\subsection{Fusion de deux branches}

\subsection{Gestion des conflits}

\subsection{Travail collaboratif}

\section{Introduction à git flow}
\begin{frame}[fragile]
	\frametitle{Pourquoi Git flow ?}
	Problématique de collaboration sur des gros projets :
	\begin{itemize}
		\item Avoir une branche \verb+master+ stable à tout moment;
		\item Créer une branche par nouvelle fonctionnalité :
			\begin{itemize}
				\item Pour une organisation plus claire;
				\item Pour développer plusieurs fonctionnalités en parallèle.
			\end{itemize}
		\item Avoir une branche de développement pour merge les fonctionnalités finies, mais qui n'est pas une branche stable.
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Comment ça fonctionne ?}
	\framesubtitle{Les branches master et develop}
	\begin{block}{La branche master}
		Il s'agit d'une branche stable. À tout moment son commit le plus récent correspond à une version fonctionnelle du projet.
	\end{block}
	\begin{block}{La branche develop}
		C'est la branche de travail courante. C'est sur celle-ci qu'on ajoute au fur et à mesure les fonctionnalités, et que l'on mergera dans master pour effectuer une release
	\end{block}
\end{frame}

\begin{frame}
	\frametitle{Comment ça fonctionne ?}
	\framesubtitle{Feature, bugfix, release et hotfix}
	Ce sont des branches avec des utilités bien définies :
	\begin{block}{feature}
		Une fonctionnalité particulière, qui sera merge dans develop quand elle sera finie
	\end{block}
	\begin{block}{bugfix}
		Résolution d'un bug {\bf qui n'existe que sur dévelop}. Sera merge dans develop
	\end{block}
	\begin{block}{release}
		Permet de faire des modifications sur le projet avant la sortie d'une release. Merge dans master et dans develop (crée un tag sur master)
	\end{block}
\end{frame}

\begin{frame}
	\frametitle{Comment ça marche ?}
	\framesubtitle{Hotfix}
	\begin{block}{hotfix}
		Pour résoudre un bug qui est présent sur une version \enquote{stable} (donc dans master). Sera merge dans develop {\bf et} dans master (crée un tag sur master).
	\end{block}
	\begin{center}
		\includegraphics[height=.5\paperheight]{imgs/git_flow.png}
	\end{center}
\end{frame}

\end{document}