...
 
Commits (113)
*~
*.toc
*.out
*.aux
*.log
*.nav
*.pdf
*.snm
*.swp
*.vrb
stages:
- build
- deploy
beamer-build:
image: aergus/latex
stage: build
script:
- make
artifacts:
paths:
- "*.pdf"
tags:
- docker
synchronize:
stage: deploy
before_script:
- apt-get update -y
- apt-get install -y rsync
- echo "$ssh_key" > id_rsa
- chmod 600 id_rsa
script:
# In non-interactive context, don't check host identity
- rsync -e"ssh -i id_rsa -o StrictHostKeyChecking=no" -avz *.pdf apiInit@pica02.picasoft.net:~/artefact/git/
after_script:
- rm id_rsa
dependencies:
- beamer-build
tags:
- linux
only:
- master
\ No newline at end of file
24 janvier 2019
Rémy Huet (remy.huet@etu.utc.fr), Thibaud Duhautbout (thibaud@duhautbout.ovh), Quentin Duchemin (quentinduchemin@tuta.io), Romain Maliach (rmaliach@etu.utc.fr), Association Picasoft (picasoft@assos.utc.fr)
La présentation et tous les fichiers qui composent ce dépôt sont sous licence
Creative Commons 4.0 Attribution - Partage dans les Mêmes Conditions 4.0
International (CC BY-SA 4.0).
Vous êtes libre de partager (copier, distribuer et communiquer le matériel par
tous moyens et sous tous formats) et d'adapter (remixer, transformer et créer à
partir du matériel) ces fichiers pour toute utilisation, y compris commerciale.
Visitez https://creativecommons.org/licenses/by-sa/4.0/deed.fr pour plus
d'informations.
# Api/casoft Init Jour 4 : Git
## Description
Repo de la formation git de l'api/casoft Init. **En cas de questions :** [remy.huet@etu.utc.fr](mailto://remy.huet@etu.utc.fr), [thibaud@duhautbout.ovh](mailto://thibaud@duhautbout.ovh), [quentinduchemin@tuta.io](mailto://quentinduchemin@tuta.io).
Pour aller plus loin : lire la [documentation de git](https://git-scm.com/docs).
En cas de remarques sur la présentation (ou de questions aussi), vous pouvez utiliser le [système d'issues](https://gitlab.utc.fr/picasoft/apis/h19/init/git/issues).
## Présentation
La présentation au format PDF est disponible [ici](https://school.picasoft.net/artefact/git/main.pdf).
## Contribuer !
Créez une branche, et faites une merge request ! Faites la relire par un tiers qui la valide et la merge.
N'oubliez pas d'ajouter votre nom dans la license et dans les auteurs de `main.tex`
## Plan
Le plan est disponible [ici](docs/plan.md)
# Plan de la présentation
## À propos
La formation sur git durera une journée (~6/7 heures). Elle abordera à la fois l'utilisation de Git (local et remotes) mais aussi les méthodes de gestion de travail propres à GitLab.
**Comment lire ce plan ?**
Les sections sont numérotés en niveau 1. Les sous-sections en niveau 2. Une indentation sous la section/sous section est un titre, deux un sous-titre. Un niveau sans "fils" est une frame.
## Plan
1. Introduction
* OK - Qu'est ce que git ?
* OK - Pourquoi la gestion de version ?
* OK - Différents logiciels de gestion de version
* OK - Petite histoire de Git
*(transition ?)*
2. Versionner son travail
1. Configuration et initialisation
* OK - Création d'un dépôt Git
* OK - Configurer son identité
* OK - Configuration locale / configuration globale
2. Gestion théorique
* OK - Fonctionnement de Git
* Working Directory vs. Staging Area vs. Repository
* OK - Explications
3. Gestion linéaire en pratique
* Créer des versions
* OK - Working directory <-> staging area
* OK - Exemples
* OK - Staging area <-> repository
* OK - Dissection d'un commit
* Visualiser les différences
* OK - Git log
* OK - Git diff
* OK - Git show
3. Utiliser les versions
1. Le HEAD
* Qu'est-ce que le HEAD ?
2. Marquer une version
* Git tag
3. Mettre de côté ses modifications
* Enregistrer les modifications locales
* Restaurer les modifications locales
4. Parcourir l'historique
* Changer de version
* Revenir au dernier commmit
* Annuler des changements
5. Annuler des commits
* Sans modification d'historique
* Avec modification d'historique
* Git reset
* Git commit --amend
4. Utilisation des remotes
1. Présentation
* Le concept des remotes
* Exemples de remotes
* Création d'un dépôt distant
2. Récupérer du travail existant
* Cloner un dépôt existant
* Tirer des changements
3. Envoyer son travail
* Pousser des commits
5. Gestion non linéaire [branche gestion_non_lineaire non mergée]
1. Explications théoriques
* OK - Principe de gestion non linéaire
* Création d'une divergence
* OK - Principe de la gestion non linéaire
* OK - Explications
* OK - Création d'une divergence : analyse et mise en contexte
* OK - Illustrations / Exemple
* OK - Fusion
2. Application à Git
* OK - Gestion des branches
* OK - Changer de branche
* OK - Visualisation
3. Fusionner des branches
* OK - Le merge
* Le rebase
* OK - Avertissement
* OK - Comparaison avec le merge
* OK - Application simple
* Rebase interactif
* Le cherry-pick
6. Résolution de conflits
1. Les conflits
* Qu'est-ce qu'un conflit ?
* Exemple de situation conflictuelle
* Comment se présente un conflit ?
* Concrètement, quand peut-on avoir un conflit ?
* Merge
* Rebase
* Pull
2. Résoudre un conflit
* En théorie
* Application
3. Historiques divergents
* Quand parle-t-on de divergence ?
* Comment diverge-t-on ?
* Résoudre des divergences ?
7. Travail collaboratif avec Git et GitLab
1. Présentation de git flow
2. Présentation de GitLab
This diff is collapsed.
\documentclass[usepdftitle=false]{beamer}
\usepackage[french]{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}
\usepackage{tikz}
\hypersetup{
pdfauthor={Rémy Huet, Thibaud Duhautbout, Quentin Duchemin, Romain Maliach},
pdftitle={Api/casoft Init - Jour 4 : Git},
pdfsubject={Formation git},
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}
\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[Api/casoft Init - Git]{Api/casoft Init - Jour 4 - Git}
\titlegraphic{\includegraphics[width=5em]{./imgs/picasoft_logo.png}\\ \href{https://creativecommons.org/licenses/by-sa/4.0/deed.fr}{\includegraphics[width=4em]{./imgs/licence.eps}}}
\author[Huet, Duhautbout, Duchemin, Maliach]{%
\phantom{x}\hfill Rémy {\sc Huet} \hfill Thibaud {\sc Duhautbout}\hfill \phantom{x} \\
\phantom{x}\hfill Quentin \textsc{Duchemin} \hfill Romain {\sc Maliach} \hfill \phantom{x}}
\institute[]{Association Picasoft}
\date[04/07/2019]{Jeudi 4 juillet 2019}
\usetheme{AnnArbor}
\usecolortheme{crane}
\fvset{fontsize=\tiny,commandchars=\\\{\}}
\AtBeginSection[]
{
\begin{frame}
\begingroup
\footnotesize
\tableofcontents[currentsection, hideothersubsections]
\endgroup
\end{frame}
}
\AtBeginSubsection[]
{
\begin{frame}
\begingroup
\footnotesize
\tableofcontents
[
currentsection,
currentsubsection,
subsectionstyle=show/shaded/hide
]
\endgroup
\end{frame}
}
\begin{document}
\begin{frame}
\titlepage
\end{frame}
\begin{frame}
\frametitle{Table des matières}
\begingroup
\footnotesize
\tableofcontents[hidesubsections]
\endgroup
\end{frame}
\begin{frame}
\frametitle{Question avant de commencer}
\begin{flushright}
{\it\enquote{Est-ce qu'on peut s'en servir pour donner de l'élan à un pigeon ?} \\ Yvain, chevalier au lion \\ Kaamelott Livre III ep. 95 L'Étudiant}
\end{flushright}
\end{frame}
\section{Introduction}
\input{./src/tex/introduction.tex}
\section{Versionner son travail}
\input{./src/tex/versionner_travail.tex}
\section{Utiliser les versions}
\input{./src/tex/utiliser_versions.tex}
\section{Utilisation des remotes}
\input{./src/tex/utilisation_remotes.tex}
\section{Gestion non linéaire}
\input{./src/tex/gestion_non_lineaire.tex}
\section{Résolution des conflits}
\input{./src/tex/resolution_conflits.tex}
\section{Travail collaboratif avec Git et GitLab}
\input{./src/tex/travail_collaboratif.tex}
\section{Pour aller plus loin !}
\input{./src/tex/aller_plus_loin.tex}
\end{document}
all:
pdflatex main.tex
pdflatex main.tex
presentation:
pdflatex "\def\Release{PRESENTATION}\input{main}"
pdflatex "\def\Release{PRESENTATION}\input{main}"
\subsection{Annuler des commits}
\input{src/tex/aller_plus_loin/annuler_commits.tex}
\begin{frame}[fragile]
\frametitle{Sans modification d'historique}
\begin{block}{}
\enquote{
Dis, je me suis planté sur un commit, j'aimerais bien l'annuler \ldots
C'est possible ? \\
Oui ! Utilises git revert !
}
\end{block}
\verb+git revert+ permet d'annuler un commit, en en créant un commit qui fait les modifications inverses.
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git revert HEAD \Pause
[master 6e23b65] Revert "Troisième commit"
1 file changed, 1 deletion(-)
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git show HEAD \Pause
\textcolor{yellow}{commit 6e23b65243628f81924f650466c86ef3a8e42ec5 (}{\bf\textcolor{cyan}{HEAD -> }\textcolor{green}{master}}\textcolor{yellow}{)}
Author: huetremy <remy.huet@etu.utc.fr>
Date: Fri Jan 11 14:20:59 2019 +0100
Revert "Troisième commit"
This reverts commit a04da653083b6b0ba3eea2bce98d903acfd0a4d3.
diff --git a/API.txt b/API.txt
index a03f78c..5596950 100644
--- a/API.txt
+++ b/API.txt
\textcolor{cyan}{@@ -1,3 +1,2 @@}
Je suis le premier fichier utilisé pour cette API sur git
J'ajoute une ligne à mon fichier
\textcolor{red}{-Encore une ligne en plus !} \Pause
$ git diff HEAD\~{}2
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]
\frametitle{Avec modification d'historique}
\framesubtitle{Git reset}
\begin{block}{À quoi ça sert ?}
\begin{itemize}
\item \verb+git reset+ permet de remettre le HEAD dans un état spécifique, et modifie l'arbre en conséquence (supprime tous les commits après)
\item \verb+git reset --soft+ laisse le working directory dans l'état dans lequel il était
\item \verb+git reset --hard+ remet le working directory dans l'état du commit sur lequel on reset.
\end{itemize}
\end{block}
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git reset --soft HEAD~1 \Pause
$ cat API.txt \Pause
Je suis le premier fichier utilisé pour cette API sur git
J'ajoute une ligne à mon fichier
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git log --graph --all \Pause
* \textcolor{yellow}{commit a04da653083b6b0ba3eea2bce98d903acfd0a4d3 (}{\bf\textcolor{cyan}{HEAD -> }\textcolor{green}{master}}\textcolor{yellow}{)}
\textcolor{red}{|} Author: huetremy <remy.huet@etu.utc.fr>
\textcolor{red}{|} Date: Fri Jan 11 10:16:10 2019 +0100
\textcolor{red}{|}
\textcolor{red}{|} Troisième commit
\textcolor{red}{|}
* \textcolor{yellow}{commit 5b63bd1f9afe4685b60074030960e39bb5152e67}
\textcolor{red}{|} Author: Thibaud Duhautbout <thibaud@duhautbout.ovh>
\textcolor{red}{|} Date: Thu Jan 3 15:55:33 2019 +0100
\textcolor{red}{|}
\textcolor{red}{|} Second commit
\textcolor{red}{|}
* \textcolor{yellow}{commit 712951dbb3ee0cc4d248582dc5408da3afdec853 (tag: mon_tag)}
Author: Thibaud Duhautbout <thibaud@duhautbout.ovh>
Date: Thu Jan 3 15:37:54 2019 +0100
Ajout du premier fichier
\end{Verbatim}
\end{beamercolorbox}
On voit bien grâce qux deux commandes précédentes que le commit a été supprimé mais que les modifications ont été gardées\ldots
Maintenant :
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git commit -am ''Commit de revert'' \Pause
[master eae33f2] Commit de revert
1 file changed, 1 deletion(-)
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git reset --hard HEAD~1 \Pause
HEAD est maintenant à a04da65 Troisième commit \Pause
$ cat API.txt \Pause
Je suis le premier fichier utilisé pour cette API sur git
J'ajoute une ligne à mon fichier
Encore une ligne en plus ! \Pause
$ git log --graph --all \Pause
* \textcolor{yellow}{commit a04da653083b6b0ba3eea2bce98d903acfd0a4d3 (}{\bf\textcolor{cyan}{HEAD -> }\textcolor{green}{master}}\textcolor{yellow}{)}
\textcolor{red}{|} Author: huetremy <remy.huet@etu.utc.fr>
\textcolor{red}{|} Date: Fri Jan 11 10:16:10 2019 +0100
\textcolor{red}{|}
\textcolor{red}{|} Troisième commit
\textcolor{red}{|}
* \textcolor{yellow}{commit 5b63bd1f9afe4685b60074030960e39bb5152e67}
\textcolor{red}{|} Author: Thibaud Duhautbout <thibaud@duhautbout.ovh>
\textcolor{red}{|} Date: Thu Jan 3 15:55:33 2019 +0100
\textcolor{red}{|}
\textcolor{red}{|} Second commit
\textcolor{red}{|}
* \textcolor{yellow}{commit 712951dbb3ee0cc4d248582dc5408da3afdec853 (tag: mon_tag)}
Author: Thibaud Duhautbout <thibaud@duhautbout.ovh>
Date: Thu Jan 3 15:37:54 2019 +0100
Ajout du premier fichier
\end{Verbatim}
\end{beamercolorbox}
Le commit a bien été effacé, mais cette fois les modifications n'ont pas été gardées
\end{frame}
\begin{frame}[fragile]
\frametitle{Avec modification d'historique}
\framesubtitle{Git commit --amend}
\begin{block}{}
\enquote{
Dis, j'aimerais faire une toute petite modification sur un commit, c'est possible ? \\
-- Oui ! Utilises git commit \--\--ammend
}
\end{block}
\verb+git commit --ammend+ permet de modifier un commit (tant son message que son contenu, son auteur \ldots)
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ echo "Je suis l'apiinit" >> API.txt && git commit -am "Commit supplémentaire" \Pause
$ sed -i "s|apiinit|Api/casoft init|" API.txt \Pause
$ git commit -a --amend \Pause
[master 168efba] Commit supplémentaire
Date: Fri Jan 11 14:53:09 2019 +0100
1 file changed, 1 insertion(+)
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git log --graph \Pause
* \textcolor{yellow}{commit 168efba77dcfd59ba4346fe4a34427b71db75da7 (}{\bf\textcolor{cyan}{HEAD -> }\textcolor{green}{master}}\textcolor{yellow}{)}
\textcolor{red}{|} Author: huetremy <remy.huet@etu.utc.fr>
\textcolor{red}{|} Date: Fri Jan 11 14:53:09 2019 +0100
\textcolor{red}{|}
\textcolor{red}{|} Commit supplémentaire
\textcolor{red}{|}
* \textcolor{yellow}{commit a04da653083b6b0ba3eea2bce98d903acfd0a4d3}
\textcolor{red}{|} Author: huetremy <remy.huet@etu.utc.fr>
\textcolor{red}{|} Date: Fri Jan 11 10:16:10 2019 +0100
\textcolor{red}{|}
\textcolor{red}{|} Troisième commit
\textcolor{red}{|}
[\ldots] \Pause
$ git show HEAD \Pause
\textcolor{yellow}{commit 168efba77dcfd59ba4346fe4a34427b71db75da7 (}{\bf\textcolor{cyan}{HEAD -> }\textcolor{green}{master}}\textcolor{yellow}{)}
Author: huetremy <remy.huet@etu.utc.fr>
Date: Fri Jan 11 14:53:09 2019 +0100
Commit supplémentaire
{\bf{}diff --git a/API.txt b/API.txt}
{\bf{}index a03f78c..4af702a 100644}
{\bf{}--- a/API.txt}
{\bf{}+++ b/API.txt}
\textcolor{cyan}{@@ -1,3 +1,4 @@}
Je suis le premier fichier utilisé pour cette API sur git
J'ajoute une ligne à mon fichier
Encore une ligne en plus !
\textcolor{myGreen}{+Je suis l'Api/casoft init}
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\subsection{Explications théoriques}
\input{src/tex/gestion_non_lineaire/explications_theoriques.tex}
\subsection{Application à Git}
\input{src/tex/gestion_non_lineaire/application_git.tex}
\subsection{Fusionner des branches}
\input{src/tex/gestion_non_lineaire/fusionner_branches.tex}
\begin{frame}[fragile]
\frametitle{Gestion pratique des branches}
\begin{block}{Création d'une branche}
\begin{itemize}
\item \verb+git branch <nom>+ pour créer une branche ;
\item \verb+git checkout -b <nom>+ pour créer une branche et changer la branche courante pour celle-ci.
\end{itemize}
\end{block}
\Pause
\begin{block}{Statut des branches}
\begin{itemize}
\item La commande \verb+git status+ indique la branche courante;
\item La commande \verb+git branch+ montre la liste des branches et la branche courante.
\end{itemize}
\end{block}
\Pause
\begin{block}{Suppression d'une branche}
\begin{itemize}
\item \verb+git branch -d <nom>+ pour supprimer une branche;
\item Si la branche n'a pas été fusionnée, \verb+git branch -D <nom>+.
\end{itemize}
\end{block}
\end{frame}
\begin{frame}[fragile]
\frametitle{Application}
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git branch premiere_branche \Pause
$ git branch \Pause
* \textcolor{myGreen}{master}
premiere_branche \Pause
$ git checkout -b develop \Pause
Basculement sur la nouvelle branche 'develop' \Pause
$ git status \Pause
Sur la branche develop
rien à valider, la copie de travail est propre \Pause
$ git branch -d premiere_branche \Pause
Branche premiere_branche supprimée (précédemment 168efba)
$ touch dev.txt \Pause
$ git add -A && git commit -m ''Ajout fichier dev'' \Pause
[develop 2292018] Ajout fichier dev
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 dev.txt
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]
\frametitle{Changer de branche}
\framesubtitle{Plus facile qu'à l'UTC !}
\begin{block}{Comment faire ?}
\begin{itemize}
\item Une commande simple : \verb+git checkout <nom_de_la_branche>+;
\item {\bf Attention :} ne pas avoir de changements non validés ! (ou passer par un \verb+git stash+)
\end{itemize}
\end{block}
\Pause
\begin{block}{Rappel}
\verb+git checkout+ sert aussi à se déplacer sur un commit précis. \\
En fait, cette commande sert à déplacer le \verb+HEAD+. On peut assimiler un \verb+checkout+ sur une branche à un \verb+checkout+ sur un commit.\\
En fait, le nom de le branche n'est {\bf qu'une étiquette} sur le dernier commit de celle-ci.
\end{block}
\end{frame}
\begin{frame}[fragile]
\frametitle{Visualisation}
\framesubtitle{Un joli graphe !}
\begin{itemize}
\item En console : \verb+git log --graph --all+
\item Depuis GitLab :
\end{itemize}
\begin{center}
\includegraphics[height=.5\paperheight]{imgs/graph_gitlab.png}
\end{center}
\end{frame}
\begin{frame}[fragile]
\frametitle{Visualisation}
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git checkout master && ls \Pause
Basculement sur la branche 'master'
Votre branche est à jour avec 'origin/master'.
API.txt \Pause
$ git log --graph --all \Pause
* \textcolor{yellow}{commit 2292018a27182fef507601140c7f93d679b93678 (}{\bf\textcolor{green}{develop}}\textcolor{yellow}{)}
\textcolor{red}{|} Author: huetremy <remy.huet@etu.utc.fr>
\textcolor{red}{|} Date: Mon Jan 14 14:01:37 2019 +0100
\textcolor{red}{|}
\textcolor{red}{|} Ajout fichier dev
\textcolor{red}{|}
* \textcolor{yellow}{commit 168efba77dcfd59ba4346fe4a34427b71db75da7 (}{\bf\textcolor{cyan}{HEAD -> }\textcolor{green}{master}}\textcolor{yellow}{)}
\textcolor{red}{|} Author: huetremy <remy.huet@etu.utc.fr>
\textcolor{red}{|} Date: Fri Jan 11 14:53:09 2019 +0100
\textcolor{red}{|}
\textcolor{red}{|} Commit supplémentaire
\textcolor{red}{|}
* \textcolor{yellow}{commit a04da653083b6b0ba3eea2bce98d903acfd0a4d3}
\textcolor{red}{|} Author: huetremy <remy.huet@etu.utc.fr>
\textcolor{red}{|} Date: Fri Jan 11 10:16:10 2019 +0100
\textcolor{red}{|}
\textcolor{red}{|} Troisième commit
[\ldots]
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}
\frametitle{Principe de la gestion non linéaire}
Jusqu'ici, on n'a fait que de la gestion linéaire.
Tous les commits étaient sur {\bf une unique branche} (master)
En pratique, tous les commits ne sont pas nécessairement sur la même branche de l'arbre.
\begin{figure}[h]
\centering
\input{src/tikz/arbre.tex}
\end{figure}
{\it Le sens des flèches n’est pas chronologique !
Chaque commit pointe vers son père.}
\end{frame}
\begin{frame}[fragile]{Gestion non linéaire}
\begin{block}{}
\centering
\enquote{Mais pourquoi est-ce qu'on fait ça ?}
\end{block}
\bigskip
\Pause
Une divergence s'effectue à partir d'un certain point : tout le travail précédent l'instant de divergence est commun à toutes les branches postérieures à la création de la divergence.
\medskip
On peut donner quelques raisons \enquote{générales} sur l'utilité des divergences :
\begin{itemize}
\item isoler les travaux indépendants en cours
\item traiter les problèmes d'intégration séparément
\item enregistrer des versions spécifiques
\end{itemize}
En pratique, l'utilisation des divergences dépend beaucoup du type de projet, de la répartition des travaux entre les contributeurs et des méthodes de travail adoptées.
\end{frame}
\begin{frame}
\frametitle{Création d'une divergence}
\framesubtitle{Analyse}
\begin{figure}[h]
\centering
\input{src/tikz/arbre.tex}
\end{figure}
\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{frame}
\begin{frame}
\frametitle{Création d'une divergence}
\framesubtitle{Analyse}
\begin{figure}[h]
\centering
\input{src/tikz/arbre.tex}
\end{figure}
\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{frame}
\begin{frame}
\frametitle{Création d'une divergence}
\framesubtitle{Mise en contexte}
\begin{block}{}
Alice, Bob et Charlie travaillent sur un rapport ensemble et décident d'utiliser Git pour gérer l'avancée de leur travail.
\end{block}
\begin{figure}[h]
\centering
\input{src/tikz/arbre.tex}
\end{figure}
\begin{itemize}
\item Alice met en place la structure globale du rapport avec C0 et C1
\Pause
\item Bob se charge de la partie 1, il crée une nouvelle branche dédiée à sa partie et ajoute C2
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Création d'une divergence}
\framesubtitle{Mise en contexte}
\begin{figure}[h]
\centering
\input{src/tikz/arbre.tex}
\end{figure}
\begin{itemize}
\item Charlie s'occupe de la partie 2.1 : il ajoute la structure de la partie 2 avec C3 sur une nouvelle branche, et avance sa partie avec C5
\Pause
\item Alice rédige la partie 2.2 : elle crée une nouvelle branche à partir de C3 pour récupérer la structure de la partie 2, puis ajoute C4 et C6
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Fusion !}
\begin{figure}[h]
\centering
\input{src/tikz/arbre.tex}
\end{figure}
\begin{block}{}
\centering
\enquote{Attends un peu, et C7 il fait quoi ? Et pourquoi il a deux pères ?}
\end{block}
\Pause
\begin{itemize}
\item C7 est un commit un peu spécial : c'est un \textbf{commit de fusion};
\item Objectif : intégrer les modifications de la branche bleue dans la branche verte (Alice fusionne ses modifications dans la branche de Charlie);
\item Il a bien \textbf{deux} pères (c'est la seule situation où ça arrive);
\item \textbf{Attention !} Si C5 et C6 portent des modifications qui se recouvrent, la fusion va créer des \textbf{conflits} qu'il faudra régler avant de créer C7.
\end{itemize}
\end{frame}
This diff is collapsed.
\begin{frame}
\frametitle{Qu'est-ce que Git ?}
\begin{block}{À propos}
Git est un {\bf logiciel} de {\bf gestion de version}. Il est {\bf open source} et publié sous {\bf license libre}
\end{block} \Pause
\begin{block}{Sur quelles plateformes ?}
Git est aussi bien disponible sur les distributions {\bf GNU/Linux} que sur {\bf MacOS} et sur {\bf Windows}.
On trouve également des applications Git pour {\bf Android}.
\end{block}
\end{frame}
\begin{frame}
\frametitle{Pourquoi la gestion de version ?}
\begin{itemize}
\item Sauvegarde {\bf incrémentale} du travail \Pause
\item {\bf Suivi} des modifications et {\bf retour en arrière} \Pause
\item {\bf Partage} des modifications \Pause
\item {\bf Centralisation} des sources \Pause
\item {\bf Collaboration} simplifiée \Pause
\item Possibilité de {\bf maintenir plusieurs versions}
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Différents logiciels de gestion de version}
\includegraphics[height=2cm]{./imgs/logo_git.png}
\hfill
\includegraphics[height=2cm]{./imgs/logo_svn.png}
\hfill
\includegraphics[height=2cm]{./imgs/logo_mercurial.png}
\bigskip
\centering
Et plein d'autres !
37 systèmes recensés sur Wikipedia
(\url{https://en.wikipedia.org/wiki/Comparison_of_version_control_software})
\end{frame}
\begin{frame}
\frametitle{Petite histoire de Git}
\begin{figure}[h]
\centering
\includegraphics[scale=.2]{./imgs/logo_git.png}
\end{figure}
\begin{itemize}
\item Créé en 2005 par les développeurs du noyeau Linux
\item Système de gestion de version distribué
\item Rapide
\item Possibilité de développements non-linéaires (branches)
\item Popularité grandissante chez les développeurs
\end{itemize}
\end{frame}
\subsection{Les conflits}
\input{src/tex/resolution_conflits/les_conflits.tex}
\subsection{Résoudre un conflit}
\input{src/tex/resolution_conflits/resoudre_conflit.tex}
\subsection{Historiques divergents}
\input{src/tex/resolution_conflits/historiques_divergents.tex}
\begin{frame}
\frametitle{Quand parler de divergence ?}
\begin{block}{Définition}
On parle de \textbf{divergence} lorsque deux \textbf{historiques} sont \textbf{incompatibles}
\textit{(c'est à dire qu'on ne peut pas pousser ou tirer car les historiques ne sont pas cohérents)}
Il faut bien faire la différence entre le \textbf{retard} d'un historique sur un autre, qui peut se régler via un \texttt{push} ou un \texttt{pull} et une divergence.
\end{block}
\begin{figure}[h]
\centering
\input{src/tikz/divergence.tex}
\caption{Exemple de divergence}
\label{fig:divergence}
\end{figure}
\end{frame}
\begin{frame}
\frametitle{Comment diverger ?}
\begin{block}{Explications}
On vient de voir qu'une divergence était une incohérence entre deux historiques.
On peut donc en déduire plusieurs cas communs de divergence:
\begin{itemize}
\item En faisant un commit sans être à jour avec un repo distant
\item En ammendant ou supprimant un ou plusieurs commits \textit{via un git commit --amend ou un git reset}
\item Lors d'un rebase \textit{(c'est pourquoi on vous a dit de ne jamais rebase une branche déjà suivie)}
\end{itemize}
\end{block}
\end{frame}
\begin{frame}[fragile]
\frametitle{Résoudre des divergences ?}
\begin{block}{Définition}
\textbf{Résoudre une divergence}, c'est faire en sorte que les historiques soient cohérents.
Pour ça, on peut:
\begin{itemize}
\item Remettre toutes les divergences au dessus de l'historique distant via un \texttt{git rebase}.
Ainsi, si on fait un commit sur master en étant en retard sur le remote, on rebasera master sur origin/master et la divergence sera réglée
\item Écrasant son historique local via un \verb+git reset --hard+
\item Écrasant l'historique distant via un \verb+git push --force+
\end{itemize}
\end{block}
\begin{alertblock}{Attention}
On évitera d'ecraser l'historique distant sans être sûr de soi, car cela créera des divergences avec \textbf{tous les autres collaborateurs} du projet.
\end{alertblock}
\end{frame}
\begin{frame}
\frametitle{Qu'est-ce qu'un conflit ?}
{\bf Définition :} On parle de conflit lorsque deux personnes on modifié les mêmes lignes d'un fichier {\bf en parallèle} et que git ne peut donc pas savoir quelle version conserver lors d'une fusion.
\Pause
{\bf Concrètement,} on peut avoir un conflit :
\begin{itemize}
\item Lors d'un merge;
\item Lorsque l'on fait un commit sans être à jour avec la branche distante (ce qui impliquera un merge lors du prochain pull);
\item Lors d'un rebase;
\item Quand on ré-applique des modifications qui avaient été mises de côté via un stash.
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Exemple de situation conflictuelle}
\begin{figure}[h]
\centering
\input{src/tikz/merge.tex}
\end{figure}
\begingroup
\tiny
\begin{block}{Exemple :}
À partir du commit C3 :
\begin{itemize}
\item Alice crée une nouvelle branche sur laquelle elle effectue les commits C4 et C6 ;
\item Pendant ce temps, Bob effectue le commit C5 sur la branche verte il modifie des lignes que Alice modifie également lors de C4 et C6 ;
\item Alice veut fusionner sa branche dans la branche verte. Malheureusement, comme Bob a modifié les mêmes lignes qu'elle, git ne sait pas quelles sont les modifications à garder;
\item Le commit C7 correspond donc à un commit de merge lors duquel Alice règle les conflits entre sa branche et celle de Bob.
\end{itemize}
\end{block}
\endgroup
\end{frame}
\begin{frame}[fragile]
\frametitle{Comment se présente un conflit ?}
Exemple à ne pas taper
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git merge develop \Pause
Fusion automatique de fichier.txt
CONFLIT (contenu) : Conflit de fusion dans fichier.txt
La fusion automatique a échoué ; réglez les conflits et validez le résultat.\Pause
$ git status \Pause
Sur la branche master
Vous avez des chemins non fusionnés.
(réglez les conflits puis lancez "git commit")
(utilisez "git merge --abort" pour annuler la fusion)
Chemins non fusionnés :
(utilisez "git add <fichier>..." pour marquer comme résolu)
\textcolor{red}{modifié des deux côtés : fichier.txt}
aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a") \Pause
$ cat fichier.txt
\ldots
<<<<<<< HEAD
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
=======
Integer nec porta orci, non egestas odio.
>>>>>>> develop
\ldots
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]
\frametitle{En théorie}
\begin{itemize}
\item Git fait de la gestion de versions \enquote{stupidement}.
Il ne comprend pas votre code / votre texte, et ne sait donc pas quoi garder en cas de conflit.
\item Résoudre un conflit c'est dire à Git quelle est la bonne verion à garder.
\item Il peut s'agit d'une des deux versions uniquement, ou d'un mélange des deux.
\item Concrètement cela consite à réécrire les zones délimitées par \verb+<<<<<<<<<<+ et \verb+>>>>>>>>>>+.
\end{itemize}
\end{frame}
\begin{frame}[fragile]
\frametitle{Application}
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ echo "Toto" >> dev.txt && git commit -am "Toto" \Pause
[master 4d47790] Toto
1 file changed, 1 insertion(+)
$ git checkout develop && echo "Titi" >> dev.txt && git commit -am "Titi" \Pause
Switched to branch 'develop'
[develop f32aba6] Titi
1 file changed, 1 insertion(+)
$ git checkout master && git merge develop \Pause
Switched to branch 'master'
Auto-merging dev.txt
CONFLICT (content): Merge conflict in dev.txt
Automatic merge failed; fix conflicts and then commit the result.
$ cat dev.txt \Pause
Ma première ligne
<<<<<<< HEAD
Toto
=======
Titi
>>>>>>> develop
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]{Application}
\begin{block}{}
Pour résoudre le conflit, on va dire à git quelle version du fichier garder.
Ici, on mettra arbitrairement \enquote{Début de nouvelle fonctionnalité}
\end{block}
On modifie le fichier dev.txt :
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
Ma première ligne
Début de nouvelle fonctionnalité
\end{Verbatim}
\end{beamercolorbox}
Puis on finit le merge:
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ git add dev.txt
$ git commit
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\subsection{Gitlab, une forge Git}
\input{src/tex/travail_collaboratif/fonctionnalitesGitlab.tex}
\subsection{Gitflow, un modèle de branche}
\input{src/tex/travail_collaboratif/gitFlow.tex}
\begin{frame}
\frametitle{Qu'est-ce qu'une forge?}
\begin{block}{Forge}
C'est un logiciel complémentaire à Git qui, en plus de gérer les versions, propose:
\begin{itemize}
\item L'hébergement de repos
\item La gestion des bugs, de la documentation, des tâches à accomplir...
\item La protection du repo (mot de passe et clés, droits de l'utilisateur...)
\item Un réseau social permettant à une communauté d'interagir avec le repo
\end{itemize}
\end{block}
L'UTC héberge une instance de la forge \textbf{Gitlab}. Il existe aussi Github, qui est une énorme forge centralisée.
\end{frame}
\begin{frame}
\frametitle{Actions sur des commits}
Les commits étant constitués de diffs, on peut commenter ces diffs:
\begin{minipage}[t]{.5\linewidth}
Cliquer sur un commit:
\begin{figure}[h]
\centering
\includegraphics[width=100px]{imgs/gitlab_commits_history.png}
\end{figure}
Les diffs s'affichent. Cliquer sur un numéro de ligne et commenter.
\end{minipage}%
\begin{minipage}[t]{.5\linewidth}
\begin{figure}[h]
\centering
\includegraphics[width=120px]{imgs/gitlab_comment_diff.png} \\ \includegraphics[width=200px]{imgs/gitlab_comment_done.png}
\end{figure}
\end{minipage}
\end{frame}
\begin{frame}
\frametitle{Les issues: demander des améliorations}
Pour chaque repo, Gitlab tient une liste d'issues. Une issue est un problème ou une demande sur le code. Tout le monde peut déposer des issues mais on peut changer ce comportement.
\begin{block}{}
\centering
\enquote{A quoi ça sert de faire ça sur Gitlab? Je peux très bien tenir la liste des choses à faire sur mon 3310!}
\end{block}
Il y a plusieurs intérêts, par exemple:
\begin{itemize}
\item On peut commenter des fichiers et des diff sans les modifier
\item Cela facilite la communication entre les différents développeurs et permet d'assurer un suivi
\item On peut assigner (confier) une issue à un développeur
\item On peut référencer les issues dans les messages de commit.
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Les issues: la pratique}
Pour créer une issue, rien de plus simple: on clique sur issues puis sur new.
\begin{minipage}[t]{.5\linewidth}
\begin{figure}[h]
\centering
\includegraphics[width=150px]{imgs/gitlab_sidebar.png}
\end{figure}
\end{minipage}%
\begin{minipage}[t]{.5\linewidth}
\begin{figure}[h]
\centering
\includegraphics[width=90px]{imgs/gitlab_new_issue.png} \\
\includegraphics[width=150px]{imgs/gitlab_fill_issue.png}
\end{figure}
\end{minipage}
Une méthodologie de travail possible est de lister toutes les tâches à réaliser sous la forme d'issues. On peut aussi s'en servir pour faire remonter les bugs trouvés par les utilisateurs.
\end{frame}
\begin{frame}{Les issues - vision globale}
\includegraphics[width=\linewidth]{imgs/gitlab_issues.png}
\end{frame}
\begin{frame}[fragile]{Les issues - tableau}
Il est possible de gérer les issues sous une forme de tableau Kanban (ToDoList) :
\begin{figure}[h]
\centering
\includegraphics[scale=.2]{imgs/gitlab_issues_tableau.png}
\end{figure}
\verb+https://fr.wikipedia.org/wiki/Tableau_kanban+
\end{frame}
\begin{frame}{Les issues : gérer son projet}
Les issues ne sont pas seulement une façon de remonter des problèmes !
Elles peuvent également être utilisées pour gérer son projet :
\begin{itemize}
\item Chaque tâche identifiée est matérialisée par une issue ;
\item Les issues sont assignées à chaque collaborateur ;
\item Les issues peuvent servir d'espace de discussion sur les points de travail ;
\item Une fois les travaux terminés, les issues sont fermées.
\end{itemize}
\end{frame}
\begin{frame}{Les jalons}
Les jalons permettent de regrouper les issues et de visualiser l'avancée globale du projet.
\begin{figure}[h]
\centering
\includegraphics[scale=.3]{imgs/gitlab_milestones.png}
\end{figure}
A la fin du jalon, une \emph{merge request} (ça arrive juste après) peut être ouverte.
\end{frame}
\begin{frame}
\frametitle{Les merge request}
Les merge request permettent à des développeurs tiers (n'ayant pas d'accès en écriture au repo) de proposer leurs modifications. \\
Ils peuvent ainsi travailler sur une autre branche (voire une autre remote) puis demander aux propriétaires de merge leurs commits. \\
Certaines branches peuvent être \textbf{protégées}: seuls certains utilisateurs peuvent y écrire. \\
\end{frame}
\begin{frame}
\frametitle{Les merge request}
Pour faire une merge request, il suffit de sélectionner les deux branches dans l'interface graphique. Gitlab peut même prédir si le `git merge` fonctionnera automatiquement ou s'il y aura des conflits. \\
\begin{figure}[h]
\centering
\includegraphics[width=270px]{imgs/gitlab_branches.png} \\
\includegraphics[width=200px]{imgs/gitlab_merge_request.png} \\
\end{figure}
\end{frame}
\begin{frame}
\frametitle{Gestion des droits}
\framesubtitle{Visibilité}
Quand on crée un repo, on choisit sa visibilité. Il y en a 3 sur gitlab: Private, Internal et Public.
\includegraphics[width=220px]{imgs/gitlab_create_projet.png}
\end{frame}
\begin{frame}
\frametitle{Gestion des droits}
\framesubtitle{Rôles}
On peut ensuite ajouter des membres habilités à écrire dans le repo via l'onglet members. A l'UTC, on peut trouver des personnes par nom ou login CAS.\\
\includegraphics[width=220px]{imgs/gitlab_add_member.png} \\
Chaque membre a un rôle parmi les suivants :
\begin{itemize}
\item \textbf{Guest} : peut écrire des commentaires et des issues
\item \textbf{Reporter} : peut lire le code et modérer les commentaires et issues
\item \textbf{Developer} : peut créer des branches et y push du code.
\item \textbf{Maintainer} : peut gérer les branches
\item \textbf{Owner} : toutes les autres permissions
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Gestion des droits}
\framesubtitle{Groupes}
Les projets gitlab (c'est-à-dire les repos et les infos liées à ces repos) peuvent être rangées dans des groupes et des sous-groupes. Les groupes permettent de représenter des équipes de développeurs, de segmenter leurs droits, d'organiser les repo par thématique. \newline
Voici un extrait de l'arborescence de Picasoft: \\
\includegraphics[width=130px]{imgs/gitlab_groups_tree.png} \\
\end{frame}
\begin{frame}[fragile]
\frametitle{Organiser tout ça}
Il existe de nombreuses méthodes et modèles pour organiser tout ce joyeux bazar à base de branches, d'issues et de merge request. L'une d'entre elles est git flow.
Git flow est un workflow, un modèle définissant où stocker quelle information et dans quel ordre exécuter quelles tâches; mais c'est aussi un outil en ligne de commande qui permet d'accélérer la mise en place de ce workflow.
Il faut l'installer en plus de git. Sous debian et dérivées:
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
# apt update && apt -y install git-flow
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]
\frametitle{Le workflow}
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}
\Pause
\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}
\Pause
\begin{block}{bugfix}
Résolution d'un bug {\bf qui n'existe que sur develop}. Sera merge dans develop
\end{block}
\Pause
\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 fonctionne ?}
\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}
\begin{frame}[fragile]
\frametitle{En pratique}
\framesubtitle{init}
Tout commence par un \textbf{init}, à l'intérieur d'un repo. Appuyez sur entrée à chaque question, on reste sur les noms par défaut.
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
git flow init
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Hooks and filters directory? [./.git/hooks]
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]
\frametitle{En pratique}
\framesubtitle{Si vous êtes développeur: créer des features}
Pour créer une feature du nom de pigeon:
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
git flow feature start pigeon
Basculement sur la nouvelle branche 'feature/pigeon'
Summary of actions:
- A new branch 'feature/pigeon' was created, based on 'develop'
- You are now on branch 'feature/pigeon'
Now, start committing on your feature. When done, use:
git flow feature finish pigeon
\end{Verbatim}
\end{beamercolorbox}
Git flow a créé la branche feature/pigeon.
\end{frame}
\begin{frame}[fragile]
\frametitle{En pratique}
\framesubtitle{Si vous êtes peu de développeurs: merge des features}
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
git flow feature finish pigeon
Basculement sur la branche 'develop'
Déjà à jour.
Branche feature/pigeon supprimée (précédemment 83fb6b9).
Summary of actions:
- The feature branch 'feature/pigeon' was merged into 'develop'
- Feature branch 'feature/pigeon' has been locally deleted
- You are now on branch 'develop'
\end{Verbatim}
\end{beamercolorbox}
Git flow a merge la feature dans develop et a supprimé la branche feature/pigeon.
\end{frame}
\begin{frame}[fragile]
\frametitle{En pratique}
\framesubtitle{Si vous êtes une grande équipe: push des features}
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
git flow feature publish pigeon
\end{Verbatim}
\end{beamercolorbox}
Ceci va tout simplement push la branche feature/pigeon sur le serveur. On pourra éventuellement faire une merge request pour la mettre dans develop.
Pour pull les features des autres:
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
git flow feature pull origin pigeon
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}[fragile]
\frametitle{En pratique}
\framesubtitle{La release: pour les changements de dernière minute}
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
git flow release start pigeon2000
Basculement sur la nouvelle branche 'release/pigeon2000'
Summary of actions:
- A new branch 'release/pigeon2000' was created, based on 'develop'
- You are now on branch 'release/pigeon2000'
Follow-up actions:
- Bump the version number now!
- Start committing last-minute fixes in preparing your release
- When done, run:
git flow release finish 'pigeon2000'
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}
\frametitle{Résumé des comandes}
\input{src/tikz/commandes_gitFlow.tex}
\end{frame}
\subsection{Présentation}
\input{./src/tex/utilisation_remotes/presentation.tex}
\subsection{Récupérer du travail existant}
\input{./src/tex/utilisation_remotes/recuperer_travail.tex}
\subsection{Envoyer son travail}
\input{./src/tex/utilisation_remotes/envoyer_travail.tex}
\begin{frame}[fragile]
\frametitle{Pousser des commits}
\begin{block}{Explications}
{\bf Pousser} un ou plusieurs commits, c'est envoyer du travail local sur le serveur pour le partager/sauvegarder.
Cela se fait avec la commande \verb+git push+
\end{block}
\begin{beamercolorbox}[rounded=true, shadow=true]{terminal}
\begin{Verbatim}
$ cd .. \Pause
$ git clone git@gitlab.utc.fr:<mon_login>/<mon_repo> \Pause
[\ldots] \Pause
$ cd <mon_repo> \Pause
$ touch file && git add -A && git commit -m ''mon premier commit'' \Pause
[\ldots] \Pause
$ git push \Pause
Décompte des objets: 3, fait.
Delta compression using up to 8 threads.
Compression des objets: 100% (2/2), fait.
Écriture des objets: 100% (3/3), 939 bytes | 939.00 KiB/s, fait.
Total 3 (delta 1), reused 0 (delta 0)
To gitlab.utc.fr:<mon_login>/<mon_repo>
e32c9bf..4cf38e2 master -> master
\end{Verbatim}
\end{beamercolorbox}
\end{frame}
\begin{frame}
\frametitle{Le concept des remotes}
\begin{block}{Présentation}
Une \enquote{remote} est un dépôt git en ligne. Celui-ci se comporte comme un dépôt local, à part qu'il ne possède pas de \enquote{working directory}.
\end{block}
\begin{block}{Intérêt}
\begin{itemize}
\item Partage du dépôt git : on peut désormais travailler à plusieurs dessus
\item Sauvegarde du travail à distance
\end{itemize}
\end{block}
\end{frame}
\begin{frame}
\frametitle{Exemples de remotes}
\begin{minipage}[t]{.5\linewidth}
\begin{figure}[h]
\centering
\includegraphics[width=.5\linewidth]{imgs/github.jpeg}
\end{figure}
\end{minipage}%
\begin{minipage}[t]{.5\linewidth}
\begin{figure}[h]
\centering
\includegraphics[width=.5\linewidth]{imgs/gitlab.jpeg}
\end{figure}
\end{minipage}
\medskip
\centering
Mais surtout : \url{https://gitlab.utc.fr}
\end{frame}
\begin{frame}
\frametitle{Création d'un dépôt distant}
\begin{block}{Depuis le gitlab de l'utc}
Se rendre sur \url{https://gitlab.utc.fr}
Une fois connecté avec ses identifiants CAS, il suffit d'appuyer sur le bouton \enquote{New project} et de renseigner un nom et un niveau de visibilité
\end{block}
\begin{block}{Ajout de clé ssh}
Pour simplifier l'authentification au serveur, on ajoutera sa {\bf clé publique ssh} à son profil
\end{block}
\end{frame}