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

merge and conflict

parent 2054355b
......@@ -470,7 +470,7 @@ extract it and add it to the Git history.
% puis le décompresse et l'ajoute au dépôt local git~:
\begin{minted}{console}
alice@laptop1$ wget https://ensiwiki.ensimag.fr/index.php/Fichier:Sandbox.tar.gz
alice@laptop1$ wget https://ensiwiki.ensimag.fr/images/8/86/Sandbox.tar.gz
alice@laptop1$ cd ~/project1/
alice@laptop1$ tar xzvf ../Fichier:Sandbox.tar.gz
alice@laptop1$ git status
......@@ -652,26 +652,30 @@ The "commit" will be published to any user in the next section.
% On va maintenant mettre ce « commit » à disposition des
% autres utilisateurs.
More on commit in \href{https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository}{Chapter 2.2}
\subsection{Merge}
SEULEMENT {\em Bob} fait~:
First, \textbf{ONLY} {\em Bob} publishes its commit~:
\begin{minted}{console}
bob@laptop2$ git push # Envoyer les commits locaux dans
# le dépôt partagé
bob@laptop2$ git push # send the Bob commit to shared repository
\end{minted}
Pour voir où on en est, les deux équipes peuvent lancer la commande~:
{\em Alice} and {\em Bob} should follow change in the local history:
%Pour voir où on en est, les deux équipes peuvent lancer la commande~:
\begin{minted}{bash}
gitk # afficher l'historique sous forme graphique
gitk # graphical history
\end{minted}
ou bien
or with
\begin{minted}{bash}
git log # afficher l'historique sous forme textuelle.
git log # textual history.
\end{minted}
À PRESENT, {\em Alice} peut tenter d'envoyer ses modifications~:
Second, {\em Alice} attempts to publish her modifications~:
\begin{minted}{console}
alice@laptop1$ git push
\end{minted}
On voit apparaître~:
The publication should failed~:
\begin{verbatim}
To ssh://git@gitlab.ensimag.fr/alice_bob/project1.git
! [rejected] master -> master (non-fast forward)
......@@ -682,29 +686,38 @@ Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
\end{verbatim}
L'expression « non-fast-forward » (qu'on pourrait traduire par « absence
d'avance rapide ») veut dire qu'il y a des modifications dans le dépôt
vers lequel on veut envoyer nos modifications et que nous n'avons
pas encore récupérées. Il faut donc fusionner les modifications avant
de continuer.
L'utilisateur {\em Alice} fait donc~:
% L'expression « non-fast-forward » (qu'on pourrait traduire par « absence
% d'avance rapide ») veut dire qu'il y a des modifications dans le dépôt
% vers lequel on veut envoyer nos modifications et que nous n'avons
% pas encore récupérées. Il faut donc fusionner les modifications avant
% de continuer.
{\em Alice} has first to merge {\em Bob} modifications already published.
{\em Alice} do the merge~:
\begin{minted}{console}
alice@laptop1$ git pull
\end{minted}
Après quelques messages sur l'avancement de l'opération, on voit
apparaître~:
% Après quelques messages sur l'avancement de l'opération, on voit
% apparaître~:
{\em Alice} and {\em Bob} have change the same lines, thus the
automatic merge should fail.
\begin{verbatim}
Auto-merging sandbox/hello.c
CONFLICT (content): Merge conflict in sandbox/hello.c
Automatic merge failed; fix conflicts and then commit the result.
\end{verbatim}
Ce qui vient de se passer est que {\em Bob} et {\em Alice} ont fait
des modifications au même endroit du même fichier dans les commits
qu'ils ont faits chacun de leur côté (en ajoutant leurs noms sur la
même ligne), et Git ne sait pas quelle version choisir pendant la
fusion~: c'est un conflit, et nous allons devoir le résoudre
manuellement. Allez voir \texttt{hello.c}.
% Ce qui vient de se passer est que {\em Bob} et {\em Alice} ont fait
% des modifications au même endroit du même fichier dans les commits
% qu'ils ont faits chacun de leur côté (en ajoutant leurs noms sur la
% même ligne), et Git ne sait pas quelle version choisir pendant la
% fusion~: c'est un conflit, et nous allons devoir le résoudre
% manuellement. Allez voir \texttt{hello.c}.
La bonne nouvelle, c'est que les modifications faites par \textit{Alice} et Bob
sur des endroits différents du fichier ont été fusionnées. Quand une
......@@ -713,7 +726,10 @@ même temps, ce cas est le plus courant~: les développeurs font les
modifications, et le gestionnaire de versions fait les fusions
automatiquement.
En haut du fichier, on trouve~:
{\em Alice} has to set \texttt{hello.c} to the correct version by
hand. Hopefully, problematic lines are well indicated in the file.
%En haut du fichier, on trouve~:
\begin{minted}{diff}
<<<<<<< HEAD
/* Auteurs : Alice et ... */
......@@ -722,26 +738,28 @@ En haut du fichier, on trouve~:
>>>>>>> 2483c228b1108e74c8ca4f7ca52575902526d42a
\end{minted}
Les lignes entre \verb|<<<<<<<| et \verb|=======| contiennent la
version de votre commit (qui s'appelle HEAD). Les lignes entre
\verb|=======| et \verb|>>>>>>>| contiennent la version que nous
venons de récupérer par « pull » (nous avions dit qu'il était identifié
par la chaîne 2483c22, en fait, l'identifiant complet est plus long,
nous le voyons ici).
% Les lignes entre \verb|<<<<<<<| et \verb|=======| contiennent la
% version de votre commit (qui s'appelle HEAD). Les lignes entre
% \verb|=======| et \verb|>>>>>>>| contiennent la version que nous
% venons de récupérer par « pull » (nous avions dit qu'il était identifié
% par la chaîne 2483c22, en fait, l'identifiant complet est plus long,
% nous le voyons ici).
Il faut alors « choisir » dans \texttt{hello.c} la version qui convient
(ou même la modifier). Ici, on va fusionner à la main (\textit{i.e.} avec un
éditeur de texte) et remplacer l'ensemble par ceci~:
% Il faut alors « choisir » dans \texttt{hello.c} la version qui convient
% (ou même la modifier). Ici, on va fusionner à la main (\textit{i.e.} avec un
% éditeur de texte) et remplacer l'ensemble par ceci~:
{\em Alice} has to remove indicators to put the file in the desired state:
\begin{verbatim}
/* Auteurs : Alice et Bob */
\end{verbatim}
Si {\em Alice} fait à nouveau
%Si {\em Alice} fait à nouveau
Then
\begin{minted}{console}
alice@laptop1$ git status
\end{minted}
On voit apparaître~:
should display~:
\begin{verbatim}
On branch master
Your branch and 'origin/master' have diverged,
......@@ -754,13 +772,15 @@ Unmerged paths:
no changes added to commit (use "git add" and/or "git commit -a")
\end{verbatim}
Si on n'est pas sûr de soi après la résolution des conflits, on peut
lancer la commande~:
To be sure of the results, {\em Alice} check the differences:
% Si on n'est pas sûr de soi après la résolution des conflits, on peut
% lancer la commande~:
\begin{minted}{bash}
git diff # git diff sans argument, alors qu'on avait
# l'habitude d'appeler 'git diff HEAD'
\end{minted}
Après un conflit, Git affichera quelque chose comme~:
The result looks like:
\begin{verbatim}
diff --cc hello.c
index 5513e89,614e4b9..0000000
......@@ -775,14 +795,15 @@ index 5513e89,614e4b9..0000000
#include <stdio.h>
\end{verbatim}
(les '+' et les '-' sont répartis sur deux colonnes, ce qui correspond
aux changements par rapport aux deux « commits » qu'on est en train de
fusionner. Si vous ne comprenez pas ceci, ce n'est pas très grave !)
Après avoir résolu manuellement les conflits à l'intérieur du fichier,
on marque ces conflits comme résolus, explicitement, avec \texttt{git
add}~:
%(les '+' et les '-' sont répartis sur deux colonnes, ce qui correspond
% aux changements par rapport aux deux « commits » qu'on est en train de
% fusionner. Si vous ne comprenez pas ceci, ce n'est pas très grave !)
% Après avoir résolu manuellement les conflits à l'intérieur du fichier,
% on marque ces conflits comme résolus, explicitement, avec \texttt{git
% add}~:
{\em Alice} mark the conflicts as solved, using \texttt{git add}:
\begin{verbatim}
$ git add hello.c
$ git status
......@@ -796,70 +817,86 @@ Changes to be committed:
\end{verbatim}
On note que \texttt{hello.c} n'est plus considéré « both modified »
(c'est-à-dire contient des conflits non-résolus) par Git, mais simplement
comme « modified ».
% On note que \texttt{hello.c} n'est plus considéré « both modified »
% (c'est-à-dire contient des conflits non-résolus) par Git, mais simplement
% comme « modified ».
% Quand il n'y a plus de fichier en conflit, il faut faire un commit
% (comme « git pull » nous l'avait demandé)~:
Quand il n'y a plus de fichier en conflit, il faut faire un commit
(comme « git pull » nous l'avait demandé)~:
Then, {\em Alice} finishes to build the merge commit:
\begin{minted}{bash}
git commit
\end{minted}
(Dans ce cas, il est conseillé, même pour un débutant, de ne pas
utiliser l'option \verb|-a|, mais c'est un détail)
% (Dans ce cas, il est conseillé, même pour un débutant, de ne pas
% utiliser l'option \verb|-a|, mais c'est un détail)
The default message is sufficient.
Un éditeur s'ouvre, et propose un message de commit du type « \texttt{Merge
branch 'master' of ...} », on peut le laisser tel quel, sauver et
quitter l'éditeur.
% Un éditeur s'ouvre, et propose un message de commit du type « \texttt{Merge
% branch 'master' of ...} », on peut le laisser tel quel, sauver et
% quitter l'éditeur.
Nb~: s'il n'y avait pas eu de conflit, ce qui est le cas le plus
courant, « git pull » aurait fait tout cela~: télécharger le nouveau
commit, faire la fusion automatique, et créer si besoin un nouveau
commit correspondant à la fusion.
% Nb~: s'il n'y avait pas eu de conflit, ce qui est le cas le plus
% courant, « git pull » aurait fait tout cela~: télécharger le nouveau
% commit, faire la fusion automatique, et créer si besoin un nouveau
% commit correspondant à la fusion.
On peut maintenant regarder plus en détails ce qu'il s'est passé~:
%On peut maintenant regarder plus en détails ce qu'il s'est passé~:
Looking at the details:
\begin{minted}{bash}
gitk
\end{minted}
Pour \textit{Alice}, on voit apparaître les deux « commit » fait par {\em Bob} et
{\em Alice} en parallèle, puis le « merge commit » que nous venons de créer
avec « git pull ». Pour {\em Bob}, rien n'a changé.
{\em Alice} logs show 3 commits: the two modifications and the merge.
% Pour \textit{Alice}, on voit apparaître les deux « commit » fait par {\em Bob} et
% {\em Alice} en parallèle, puis le « merge commit » que nous venons de créer
% avec « git pull ». Pour {\em Bob}, rien n'a changé.
La fusion étant faite, {\em Alice} peut mettre à disposition son travail
(le premier commit, manuel, et le commit de fusion) avec~:
{\em Alice} publishes her repository state:
\begin{minted}{console}
alice@laptop1$ git push
\end{minted}
et {\em Bob} peut récupérer le tout avec~:
and {\em Bob} get it without a glinch:
%et {\em Bob} peut récupérer le tout avec~:
\begin{minted}{console}
bob@laptop2$ git pull
\end{minted}
(cette fois-ci, aucun conflit, tout se passe très rapidement et en une
commande)
Les deux utilisateurs peuvent comparer ce qu'ils ont avec~:
% (cette fois-ci, aucun conflit, tout se passe très rapidement et en une
% commande)
%Les deux utilisateurs peuvent comparer ce qu'ils ont avec~:
All repositories should be in the same state now:
\begin{minted}{bash}
gitk
\end{minted}
Ils ont complètement synchronisé leurs répertoires. On peut également
faire~:
% Ils ont complètement synchronisé leurs répertoires. On peut également
% faire~:
\begin{minted}{bash}
git pull
git push
git pull # do nothing: already up-to-date
git push # do nothing: already up-to-date
\end{minted}
Mais ces commandes se contenteront de répondre \texttt{Already up-to-date.}
et \texttt{Everything up-to-date}.
% Mais ces commandes se contenteront de répondre \texttt{Already up-to-date.}
% et \texttt{Everything up-to-date}.
\subsection{Ajout de fichiers}
\subsection{Add new files}
À présent, {\em Alice} crée un nouveau fichier, \texttt{toto.c},
avec un contenu quelconque.
{\em Alice} fait~:
{\em Alice} create a new file \texttt{toto.c} and do:
\begin{minted}{console}
alice@laptop1$ git status
\end{minted}
On voit apparaître~:
should display:
\begin{verbatim}
On branch master
Untracked files:
......@@ -868,15 +905,19 @@ Untracked files:
toto.c
nothing added to commit but untracked files present (use "git add" to track)
\end{verbatim}
Notre fichier \texttt{toto.c} est considéré comme « Untracked » (non suivi
par Git). Si on veut que \texttt{toto.c} soit ajouté au dépôt, il faut
l'enregistrer (\texttt{git commit} ne suffit pas)~: \texttt{git add toto.c}
% Notre fichier \texttt{toto.c} est considéré comme « Untracked » (non suivi
% par Git). Si on veut que \texttt{toto.c} soit ajouté au dépôt, il faut
% l'enregistrer (\texttt{git commit} ne suffit pas)~:
To put it in the next commit, {\em Alice} has to mark him for tracking
first with \texttt{git add toto.c}:
{\em Alice} fait à présent~:
%{\em Alice} fait à présent~:
\begin{minted}{console}
alice@laptop1$ git add toto.c
alice@laptop1$ git status
\end{minted}
On voit apparaître~:
should display:
\begin{verbatim}
On branch master
Changes to be committed:
......@@ -885,34 +926,41 @@ Changes to be committed:
new file: toto.c
\end{verbatim}
{\em Alice} fait à présent (-m permet de donner directement le message
de log)~:
{\em Alice} create the commit in one line, providing the message:
% fait à présent (-m permet de donner directement le message
% de log)~:
\begin{minted}{bash}
alice@laptop1$ git commit -m "ajout de toto.c"
\end{minted}
On voit apparaître~:
should display:
\begin{verbatim}
[master b1d56e6] Ajout de toto.c
1 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 toto.c
\end{verbatim}
\texttt{toto.c} a été enregistré dans le dépôt. {\em Alice} peut publier ce
changement~:
% \texttt{toto.c} a été enregistré dans le dépôt. {\em Alice} peut publier ce
% changement~:
{\em Alice} publishes the commit:
\begin{minted}{console}
alice@laptop1$ git push
\end{minted}
{\em Bob} fait à présent~:
{\em Bob} get the file with the following command:
\begin{minted}{console}
bob@laptop2$ git pull
\end{minted}
Après quelques messages informatifs, on voit apparaître~:
that should display:
\begin{verbatim}
Fast forward
toto.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 toto.c
\end{verbatim}
Le fichier \texttt{toto.c} est maintenant présent chez {\em Bob}.
% Le fichier \texttt{toto.c} est maintenant présent chez {\em Bob}.
\subsection{Fichiers ignorés par Git}
......@@ -989,56 +1037,59 @@ Quelques remarques~:
monde.
\end{itemize}
\subsection{Fin de l'exercice}
A ce stade, vous devriez avoir les bases pour l'utilisation
quotidienne de Git.
Pour utiliser Git sur un vrai TP ou projet, on peut reprendre les
explications du début de ce document
(section~\ref{sec=creation-depot-partagee}) pour créer un nouveau
dépôt Git pour chaque TP.
Pour créer un projet sans utiliser gitlab, mais directement un compte
accessible par ssh, les explications sont également disponibles sur la
page
\url{http://ensiwiki.ensimag.fr/index.php/Creer_un_depot_partage_avec_Git}
d'EnsiWiki.
Une configuration classique pour des étudiants Ensimag~: créer un
dépôt partagé par TP, et pour chaque TP, chaque étudiant de l'équipe
aura sa copie de travail pour le TP. Par exemple, si \textit{Alice}
travaille avec \textit{Bob} en TP d'algo, et avec \textit{Charlie} en
TP de méthodes numériques, il y aura un dépôt partagé pour le TP
d'algo (partagé entre \textit{Alice} et \textit{Bob}), et une pour le
TP de méthodes numériques (partagé entre \textit{Alice} et
\textit{Charlie}). Quand \textit{Alice} travaillera sur son TP
d'algo, elle sera dans la copie de travail correspondante, et la
commande \texttt{git push} enverra les changements au dépôt qu'elle
partage avec \textit{Bob}, et quand elle travaillera sur son TP de
méthodes numériques, elle travaillera dans son autre copie de travail,
et \texttt{git push} enverra ses changements au dépôt qu'elle partage
avec \textit{Charlie}. On peut avoir autant de dépôts partagés qu'on
veut, et autant de copie de travail qu'on veut par dépôt partagé.
Dans l'immédiat, si vous souhaitez continuer à travailler dans
le dépôt que vous venez de créer, vous pouvez aussi effacer le
répertoire \texttt{sandbox/}~:
% \subsection{Fin de l'exercice}
\begin{minted}{bash}
git rm -r sandbox/
git status # Pour vérifier qu'on n'a pas fait de bêtise
git commit -m "Suppression de sandbox/ (exercice termine)"
\end{minted}
puis continuer à travailler. Si vous avez besoin d'importer un
squelette de code, vous pouvez le faire par exemple avec ces
commandes~:
\begin{minted}{bash}
tar xzvf ~/chemin/vers/le/squelette.tar.gz
git add .
git commit -m "import du squelette"
\end{minted}
% A ce stade, vous devriez avoir les bases pour l'utilisation
% quotidienne de Git.
% Pour utiliser Git sur un vrai TP ou projet, on peut reprendre les
% explications du début de ce document
% (section~\ref{sec=creation-depot-partagee}) pour créer un nouveau
% dépôt Git pour chaque TP.
% Pour créer un projet sans utiliser gitlab, mais directement un compte
% accessible par ssh, les explications sont également disponibles sur la
% page
% \url{http://ensiwiki.ensimag.fr/index.php/Creer_un_depot_partage_avec_Git}
% d'EnsiWiki.
% Une configuration classique pour des étudiants Ensimag~: créer un
% dépôt partagé par TP, et pour chaque TP, chaque étudiant de l'équipe
% aura sa copie de travail pour le TP. Par exemple, si \textit{Alice}
% travaille avec \textit{Bob} en TP d'algo, et avec \textit{Charlie} en
% TP de méthodes numériques, il y aura un dépôt partagé pour le TP
% d'algo (partagé entre \textit{Alice} et \textit{Bob}), et une pour le
% TP de méthodes numériques (partagé entre \textit{Alice} et
% \textit{Charlie}). Quand \textit{Alice} travaillera sur son TP
% d'algo, elle sera dans la copie de travail correspondante, et la
% commande \texttt{git push} enverra les changements au dépôt qu'elle
% partage avec \textit{Bob}, et quand elle travaillera sur son TP de
% méthodes numériques, elle travaillera dans son autre copie de travail,
% et \texttt{git push} enverra ses changements au dépôt qu'elle partage
% avec \textit{Charlie}. On peut avoir autant de dépôts partagés qu'on
% veut, et autant de copie de travail qu'on veut par dépôt partagé.
% Dans l'immédiat, si vous souhaitez continuer à travailler dans
% le dépôt que vous venez de créer, vous pouvez aussi effacer le
% répertoire \texttt{sandbox/}~:
% \begin{minted}{bash}
% git rm -r sandbox/
% git status # Pour vérifier qu'on n'a pas fait de bêtise
% git commit -m "Suppression de sandbox/ (exercice termine)"
% \end{minted}
% puis continuer à travailler. Si vous avez besoin d'importer un
% squelette de code, vous pouvez le faire par exemple avec ces
% commandes~:
% \begin{minted}{bash}
% tar xzvf ~/chemin/vers/le/squelette.tar.gz
% git add .
% git commit -m "import du squelette"
% \end{minted}
% \section{Question bonus: Gitlab}
......@@ -1052,22 +1103,24 @@ git commit -m "import du squelette"
\section{Pour conclure\dots{}}
Bien sûr, Git est bien plus que ce que nous venons
de voir, et nous encourageons les plus curieux à se plonger dans le
manuel utilisateur et les pages de man de Git pour en apprendre plus.
Au niveau débutant, voici ce qu'on peut retenir~:
% Bien sûr, Git est bien plus que ce que nous venons
% de voir, et nous encourageons les plus curieux à se plonger dans le
% manuel utilisateur et les pages de man de Git pour en apprendre plus.
% Au niveau débutant, voici ce qu'on peut retenir~:
Git has many more to help you in your daily life of researchers or
developers. Most are explained in \href{https//git-scm.com/book}{Pro
Git book}.
\section*{Les commandes}
\section*{Summary of the basic commands}
\begin{description}
\item[git commit] enregistre l'état courant de tous les fichiers qui
ont été au préalable ajoutés par \texttt{git add},
\item[git commit -a] enregistre l'état courant du répertoire de travail,
\item[git push] publie les commits,
\item[git pull] récupère les commits publiés,
\item[git add, git rm et git mv] permettent de dire à Git quels
fichiers il doit surveiller (``traquer'' ou ``versionner'' dans le
jargon),
\item[git status, git diff HEAD] pour voir où on en est.
\item[git commit] register, in a local commit, the state of file previously added with \texttt{git add}
\item[git commit -a] register, in a local commit, the state of all tracked files
\item[git push] publishes the commits
\item[git pull] get and merge published commits,
\item[git add, git rm et git mv] mark, or unmark, file for tracking.
\item[git status, git diff HEAD] display the current state of the local repository and tips
for the next step
\end{description}
\section*{Conseils pratiques}
......
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