Commit 721f02ce authored by Grégory Mounié's avatar Grégory Mounié
Browse files

computer lab alpha

parent 370c4ecd
......@@ -283,126 +283,129 @@ Check that HEAD points on the right commit of the \texttt{master} branch.
And now merge the \texttt{develop} branch in master.
\begin{minted}{console}
git merge develop
$ git merge develop
\end{minted}
Check that the commit has two parents and the all the three trees
point to the same file.
\section{Git perd la tête~?}
\section{Headless Git}
Dans cette section, nous allons comprendre comment un dépôt peut se
retrouver dans une situation de «~tête détachée~» et pourquoi il
convient de prendre ses précautions dans ce cas-là.
This section discuss about ``detached head'': why do you pass in this
state, and what to do to avoid trouble.
\subsection{Reprendre le travail depuis un commit antérieur}
\subsection{Get the work directory state of a previous commit}
\label{sec:headless}
Récupérez l'identifiant du commit correspondant à la branche
\texttt{develop}. On peut par exemple utiliser~:
Get the SHA-1 value of the last commit of \texttt{develop} using the
following command:
\begin{minted}{console}
git show develop
$ git show develop
\end{minted}
Notez l'identifiant du commit, et récupérez (\texttt{checkout}) les
données de ce commit~:
Get the working directory related to this commit (\texttt{checkout})~:
\begin{minted}{console}
git checkout <numéro-du-commit>
$ git checkout <SHA-1 commit>
\end{minted}
Normalement, Git doit vous avertir que vous passez en état «~tête
détachée~», mais c'est simplement un avertissement.
Git should warn you about a ``detached head'' state.
Créez un nouveau fichier et faites un commit~:
Create a new file and register it with a new commit:
\begin{minted}{console}
mon_editeur_prefere fichier3.txt # inserer quelques lignes
git add fichier3.txt
git commit -m "message détaché 1"
$ emacs file3.txt # insert few lines
$ git add file3.txt
$ git commit -m "detached head message 1"
\end{minted}
Vérifiez que votre commit est bien dans le journal des révisions~:
Check that the commit is fully known by Git:
\begin{minted}{console}
git log --graph --oneline
$ git log --graph --oneline
\end{minted}
Notez mentalement le numéro de commit. Revenez à la branche master et
regardez le journal des révisions~:
Note well this commit number and then move to the \texttt{master}
branch:
\begin{minted}{console}
git checkout master
git log --graph --oneline
$ git checkout master
$ git log --graph --oneline
\end{minted}
Mais où est donc passé le commit dans lequel vous aviez ajouté le
fichier \texttt{fichier3.txt}~? Il n'est référencé par aucune branche,
donc inaccessible, sauf si l'on connaît précisément son identifiant
(ou alors si l'on fait une recherche exhaustive dans les fichiers du
dépôt).
But now, where is the commit with \texttt{file3.txt}? No branch
references it. Unless you remember the SHA-1, you may have to dig into
the logs:
\begin{itemize}
\item look into HEAD history (\texttt{logs/refs/HEAD}) for the title
of the commit
\item if you know some ``exclusive'' content of the commit, look into
the whole set of file content by using the full list of revision and
\mintinline{console}{git-grep}:
\begin{minted}{console}
$ git rev-list --all | xargs git grep <PATTERN>
\end{minted}
\item do a full search in the blob list, excluding, first, those
already in some branches.
\end{itemize}
Dans un dépôt Git, les seuls fichiers visibles facilement sont les
fichiers qui sont des ancêtres d'un point d'entrée de l'arbre des
révisions, ces points d'entrée étant~:
In a Git repository, the only easily visible files are in the ancestor
commits of a entry point:
\begin{itemize}
\item des branches~;
\item des tags~;
\item le pointeur \texttt{HEAD} (la tête).
\item branches;
\item tags;
\item \texttt{HEAD}.
\end{itemize}
Nous allons rendre notre commit visible en la fusionnant dans
la branche \texttt{develop}~:
Hopefully, you remember fully the SHA-1 and thus it is much easier to
manage. Two non-exclusive example methods follows.
First, merge the commit in the \texttt{develop} branch:
\begin{minted}{console}
git checkout develop
git merge <numéro-du-commit> # le numéro est celui du commit
# dans lequel on a créé fichier3.txt
$ git checkout develop
$ git merge <commit SHA-1> # commit with file3.txt
\end{minted}
Une autre solution possible était de créer une nouvelle branche
directement à partir de ce numéro de commit, avec%
\mintinline{bash}{git branch <nouvelle-branche> <numéro-du-commit>}.
Second, create a new branch with the commit number.
\mintinline{console}{$ git branch <BRANCH NAME> <commit SHA-1>}.
\subsection{Reprendre le travail depuis une branche antérieure}
\subsection{Working with another branch}
Revenez sur la branche master~:
Come back to the \texttt{master}:
\begin{minted}{console}
git checkout master
$ git checkout master
\end{minted}
Nous allons maintenant effectuer les mêmes opérations mais en
repartant de la branche \texttt{develop}, et non de son commit
associé.
Redo the same manipulation as in subsection \ref{sec:headless}, but
using the branch name \texttt{develop} instead of the commit number of
the branch.
\begin{minted}{console}
git checkout develop
mon_editeur_prefere fichier3.txt # inserer quelques lignes
git add fichier3.txt
git commit -m "message dev2"
git checkout master
$ git checkout develop
$ emacs file3.txt # insert few lines
$ git add file3.txt
$ git commit -m "message dev2"
$ git checkout master
\end{minted}
Revenez sur la branche \texttt{develop} et vérifiez que rien n'est
perdu~:
Comme back to \texttt{develop} and check that the commit is there:
\begin{minted}{console}
git checkout develop
git log --graph --oneline
\end{minted}
C'est normal. Lorsque l'on travaille à partir d'une branche, le
pointeur de la branche avance avec la tête. Lorsque l'on change de
branche, nos commits ne sont pas perdus.
The pointer of the branch follows HEAD and advances with it. It is
much easier to change HEAD for another branch without loosing any
commit.
\subsection{And with the tags?}
\subsection{Et les tags, dans tout ça~?}
If you come back to the tag \texttt{v0.1} from section~\ref{sec:tags},
are you in a detached head state, or not ? Why ?
Revenez au tag \texttt{v0.1} créé dans la section~\ref{sec:tags}. À
votre avis, êtes-vous en situation de tête détachée (comme si vous
aviez récupéré un numéro de commit), ou pas~? Pourquoi~?
Try and check !
\section{Pour conclure\dots{}}
\section{Conclusion\dots{}}
À l'issue de ce TP, vous devriez avoir une compréhension détaillée des
structures de données sous-jacentes au stockage de l'historique d'un
dépôt. C'est un graphe orienté, avec un certain nombre de points
d'entrées. La plupart des commandes de Git servent soit à créer de
nouveaux nœuds dans le graphe, soit à créer de nouveaux points
d'entrée, soit à naviguer. Si vous avez compris cela, vous avez tout
compris.
Git data storage is addressable by content. The link between files are
a direct acyclic graph, with several source (entry points). Most Git
commands create new nodes, new sources or navigate in the graphe.
\end{document}
......
Supports Markdown
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