Finalizes the merge / rebase comparaison

branchmerge.tex

@@ -221,53 +221,63 @@
 
 \frame{\frametitle{\texttt{rebase} \emph{vs} \texttt{merge}}
   \begin{itemize}
-  \item 
-    Remarques
-    \begin{itemize}
-    \item
-      après un \ex{merge}, c'est la branche de départ qui contient
-      l'intégralité des \emph{commits} réalisés (branche de base +
-      nouvelle fonctionnalité)
-    \item 
-      après un \ex{rebase}, c'est la nouvelle branche qui contient
-      l'intégralité des \emph{commits} réalisés
-    \end{itemize}
-  \item
-    On peut donc se demander s'il est préférable d'utiliser l'une ou
-    l'autre des commandes ou si certains environnements conditionnent
-    l'usage de l'une ou de l'autre des commandes
   \item
     Il faut bien comprendre que le processus de réécriture de
     \ex{rebase} fait que tous les \emph{commits} initiaux sont
     réécrits, et qu'ils changent donc de SHA-1 en particulier
   \item
-    Pose des problèmes comme ceux de la page 172-173 -> synthétiser et
-    expliquer
+    Les anciens \emph{commits} n'existent donc plus, ce qui pose
+    problème si
+    \begin{itemize}
+    \item
+      d'autres branches sont basées sur ces \emph{commits}
+    \item
+      ces \emph{commits} ont déjà été partagés (\emph{via} un
+      \ex{push}) vers des dépôt distants
+    \end{itemize}
   \end{itemize}
 }
 
 %======================================================================
 
-\frame{\frametitle{\ex{rebase} : la suite}
+\frame{\frametitle{\texttt{rebase} \emph{vs} \texttt{merge}}
   \begin{itemize}
   \item
-    Compléter avec http://git-scm.com/book/fr/Les-branches-avec-Git-Rebaser
+    Mais il faut également bien comprendre que la réécriture ne
+    concerne que les \emph{commits} de la nouvelle branche
   \item
-    Expliquer le fonctionnement en 2 phases, un peu comme avec merge
-    (branche départ + commande)
-  \item
-    Le rebase rend linéaire les commits qui apparaissent clairement
-    dans une branche différente avec un merge
+    Ainsi, \ex{rebase} ne pose aucun problème dans les situations où,
+    typiquement
+    \begin{itemize}
+    \item
+      une nouvelle branche est définie pour implanter une nouvelle
+      fonctionnalité
+    \item
+      cette nouvelle branche reste locale à un utilisateur et n'est
+      pas partagée tant que la nouvelle fonctionnalité n'est pas
+      finalisée et n'est pas fusionnée avec un \ex{merge} 
+    \end{itemize}
+  \end{itemize}
+}
+
+%======================================================================
+
+\frame{\frametitle{Conclusion}
+  \begin{itemize}
   \item 
-    ne pas rebaser des commits qui ont été poussés sur un dépôt
-    publics : si les branches dont sont issues les commits sont
-    locales, il n'y a pas de problème + préciser dans la présentation
-    des branches qu'elles sont locales par défaut et qu'elles ont
-    souvent vocation à le rester
+    Généralement, les branches sont utilisées localement par un
+    développeur pour implanter une nouvelle fonctionnalité, corriger
+    un bug, etc.
+  \item
+    C'est d'ailleurs le comportement par défaut de Git concernant les
+    branches
   \item
-    Conclusion locale à rebase + lien vers la partie suivante
-    présentant les différentes stratégies qu'on peut adopter à partir
-    de ces deux commandes
+    Les \ex{rebase}, utilisés régulièrement, permettent de récupérer
+    tous les \emph{commits} ajoutés à la branche de départ et de
+    «~désamorcer~» les conflits potentiels au fur et à mesure
+  \item 
+    Dans ce contexte, utiliser la commande \ex{rebase} est donc une
+    bonne pratique
   \end{itemize}
 }