diff --git a/branchmerge.tex b/branchmerge.tex
index 964c3a911a59a288fccb2a77088f80b92823635c..8a888abff55509b0e46f4a7e80ccc50f756915d6 100644
--- a/branchmerge.tex
+++ b/branchmerge.tex
@@ -4,7 +4,7 @@
%======================================================================
-%\subsection{Introduction}
+\subsection{Introduction}
%======================================================================
diff --git a/branchreco.tex b/branchreco.tex
deleted file mode 100644
index adaafe900fcd88b6409fecf1761a76130abfd29a..0000000000000000000000000000000000000000
--- a/branchreco.tex
+++ /dev/null
@@ -1,76 +0,0 @@
-%======================================================================
-\section{Travail collaboratif}
-%======================================================================
-
-\input{collabowork}
-
-%======================================================================
-
-\subsection{Recommandations pour le travail collaboratif}
-
-%======================================================================
-
-\frame{\frametitle{Recommandations pour le travail collaboratif}
- \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 au minimum sur la branche
- \ex{master} de son propre dépôt
- \item
- La réconciliation du travail de ces différentes personnes se fait
- en fusionnant les branches \ex{master} correspondantes
- \item
- Plusieurs stratégies peuvent alors être mises en place pour
- effectuer cette fusion
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Recommandations pour le travail collaboratif}
- \begin{itemize}
- \item
- Pour envoyer son travail, la commande \ex{git push} permet
- d'envoyer les \emph{commits} créés vers le dépôt distant
- \item
- Pour récupérer les \emph{commits} des autres développeurs
- \begin{itemize}
- \item
- la stratégie la plus naturelle est d'utiliser la commande
- \ex{git pull}
- \item
- cette commande récupère les \emph{commits} et effectue un
- \ex{merge}, ce qui provoque la création d'un \ex{commit}
- représentant cette fusion
- \item
- pour éviter ce \emph{commit} supplémentaire, et ainsi améliorer
- la lisibilité de l'historique, \textbf{il est recommandé} de
- faire un \ex{git pull -{}-rebase}
- \end{itemize}
- \end{itemize}
-}
-
-%======================================================================
-
-\frame{\frametitle{Modèles de développement}
- \begin{itemize}
- \item
- Le modèle de développement expliqué dans ces transparents est
- celui basé sur le fait que la branche \ex{master} contient la
- version de production du développement
- \item
- Ce modèle est très proche de celui géré par des sites hébergeant
- des projets Git comme Github par exemple
- \item
- D'autres modèles de développement, comme gitflow, font un tout
- autre usage de la branche \ex{master} et prévoient au minimum 5
- branches dans tout développement
- \item
- gitflow est utilisé dans beaucoup de développements professionnels
- : \url{http://nvie.com/posts/a-successful-git-branching-model/}
- \end{itemize}
-}
-
-%======================================================================
diff --git a/branchusecase.tex b/branchusecase.tex
index ef79e4928259e26471c695936fc97d97a52e0780..fbb3153d4f303158df9ff7e3ad8a0a78fee63b80 100644
--- a/branchusecase.tex
+++ b/branchusecase.tex
@@ -4,23 +4,24 @@
%======================================================================
-%\subsection{Introduction}
+\subsection{Introduction}
%======================================================================
\frame{\frametitle{Introduction}
\begin{itemize}
\item
- En dehors des contextes pouvant présenter des problèmes (comme des
- \ex{rebase} sur des \emph{commits} déjà partagés), plusieurs
- stratégies peuvent être mise en \oe{}uvre
+ Plusieurs stratégies d'utilisation des commandes présentées
+ peuvent être mises en \oe{}uvre, en prenant toujours soin
+ d'exclure les contextes pouvant présenter des problèmes (comme des
+ \ex{rebase} sur des \emph{commits} déjà partagés)
\item
- Toutes ces stratégies sont techniquement correctes, elles mènent à
- un état final intégrant tous les \emph{commits} (branche dé départ
+ Plusieurs de ces stratégies techniquement correctes mènent à
+ un état final intégrant tous les \emph{commits} (branche de départ
/ référence et branche de nouvelle fonctionnalité)
\item
Cependant, les historiques obtenus varient en fonction de la
- stratégie suivie
+ stratégie suivie
\end{itemize}
}
@@ -29,8 +30,8 @@
\frame{\frametitle{Introduction}
\begin{itemize}
\item
- Afin de bien comprendre les particularités des différentes
- stratégies liées aux branches
+ Afin d'illustrer les particularités de différentes stratégies
+ liées aux branches, on se propose un scénario d'étude
\begin{enumerate}
\item
on part d'une situation initiale correspondant à un dépôt
@@ -116,9 +117,9 @@
\branchstrategie{Stratégie 1}
{
- \ex{git checkout master}\\
- \ex{git rebase nouvfonc}\\
- \ex{git branch -d nouvfonc}
+ \mygitplus{git checkout master}\\
+ \mygitplus{git rebase nouvfonc}\\
+ \mygitplus{git branch -d nouvfonc}
}
{strat1.png}
{
@@ -138,21 +139,19 @@
\branchstrategie{Stratégie 2}
{
- \ex{git checkout master}\\
- \ex{git merge nouvfonc}\\
- \ex{git branch -d nouvfonc}
+ \mygitplus{git checkout master}\\
+ \mygitplus{git merge nouvfonc}\\
+ \mygitplus{git branch -d nouvfonc}
}
{strat2.png}
{
\begin{itemize}
\item
- Les \emph{commits} de la nouvelle fonctionnalité sont alignés sur
- les \emph{commits} initiaux : la branche \ex{nouvfonc}, utilisée
- temporairement, ne ressort pas clairement
+ Dans cette stratégie, on utilise uniquement \ex{merge}
\item
- Le \ex{merge} fait l'objet d'un \emph{commit} (en haut de
- l'historique) : cela reflète la réalité, mais entrave un peu la
- lisibilité
+ Les \emph{commits} de la nouvelle fonctionnalité apparaissent
+ alignés sur les \emph{commits} initiaux : la branche
+ \ex{nouvfonc}, utilisée temporairement, ne ressort pas clairement
\end{itemize}
}
@@ -160,11 +159,11 @@
\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}
+ \mygitplus{git checkout nouvfonc}\\
+ \mygitplus{git rebase master}\\
+ \mygitplus{git checkout master}\\
+ \mygitplus{git merge nouvfonc}\\
+ \mygitplus{git branch -d nouvfonc}
}
{strat3.png}
{
@@ -184,11 +183,11 @@
\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}
+ \mygitplus{git checkout nouvfonc}\\
+ \mygitplus{git rebase master}\\
+ \mygitplus{git checkout master}\\
+ \mygitplus{git merge -{}-no-ff nouvfonc}\\
+ \mygitplus{git branch -d nouvfonc}
}
{strat4.png}
{
@@ -201,7 +200,8 @@
Git à choisir une stratégie de fusion différente de celle qu'il
aurait choisi par défaut
\item
- \textbf{C'est l'historique le plus lisible}
+ \textbf{C'est l'historique le plus lisible si on souhaite faire
+ ressortir la nouvelle fonctionnalité}
\end{itemize}
}
@@ -209,9 +209,9 @@
% \branchstrategie{Stratégie 5}
% {
-% \ex{git checkout master}\\
-% \ex{git merge nouvfonc -{}-no-ff}\\
-% \ex{git branch -d nouvfonc}
+% \mygitplus{git checkout master}\\
+% \mygitplus{git merge nouvfonc -{}-no-ff}\\
+% \mygitplus{git branch -d nouvfonc}
% }
% {strat5.png}
% {
@@ -229,11 +229,26 @@
%======================================================================
\frame{\frametitle{Synthèse}
+ \framesubtitle{Notes préliminaires}
\begin{itemize}
- \item
+ \item
Le choix d'une stratégie d'intégration des branches est libre,
chaque personne / équipe est libre d'opter pour la stratégie
qu'elle veut
+ \item
+ Il est généralement opportun de choisir une stratégie unique
+ pour un projet donné (à des fins d'uniformisation)
+ \item
+ Dans les stratégies 3 et 4, il peut naturellement y avoir
+ plusieurs \ex{rebase} pour absorber au fur et à mesure les
+ \emph{commits} de la version de base
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Synthèse}
+ \begin{itemize}
\item
La stratégie 4, plébiscitée par de nombreuses équipes, présente
l'avantage de faire ressortir clairement les \emph{commits} d'une
@@ -243,18 +258,32 @@
D'autres équipes considèrent que ce \emph{commit} supplémentaire
pollue l'historique, préfèrent avoir un historique «~plat~», et
optent pour la stratégie 3
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Synthèse}
+ \begin{itemize}
\item
- Les stratégies 1 et 2 restent possibles, mais engendrent
- potentiellement plus de conflits à la fusion
+ La stratégie 1 n'a pas de sens, on a pas intérêt à intégrer
+ progressivement une nouvelle fonctionnalité dans la version stable
+ (la branche \ex{master} dans ce modèle de développement)
+ \item
+ La stratégie 2 reste possible, mais engendrent potentiellement
+ plus de conflits à la fusion car il n'y a aucun \ex{rebase}
+ intermédiaire
\end{itemize}
}
%======================================================================
\frame{\frametitle{Recommandations}
+ \framesubtitle{Pour un développement individuel sur une nouvelle fonctionnalité}
\begin{itemize}
\item
- \emph{A priori}, il faut opter pour la stratégie 3 ou 4
+ \emph{A priori}, il faut choisir la stratégie 4 (éventuellement la
+ 3)
\item
En particulier, lors de l'insertion d'une nouvelle fonctionnalité
par une nouvelle branche, des \ex{rebase} réguliers à partir de la
@@ -279,3 +308,80 @@
\end{itemize}
}
+%======================================================================
+
+\frame{\frametitle{Recommandations}
+ \framesubtitle{Pour développement collaboratif}
+ \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 au minimum sur la branche
+ \ex{master} de son propre dépôt
+ \item
+ La réconciliation du travail de ces différentes personnes se fait
+ en fusionnant les branches \ex{master} correspondantes
+ \item
+ Plusieurs stratégies peuvent aussi être mises en place pour
+ effectuer cette fusion
+ \item
+ Mais il faut bien réaliser que ces différentes branches
+ \ex{master} correspondent en fait à une \textbf{unique} branche
+ (distribuée)
+ \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Recommandations}
+ \framesubtitle{Pour développement collaboratif}
+ \begin{itemize}
+ \item
+ Pour envoyer son travail, la commande \ex{git push} permet
+ d'envoyer les \emph{commits} créés vers le dépôt distant
+ \item
+ Pour récupérer les \emph{commits} des autres développeurs
+ \begin{itemize}
+ \item
+ la stratégie la plus naturelle est d'utiliser la commande
+ \ex{git pull}
+ \item
+ cette commande récupère les \emph{commits} et effectue un
+ \ex{merge}, ce qui provoque la création d'un \ex{commit}
+ représentant cette fusion
+ \item
+ pour éviter ce \emph{commit} supplémentaire, et ainsi améliorer
+ la lisibilité de l'historique, \textbf{il est recommandé} de
+ faire un \ex{git pull -{}-rebase}\\
+% (il n'y a pas de fonctionnalité à faire ressortir)
+ \end{itemize}
+ \end{itemize}
+}
+
+%======================================================================
+
+\subsection{Modèles de développement}
+
+%======================================================================
+
+\frame{\frametitle{Modèles de développement}
+ \begin{itemize}
+ \item
+ Le modèle de développement expliqué dans ces transparents est
+ celui basé sur le fait que la branche \ex{master} contient la
+ version de production du développement
+ \item
+ Ce modèle est très proche de celui géré par des sites hébergeant
+ des projets Git comme Github par exemple
+ \item
+ D'autres modèles de développement, comme gitflow, font un tout
+ autre usage de la branche \ex{master} et prévoient au minimum 5
+ branches dans tout développement
+ \item
+ gitflow est utilisé dans beaucoup de développements professionnels
+ : \url{http://nvie.com/posts/a-successful-git-branching-model/}
+ \end{itemize}
+}
+
+%======================================================================
diff --git a/gitbranch.tex b/gitbranch.tex
index f1176066d12c8f2a412fac6d1ded5565362da850..c7f6bf4a611af068bb59431bcbb24c15590dff5f 100644
--- a/gitbranch.tex
+++ b/gitbranch.tex
@@ -35,7 +35,6 @@
\input{brancheintro}
\input{branchmerge}
\input{branchusecase}
-\input{branchreco}
% Idées d'amélioration suite à la première présentation
% =====================================================