diff --git a/branchmerge.tex b/branchmerge.tex index 82cecc75d37ff8c907aeef649caa327a2a85f87a..0ac811cdd32b7b87eb9b8405527203a58411cea0 100644 --- a/branchmerge.tex +++ b/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} }