Commit c2e4862b authored by Remy Huet's avatar Remy Huet

Merge branch 'collabGitlab' into 'master'

Collab gitlab

See merge request !6
parents e3bd8e7b 1804aaac
Pipeline #33727 passed with stages
in 59 seconds
24 janvier 2019
Rémy Huet (remy.huet@etu.utc.fr), Thibaud Duhautbout (thibaud@duhautbout.ovh), Quentin Duchemin (quentinduchemin@tuta.io), Association Picasoft (picasoft@assos.utc.fr)
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
......
......@@ -11,32 +11,33 @@ Les sections sont numérotés en niveau 1. Les sous-sections en niveau 2. Une in
1. Introduction
* Qu'est ce que git ?
* Pourquoi la gestion de version ?
* Différents logiciels de gestion de version
* Petite histoire de Git
* 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
* Création d'un dépôt Git
* Configuration locale / configuration globale
* 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
* Explications
* Schéma
* Fonctionnement de Git
* OK - Explications
3. Gestion linéaire en pratique
* Créer des versions
* Working directory <-> staging area
* Staging area <-> repository
* Dissection d'un commit
* OK - Working directory <-> staging area
* OK - Exemples
* OK - Staging area <-> repository
* OK - Dissection d'un commit
* Visualiser les différences
* Git log
* Git diff
* Git show
* OK - Git log
* OK - Git diff
* OK - Git show
3. Utiliser les versions
1. Le HEAD
......@@ -67,24 +68,25 @@ Les sections sont numérotés en niveau 1. Les sous-sections en niveau 2. Une in
3. Envoyer son travail
* Pousser des commits
5. Gestion non linéaire
5. Gestion non linéaire [branche gestion_non_lineaire non mergée]
1. Explications théoriques
* Principe de gestion non linéaire
* OK - Principe de gestion non linéaire
* Création d'une divergence
* Comment créer une divergence
* Explications
* Illustrations / Exemple
* Fusion
* 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
* Gestion des branches
* Changer de branche
* Visualisation
* OK - Gestion des branches
* OK - Changer de branche
* OK - Visualisation
3. Fusionner des branches
* Le merge
* OK - Le merge
* Le rebase
* Avertissement
* Comparaison avec le merge
* Application simple
* OK - Avertissement
* OK - Comparaison avec le merge
* OK - Application simple
* Rebase interactif
* Le cherry-pick
......
......@@ -13,7 +13,7 @@
\usepackage{xcolor}
\usepackage{tikz}
\hypersetup{
pdfauthor={Rémy Huet, Thibaud Duhautbout, Quentin Duchemin},
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},
......@@ -38,8 +38,9 @@ pdfproducer={Latex},
\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[R. Huet, T. Duhautbout, Q. Duchemin]{%
\phantom{x}\hfill Rémy {\sc Huet} \hfill Thibaud {\sc Duhautbout} \hfill Quentin \textsc{Duchemin} \hfill \phantom{x}}
\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[24/01/2019]{Jeudi 24 janvier 2018}
......@@ -85,6 +86,6 @@ pdfproducer={Latex},
\input{./src/tex/resolution_conflits.tex}
\section{Travail collaboratif avec Git et GitLab}
\input{./src/tex/tavail_collaboratif.tex}
\input{./src/tex/travail_collaboratif.tex}
\end{document}
\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}
\begin{tikzpicture}[thick,scale=0.4, every node/.style={transform shape}]
% argument 1 : flow
\node at (5,-6.5) [font=\sffamily] {\Huge git flow};
% argument 2
% feature/release/hotfix
\filldraw [fill=white, draw=black, thick] (10,-3) rectangle (14,-4);
\filldraw [fill=white, draw=black, thick] (10,-4) rectangle (14,-5);
\filldraw [fill=white, draw=black, thick] (10,-5) rectangle (14,-6);
\node at (11.5,-3.5) [font=\sffamily] {\Huge feature};
\node at (11.5,-4.5) [font=\sffamily] {\Huge release};
\node at (11.5,-5.5) [font=\sffamily] {\Huge hotfix};
% init
\node at (11.5,-7.5) [font=\sffamily] {\Huge init};
% argument 3 : start/finish/publish/pull
\filldraw [fill=white, draw=black, thick] (16,-3) rectangle (20,-4);
\filldraw [fill=white, draw=black, thick] (16,-4) rectangle (20,-5);
\filldraw [fill=white, draw=black, thick] (16,-5) rectangle (20,-6);
\filldraw [fill=white, draw=black, thick] (16,-6) rectangle (20,-7);
\node at (17.5,-3.5) [font=\sffamily] {\Huge start};
\node at (17.5,-4.5) [font=\sffamily] {\Huge finish};
\node at (17.5,-5.5) [font=\sffamily] {\Huge publish};
\node at (17.5,-6.5) [font=\sffamily] {\Huge pull};
% argument 4 : name
\node at (22,-4.5) [font=\sffamily] {\Huge name};
% lignes
\draw [thick] (6.5,-6.5) -- (10,-4.5);
\draw [thick] (6.5,-6.5) -- (10,-7.5);
\draw [thick] (14,-4.5) -- (16,-4.5);
\draw [thick] (20,-4.5) -- (21,-4.5);
\end{tikzpicture}
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment