Skip to content
Snippets Groups Projects
Commit fdc9901d authored by Philippe Dosch's avatar Philippe Dosch
Browse files

Merge branch 'branching', refactoring about branches handle under git

parents f8b642df ed5943a9
No related branches found
No related tags found
No related merge requests found
Expand all Hide whitespace changes
Inline Side-by-side
arbre.obj
+ 12
− 6
View file @ fdc9901d
......@@ -168,11 +168,17 @@ poly('Black','',2,[
]).
oval('#ff3333','',590,90,850,340,0,3,1,72,2,0,0,0,0,'3',0,[
]).
text('Black',590,346,1,0,1,265,29,73,24,5,0,0,0,0,-65534,265,29,0,0,"",0,0,0,0,370,'',[
minilines(265,29,0,0,0,0,0,[
mini_line(265,24,5,0,0,0,[
str_block(0,265,24,5,0,-1,0,0,0,[
str_seg('Black','Helvetica-Bold',1,138240,265,24,5,0,-1,0,0,0,0,0,
"Dernier commit r\351alis\351")])
text('Black',590,346,1,0,1,259,29,73,24,5,0,0,0,0,-65534,259,29,0,2,"",0,0,0,0,370,'',[
minilines(259,29,0,2,0,0,0,[
mini_line(259,24,5,0,2,0,[
str_block(0,95,24,5,0,-5,0,0,0,[
str_seg('Black','Helvetica-Bold',1,138240,95,24,5,0,-5,0,0,0,0,0,
"Dernier ")]),
str_block(0,79,24,5,0,2,0,0,0,[
str_seg('Black','Helvetica-Oblique',2,138240,79,24,5,0,2,0,0,0,0,0,
"commit")]),
str_block(0,85,24,5,0,-1,0,0,0,[
str_seg('Black','Helvetica-Bold',1,138240,85,24,5,0,-1,0,0,0,0,0,
" r\351alis\351")])
])
])]).
brancheintro.tex
+ 60
− 38
View file @ fdc9901d
......@@ -12,16 +12,16 @@
\begin{itemize}
\item
La manipulation des branches est certainement une des
fonctionnalités les plus puissantes sous git
fonctionnalités les plus puissantes sous Git
\item
Elle est particulièrement simple et rapide par rapport aux autres
VCS, où les branches sont généralement difficiles à gérer
\item
Sous git, la création d'une branche est un processus léger, ce qui
Sous Git, la création d'une branche est un processus léger, ce qui
encourage son utilisation
\item
Une \emph{branche} représente une partie de l'arborescence
créée par les différents commits contenus dans un dépôt
créée par les différents \emph{commits} contenus dans un dépôt
\end{itemize}
}
......@@ -30,11 +30,12 @@
\frame{\frametitle{Représentation arborescente}
\begin{itemize}
\item
Chaque commit créé possède au moins un père : le commit dont il
est issu
Chaque \emph{commit} créé possède au moins un père : le
\emph{commit} dont il est issu (hormis le premier \emph{commit}
naturellement)
\item
Il existe ainsi une filiation entre les différents commits d'un
dépôt, représentée sous forme d'arbre
Il existe ainsi une filiation entre les différents \emph{commits}
d'un dépôt, représentée sous forme d'arbre
\end{itemize}
\begin{center}
\includegraphics[scale=.4]{arbre.eps}
......@@ -43,14 +44,15 @@
%======================================================================
\frame{\frametitle{Branche \ext{master}}
\frame{\frametitle{Branches et branche \ext{master}}
\begin{itemize}
\item
Rappel : la création d'un dépôt git entraîne automatiquement la
Rappel : la création d'un dépôt Git entraîne automatiquement la
création d'une branche par défaut, appelée \ex{master}
\item
Techniquement, cette branche correspond à une variable \ex{master}
pointant toujours vers le dernier commit réalisé
Techniquement, une branche est représentée par une variable
pointant \textbf{toujours} vers le dernier \emph{commit} réalisé
dans cette branche
\end{itemize}
\begin{center}
\includegraphics[scale=.4]{arbremaster.eps}
......@@ -68,7 +70,7 @@
\item
Il est possible de créer de nouvelles branches pour faire évoluer,
\textit{simultanément}, le développement dans des directions
différentes pour permettre, entre autres
différentes pour, entre autres,
\begin{itemize}
\item
un développement collaboratif (= plusieurs développeurs)
......@@ -127,11 +129,12 @@
\frame{\frametitle{Le pointeur \ext{HEAD}}
\begin{itemize}
\item
Pour savoir dans quelle branche le dépôt se situe, git utilise un
pointeur spécial appelé \ex{HEAD}
Pour savoir où greffer le prochain \emph{commit}, Git utilise un
pointeur spécial appelé \ex{HEAD}, pointant vers un \emph{commit}
de référence
\item
Cette variable pointe toujours vers (le dernier commit de) la
branche courante
\ex{HEAD} pointe \emph{généralement} vers (le dernier \emph{commit}
de) la branche courante
\end{itemize}
\begin{center}
\includegraphics[scale=.4]{arbrehead.eps}
......@@ -152,7 +155,7 @@
\end{codebox}
\end{minipage}
\end{itemize}
\vspace*{-1.5cm}
\vspace*{-1.0cm}
\begin{center}
\includegraphics[scale=.4]{arbrehead2.eps}
\end{center}
......@@ -160,28 +163,11 @@
%======================================================================
\frame{\frametitle{Passage d'une branche à une autre}
\framesubtitle{Aspects techniques}
\begin{itemize}
\item
Lors du passage d'une branche à une autre, git restaure le
répertoire de travail dans l'état correspondant à la branche
sélectionnée (uniquement pour les fichiers suivis par git)
\item
Attention : on ne peut pas changer de branche s'il reste
des modifications en attente dans le répertoire de travail ou dans
l'index (ces deux niveaux de stockage sont communs à toutes les
branches)
\end{itemize}
}
%======================================================================
\frame{\frametitle{Passage d'une branche à une autre}
\framesubtitle{Ajout de \emph{commits}}
\begin{itemize}
\item
Les nouveaux \emph{commits} sont ajoutés à la branche courante
Les nouveaux \emph{commits} sont ajoutés au niveau de \ex{HEAD}
\begin{codebox}
\mygitplus{git commit ...}
\end{codebox}
......@@ -198,6 +184,41 @@
%======================================================================
\frame{\frametitle{Remarques sur \ext{checkout}}
\begin{itemize}
\item
Techniquement, la commande \ex{git checkout} n'est pas limitée aux
branches : elle accepte n'importe quel \emph{commit} en paramètre
\item
Son premier impact est de déplacer le pointeur \ex{HEAD}
\item
Ainsi, si le paramètre reçu correspond à une branche, elle
provoque le changement de branche
\item
Dans le cas contraire, \ex{HEAD} ne correspond à aucune tête de
branche : on parle alors de \emph{tête détachée}
\end{itemize}
}
%======================================================================
\frame{\frametitle{Passage d'une branche à une autre}
\framesubtitle{Aspects techniques}
\begin{itemize}
\item
Lors du passage d'une branche à une autre, Git restaure le
répertoire de travail dans l'état correspondant à la branche
sélectionnée (uniquement pour les fichiers suivis par Git)
\item
Attention : on ne peut pas changer de branche s'il reste
des modifications en attente dans le répertoire de travail ou dans
l'index (ces deux niveaux de stockage sont communs à toutes les
branches)
\end{itemize}
}
%======================================================================
\frame{\frametitle{Autres commandes liées aux branches}
\begin{itemize}
\item
......@@ -217,9 +238,10 @@
\begin{itemize}
\item
Pour supprimer une branche, qui doit avoir été fusionnée au
préalable (utiliser le flag \ex{-D} au lieu de \ex{-d} pour
forcer la suppression)\\
\ex{git branch -d \emph{branche}}
préalable\\
\ex{git branch -d \emph{branche}}\\
(utiliser le flag \ex{-D} au lieu de \ex{-d} pour forcer la
suppression)
\item
Liste des branches dont les apports n'ont pas encore été
fusionnés\\
......
branchmerge.tex
+ 41
− 34
View file @ fdc9901d
%======================================================================
\section{Fusion de branches}
\section{Réconciliation de branches}
%======================================================================
%\subsection{Introduction}
\subsection{Introduction}
%======================================================================
......@@ -27,17 +27,17 @@
\frame{\frametitle{Introduction}
\begin{itemize}
\item
À ce stage, il est nécessaire de fusionner les deux branches
À ce stage, il est nécessaire de réconcilier les deux branches
\item
Il existe plusieurs commandes permettant d'obtenir la fusion
Il existe plusieurs commandes permettant d'obtenir le résultat
souhaitée
\begin{itemize}
\item
la commande \ex{git merge}, réalisant effectivement une fusion
des branches concernées
la commande \ex{git merge}, réalisant une fusion des branches
concernées
\item
la commande \ex{git rebase}, permettant de réécrire l'historique
et d'obtenir un résultat différent, mais proche
et d'obtenir un résultat similaire, mais différent
\end{itemize}
\end{itemize}
}
......@@ -51,8 +51,8 @@
\frame{\frametitle{Introduction}
\begin{itemize}
\item
C'est la commande la plus naturelle à utiliser pour effectuer une
fusion
La commande \ex{git merge} effectue une \emph{fusion}, l'opération
la plus naturelle à réaliser pour réconcilier les branches
\item
Sur le principe, quelques étapes sont nécessaires pour sa mise en
\oe{}uvre
......@@ -100,11 +100,11 @@
disponibilité de plusieurs algorithmes choisis suivant la
configuration de départ
\item
Suivant ces configurations, une fusion peut occasionner
Suivant cette configuration, une fusion peut occasionner
\begin{itemize}
\item
un simple déplacement du pointeur représentant une branche
(typiquement si la branche de base n'a pas été modifiée)
(typiquement si l'une des branches n'a pas été modifiée)
\item
la création d'un nouveau \emph{commit} (s'il y a eu des
modifications sur les 2 branches)
......@@ -128,6 +128,8 @@
\item
Un des usages fait de cette commande est de garder une nouvelle
branche synchronisée avec la branche dont elle est issue
(permettant ainsi de cumuler les \emph{commits} réalisés dans les
deux branches)
\end{itemize}
}
......@@ -136,17 +138,13 @@
\frame{\frametitle{Une alternative à la fusion}
\begin{itemize}
\item
Pour assurer cette synchronisation
\begin{itemize}
\item
la commande \ex{rebase} est doit être appliquée régulièrement
pour que la nouvelle branche « profite » aussi des
\emph{commits} réalisés dans la branche de départ
\item
la fusion finale est généralement facilitée, la synchronisation
régulière permettant de régler les éventuels conflits au fur et
à mesure
\end{itemize}
Pour assurer cette synchronisation, la commande \ex{rebase} doit
être appliquée régulièrement pour que la nouvelle branche
«~profite~» aussi des \emph{commits} réalisés dans la branche de
départ
\item
La fusion finale est facilitée, la synchronisation régulière
permettant de régler les éventuels conflits au fur et à mesure
\end{itemize}
}
......@@ -158,8 +156,8 @@
La commande \ex{rebase}
\begin{enumerate}
\item
cherche l'ancêtre commun aux deux branches considérées~: ce sera
le premier \emph{commit} à réécrire
cherche l'ancêtre commun aux deux branches considérées~: c'est à
partir de cet ancêtre que les \emph{commits} seront réécrits
\item
réécrit chacun des commits de la nouvelle branche pour qu'ils ne
soient plus relatifs à l'ancêtre commun mais au dernier commit
......@@ -204,7 +202,7 @@
\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 +
l'intégralité des \emph{commits} réalisés (branche de départ +
nouvelle fonctionnalité)
\item
après un \ex{rebase}, c'est la nouvelle branche qui contient
......@@ -223,8 +221,9 @@
\begin{itemize}
\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
\ex{rebase} fait que tous les \emph{commits} initiaux de la
nouvelle branche sont réécrits, et qu'ils changent donc de SHA-1
en particulier
\item
Les anciens \emph{commits} n'existent donc plus, ce qui pose
problème si
......@@ -248,7 +247,7 @@
\item
Ainsi, \ex{rebase} ne pose aucun problème dans les situations où,
typiquement
\begin{itemize}
\begin{enumerate}
\item
une nouvelle branche est définie pour implanter une nouvelle
fonctionnalité
......@@ -256,7 +255,7 @@
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{enumerate}
\end{itemize}
}
......@@ -265,12 +264,20 @@
\frame{\frametitle{Conclusion}
\begin{itemize}
\item
Généralement, les branches sont utilisées localement par un
développeur pour implanter une nouvelle fonctionnalité, corriger
un bug, etc.
Généralement, les nouvelles 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
D'ailleurs, le comportement par défaut de Git est maintenant de ne
synchroniser que la branche récupérée au moment du clonage (un
\ex{push} ne considère donc pas les nouvelles branches locales)
\end{itemize}
}
%======================================================================
\frame{\frametitle{Conclusion}
\begin{itemize}
\item
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
......
branchreco.tex deleted 100644 → 0
+ 0
− 76
View file @ f8b642df
%======================================================================
\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}
}
%======================================================================
branchusecase.tex
+ 145
− 39
View file @ fdc9901d
......@@ -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}
}
%======================================================================
git-asrall.tex deleted 100644 → 0
+ 0
− 955
View file @ f8b642df
This diff is collapsed.
git-cmm.tex deleted 100644 → 0
+ 0
− 1419
View file @ f8b642df
This diff is collapsed.
gitbranch.tex
+ 3
− 4
View file @ fdc9901d
\documentclass{IutSlideBeamerNew}
\title{Git}
\title[Git, gestion de branches]{Git}
\subtitle{Gestion des branches}
\date{7 février 2014}
\date{4 avril 2014}
\AtBeginSubsection[]
{
......@@ -35,12 +35,11 @@
\input{brancheintro}
\input{branchmerge}
\input{branchusecase}
\input{branchreco}
% Idées d'amélioration suite à la première présentation
% =====================================================
% - Faire une transparent, placé au début des usecase et à la fin en
% - Faire un transparent, placé au début des usecase et à la fin en
% guise de synthèse /récapitulatif, reprenant le scénario 4 + le git
% pull --rebase
% - Expliquer pour le travail collaboratif que l'on traite plusieurs
......
redmineiut.tex
+ 1
− 1
View file @ fdc9901d
......@@ -121,7 +121,7 @@
\item
un wiki (pour y gérer la documentation interne)
\item
...et un dépôt git !
...et un dépôt Git !
\end{itemize}
\item
Les projets Redmine sont à créer à l'initiative d'un des membres
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment