%======================================================================

\section{Les bases de Git}

%======================================================================

\subsection{Principes liés à Git}

%======================================================================

\frame{\frametitle{Possibilités}
  \begin{itemize}
  \item
    Les VCS travaillent principalement sur les fichiers texte
    (\ex{.txt}, \ex{.c}, \ex{.java}, \ex{.xml}...)
  \item
    Les fichiers binaires (\ex{.jpg}, \ex{.doc}, \ex{.pdf}...) peuvent
    également être intégrés mais ne peuvent prétendre qu'au
    versionage, pas à l'édition collaborative
  \item
    Que faut-il stocker dans un dépôt ?
    \begin{itemize}
    \item
      \textbf{toutes} les ressources nécessaires à la construction
      d'un projet...
    \item 
      ...\textbf{à l'exception} de celles qui sont générées
      automatiquement (\ex{.o} en C, \ex{.class} en Java...)
    \end{itemize}
  \end{itemize}
}

%======================================================================

\frame{\frametitle{Usages}
  \begin{itemize}
  \item
    Utiliser un VCS suppose que les développeurs travaillent en
    concertation~! 
  \item
    Les VCS supposent que les développeurs ne modifient pas la même
    partie d'un même fichier
  \item
    Les VCS peuvent fusionner deux modifications relatives à un même
    fichier si elles concernent des parties différentes
  \item
    Dans le cas contraire, un \emph{conflit} est généré et doit être
    réglé manuellement (par les développeurs)
  \end{itemize}
}

%======================================================================

\frame{\frametitle{Principe de fonctionnement d'un dépôt}
  \begin{itemize}
  \item
    Création d'un dépôt (\emph{repository}) vide
  \item
    Alimentation du dépôt par l'intermédiaire de \emph{commits}
  \item
    Un \emph{commit} contient
    \begin{itemize}
    \item
      un ensemble de modifications de données, suite aux manipulations
      des fichiers du projet (création, édition, suppression,
      renommage...)
    \item
      un \emph{log} associé : commentaire sur la nature des modifications
    \item
      des méta-informations : identifiant de \emph{commit}, auteur, date
    \end{itemize}
  \end{itemize}
}

%======================================================================

\frame{\frametitle{Différents niveaux de stockage}
  \begin{center}
    \includegraphics[height=5cm]{couches-git.eps}
  \end{center}
}

%======================================================================

\frame{\frametitle{Différents niveaux de stockage}
  \begin{itemize}
  \item
    \emph{Répertoire de travail}
    \begin{itemize}
    \item
      contient la copie locale des sources du projet
    \item
      contient, à sa racine, le répertoire \ex{.git} (configuration du
      projet)
    \end{itemize}
  \item
    \emph{Index}
    \begin{itemize}
    \item
      espace temporaire utilisé pour préparer la transition de données
      entre le répertoire de travail et le dépôt local
    \item
      permet de \textbf{choisir} quel sous-ensemble de modifications,
      présentes dans le répertoire de travail, répercuter dans le
      dépôt local lors d'un \emph{commit}
    \end{itemize}
  \end{itemize}
}

%======================================================================

\frame{\frametitle{Différents niveaux de stockage}
  \begin{itemize}
  \item
    \emph{Dépôt local}
    \begin{itemize}
    \item
      contient la totalité de toutes les versions de tous les fichiers
      du projet, par l'intermédiaire des \emph{commits}
    \item
      contient toutes les méta-informations : historique, \emph{logs},
      \emph{tags}...
    \item
      propre à un utilisateur donné
    \end{itemize}
  \item
    \emph{Dépôt(s) distant(s)}
    \begin{itemize}
    \item 
      est intrinsèquement similaire à un dépôt local
    \item
      peut être
      \begin{itemize}
      \item
        le dépôt local d'un autre utilisateur
      \item
        un dépôt centralisé dédié : il est alors configuré et déployé
        pour pouvoir être partagé entre utilisateurs
      \end{itemize}
    \end{itemize}
  \end{itemize}
}

%======================================================================

\frame{\frametitle{Principe de fonctionnement intrinsèque}
  \begin{itemize}
  \item
    Contrairement à d'autres VCS, Git s'intéresse aux
    \textbf{contenus}, pas aux fichiers en tant que tels
  \item
    Les noms de fichiers, les dates de modification, n'interviennent
    donc pas directement pour déterminer les modifications réalisées
    depuis un \emph{commit} donné
  \item
    Git calcule pour chaque fichier une \emph{signature} SHA-1 lui
    permettant de détecter des changements de contenu
  \item
    Les noms de fichiers, les dates associées, ne sont considérées que
    comme des méta-informations
  \end{itemize}
}

%======================================================================

\frame{\frametitle{SHA-1}
  \framesubtitle{Définition}
  \begin{itemize}
  \item
    Fonction de hachage cryptographique conçue par la NSA
    \begin{itemize}
    \item
      prend en entrée un texte de longueur maximale $2^{64}$ bits,
      soit environ $2.3 \times 10^{18}$ caractères ($\sim 2.3$~Eo)
    \item
      produit une signature sur $160$~bits, soit $20$~octets, soit
      $40$~caractères hexadécimaux ($\sim 1.5 \times 10^{48}$
      possibilités)
    \item
      très bonne répartition des hashs (signatures) produits
    \end{itemize}
  \item
    Exemples
    \begin{codebox}
      \mygit{echo salut | sha1sum}{salut.sha1}
      \mygit{echo Salut | sha1sum}{Salut.sha1}
    \end{codebox}
  \end{itemize}
}

%======================================================================

\frame{\frametitle{SHA-1}
  \framesubtitle{Signatures, aspects mathématiques}
  \begin{itemize}
  \item
    Un \emph{même} contenu fournit toujours la \emph{même} signature
  \item
    D'un point de vue mathématique, il est possible que deux
    contenus différents génèrent une même signature (une
    \emph{collision})
  \item
    Mais en pratique, la probabilité est infinitésimale et peut être
    ignorée sans risque
  \item
    D'ailleurs, les 7 ou 8 premiers caractères d'une signature sont
    quasi systématiquement suffisants pour désigner sans ambiguïté un
    contenu...
  \end{itemize}
}

%======================================================================

\frame{\frametitle{SHA-1}
  \framesubtitle{Collisions et probabilités}
  \begin{itemize}
  \item
    Il faudrait que $10$ milliards de programmeurs fassent $1$
    \emph{commit} par seconde pendant presque $4$ millions d'années
    pour qu'il y ait 50\% de chance qu'une collision se produise
  \item
    «~\emph{Il y a plus de chances que tous les membres d'une équipe
    soient attaqués et tués par des loups dans des incidents sans
    relation la même nuit}~»\\
  {\tiny \hfill \emph{Documentation officielle Git,
      \url{http://git-scm.com/book}}}
  \end{itemize}
}

%======================================================================

\frame{\frametitle{Usage des signatures SHA-1}
  \begin{itemize}
  \item
    Sous Git, les signatures SHA-1 permettent d'identifier les
    contenus
    \begin{itemize}
    \item
      de fichiers
    \item
      de versions d'un projet (à travers ses fichiers)
    \item
      de \emph{commits} (en y associant des infos relatives à leur
      auteur)
    \end{itemize}
  \item
    À chaque fois, la signature obtenue est supposée unique et
    constitue un identifiant fiable
  \item
    Cette gestion de signatures est à l'origine des performances
    de Git
  \item 
    Elle lui permet aussi de garantir l'intégrité d'un projet dans un
    contexte distribué
  \end{itemize}
}