TP GIT L1

Exercice 1: Introduction à Git

Un dépôt Git permet de:

Dans cet exercice, nous allons commencer à voir le premier.

Avant de créer un dépôt Git dans notre espace de travail (« workspace »), il faudra s’assurer d’avoir Git sur sa machine et de maîtriser quelques notions sur la ligne de commande Linux.

Ce TP est écrit pour des élèves ingénieurs utilisant Java et Eclipse. Selon votre statut et département, les chemins d’accès des fichiers pourraient être différents. Et vous pourriez être en train d’utiliser un autre langage et un autre environnement de développement qu’Eclipse. Donc vous devrez peut etre faire des adaptations par rapport au texte du TP.

Introduction au terminal

Git est un outil en ligne de commande. Pour l’utiliser, il faut maitriser quelques notions sur la ligne de commande Linux. Certains connaissent déjà la ligne de commande Linux et certains pas. Si vous ne l’avez pas encore utilisé, ne vous inquiétez pas, ici on va voir une petite introduction.

Les trois plateformes majeures proposent chacune une façon de lancer une interaction en ligne de commande, le terminal.

Linux

Chaque Linux est différent, mais vous pouvez typiquement lancer un terminal avec Terminal.

Windows

Si vous avez Windows, alors ouvrez Windows Powershell, qui inclut les commandes introduites dans ce paragraphe. Pour trouver Powershell sur Windows, faites une recherche dans la barre de recherche en bas à gauche.

Mac

Le terminal du Mac se trouve dans /Applications/Utilities.

Pour tous

Ouvrez un terminal.

Terminal

Vous voyez une ligne avec le nom de la machine suivi de % et un curseur. Dans Powershell, il y a le dossier courant et > avant le curseur. Cette ligne est l’invite.

Chaque commande Linux a un nom :

Certaines commandes ont besoin d’arguments. Par exemple, pour changer de dossier, il faut savoir où aller. On rajoute donc des arguments à la commande :

Essayons quelques commandes :

Tapez pwd↵

Si vous utilisez une machine des salles de TP de l’école, ça réponde : /cal/homes/votrelogin

Dans ces TPs, nous allons utiliser le symbole → pour indiquer la réponse du système, ainsi :

Tapez pwd ↵

→ /cal/homes/votrelogin.

Tapez ls↵

→ Vous voyez la liste des fichiers et dossiers dans votre dossier personnel. Dans les salles de TP, on y trouvera un dossier workspace qui est le dossier pour votre espace de travail Java, crée par défaut par Eclipse. Si vous l’avez créé ailleurs que votre dossier perso, il faudrait y naviguer avec cd.

Tapez cd workspace↵ pour aller dans le dossier workspace

Tapez ls↵ pour afficher les fichiers du dossier courant

→ Vous voyez au moins un dossier tp01

Tapez cd tp01↵

Puis ls↵

→ Vous voyez au moins un dossier bin et un dossier src

Tapez ls src↵

→ Vous voyez tous les autres fichiers que vous avez créés.

Git est-il installé sur votre machine ?

Si vous êtes sur une machine d’une salle de TP, vous pouvez passer directement à la prochaine section. Sinon, il faut installer git sur votre machine.

Windows

Téléchargez Git pour Windows (site en anglais) où vous pouvez choisir soit l’exe si vous savez où le mettre, soit un setup automatique qui va gèrer tout ça pour vous.

Mac

Dans un terminal, tapez git --version ce qui va soit vous répondre la version déjà installée soit vous proposer d’installer les Xcode Command Line Tools qui contiennent git. Installez-le le cas échéant.

Linux

Dans un terminal, si vous avez Fedora ou équivalent:

sudo dnf install git-all

Si vous avez Debian, Ubuntu ou équivalent:

sudo apt install git-all

Git: c’est parti !

Très bien, nous avons tous les éléments nécessaires pour utiliser Git en ligne de commande.

Avant tout, il faut donner quelques préférences:

  1. git utilise un programme ‘pager’ pour afficher des messages longs, et ça peut être assez déroutant au début, donc nous supprimons le ‘pager’
  2. git utilise un très vieil éditeur de texte pour les messages de commit, et nous préférons en utiliser un plus facile à utiliser pour des débutants.
  3. git a besoin de savoir votre nom et votre email.

Merci de taper les instructions suivantes dans le terminal, en y remplaçant votre nom et votre email.

git config --global core.pager ''
git config --global core.editor nano
git config --global user.name "votre nom"
git config --global user.email "votre@email"

Pour cet exercice, nous voulons créer un nouveau dépôt Git qui va contenir le code de notre projet. Nous voudrons ensuite y mettre le code que nous avons écrit. Puis, pour terminer, nous allons vérifier que nous avons bien créé notre dépôt Git.

Initialiser le dépôt

Créer un dépôt Git, c’est dire à Git qu’on veut qu’il puisse suivre toutes les versions et évolutions des fichiers dans un dossier et ses sous-dossiers. Pour faire cela, Git va stocker de l’information dans la racine du dépôt. Un dossier .git va apparaitre, dossier qu’il ne faudra en aucun cas modifier. Tous les outils Git reconnaissent le dossier .git, même si on ne va jamais le toucher directement.

Pour créer ce dossier .git, placez vous dans le dossier “principal”: dans notre cas, le dossier est tp01.

A coup de cd nomdedossier et de cd .., placez vous dans le dossier /cal/homes/votrelogin/workspace/tp01. Vérifiez à l’aide de pwd. (NB : ce dossier pourrait être différent si vous n’êtes pas sur une machine de salle de TP ou si vous avez créé votre workspace Eclipse ailleurs.)

Puis tapez git init↵

→ Initialized empty Git repository in /cal/homes/votrelogin/workspace/tp01/.git

Félicitations, vous avez créé votre premier dépôt Git.

Ajouter les fichiers dans le dépôt

Pour l’instant, nous avons un dépôt Git vide.

Ceci pourrait sembler bizarre. C’est dans le dossier de notre projet Java qu’on a créé notre dépôt Git, pourquoi est-il vide ?

Avec Git, on choisit fichier par fichier ce qu’on veut mettre dans le dépôt, c’est à dire : quels sont les fichiers dont on veut suivre l’évolution des modifications.

On peut voir l’état de notre dépôt avec la commande git status.

Tapez git status↵

→

On branch master
       
Initial commit
       
No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
       
     .classpath
     .project
     .settings/
     bin/
     src/

La signification ligne par ligne est:

Les fichiers non marqués sont des fichiers créés par eclipse et sur lesquels il est bon de passer un moment :

Pour l’instant, nous allons mettre seulement le code source Java dans notre dépôt Git. Pour faire cela, nous utilisons la commande git add :

Tapez git add src/tp01/HelloWorld.java↵

Vous avez ajouté ce fichier source java dans le dépôt. Puis tapez de nouveau git status↵

On y voit une nouvelle section avec le nouveau fichier à rajouter dans le dépôt :

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
       
      new file:   src/tp01/HelloWorld.java

Pour l’instant, nous avons préparé une nouvelle version de notre projet, mais elle ne figure pas encore dans le dépôt Git. Il reste de signaler à Git que cette modification constitue une nouvelle version qu’on veut garder. On va donc l’enregistrer dans le dépôt avec un message qui va servir pour nous rappeler de ce qu’on a fait. Dans la terminologie Git, enregistrer une nouvelle version s’appelle faire un « commit ».

Faites alors git commit -m "message"↵ en remplaçant message par un message pertinent (du genre, “premier commit”)

Faites maintenant git status↵ et voyez la différence avec la réponse précédente.

Enfin, faites git log↵ et voyez le résultat:

commit c3e097802d521508f146111d24ba8e6d677090e4
Author: votrelogin <votrelogin@c124-02.enst.fr>
Date:   Wed May 9 16:39:11 2018 +0200

    premier commit

Après commit, il y a un code unique d’identification. Puis votre nom, la date et le message de commit.

Si vous voulez voir les fichiers contenus dans le commit, faites:

git log --stat

Vous avez peut-être remarqué que toutes les commandes Git suivent la forme git commande. Certaines commandes ont aussi des options, qu’on écrit avec --option. Par exemple, vous avez vu l’option -m "message" (qui est un raccourci pour --message="message"). Il peut aussi être intéressant de faire git log --oneline --decorate

Dans vos git status, les fichiers non suivis par git sont toujours présents, en rouge. Il serait utile de les masquer une fois pour toutes, en expliquant à git qu’il faut les ignorer. Cela se fait en créant dans la copie de travail un fichier .gitignore. Ce fichier contient une spécification par ligne:

Ce fichier doit être commit. Préparez un tel fichier, ajoutez le à git et commit.

Pour l’instant, nous avons vu les commandes :

Exercice 2

Entre les deux exercices, faites des modifications sur votre copie locale, et au moins un commit. Laissez quelques changements dans la copie de travail sans les committer.

Un court tutoriel GitLab se trouve ici

Dans cet exercice, nous allons :

Mettre à jour le dépôt local

Tout d’abord, mettez à jour votre dépôt local. Avec la commande git status, on peut voir les nouveaux fichiers qu’on a rajouté à notre copie de travail mais qui ne sont pas encore sous Git. On voit aussi une nouvelle section décrivant les fichiers qui ont été modifiés depuis la dernière version commitée. Ces modifications non plus ne sont pas (encore) pris en charge par Git. C’est à nous de dire à Git qu’on veut les garder.

Si on veut voir ce qui a changé dans la copie de travail par rapport la dernière version sous Git, on peut utiliser la commande git diff, ce qui affichera toutes les modifications de tous les fichiers dans le dépôt git depuis la dernière version commitée.

Maintenant que nous avons regardé ce qui a changé, rajoutez-les à une nouvelle version avec les commandes git add et git commit.

Quelques options utiles

GitLab

GitLab est une interface web qui permet de gérer un dépôt Git distant. Il propose de nombreuses fonctionnalités telles que la gestion de documentation, le suivi de bogues, la collaboration des équipes, etc. Pour ce TP, nous n’allons utiliser que la création et gestion d’un dépôt distant.

La première chose à faire est de se connecter au GitLab : https://gitlab.telecom-paris.fr. Avec le GitLab de l’école, vous devez vous connecter en cliquant le bouton Shibboleth.

Il y a un espace dans gitlab qui est prévu pour que vous puissiez faire ce que vous voulez, faire des erreurs et apprendre. Cet espace est de la forme 2019_gr3_tp, c’est à dire année suivie d’un caractère souligné suivi de “gr” et le numéro de votre groupe suivi d’un caractère souligné suivi de “tp”. Demandez l’accès à ce groupe, et pour ce faire, chercher le groupe dans https://gitlab.telecom-paris.fr/INF103

Une fois que vous aurez été ajouté.e dans ce groupe de TP, allez dans ce groupe. En haut de l’écran il devrait y avoir un bouton + qui permet de créer un nouveau projet :

creer depuis accueil

Puis il faut configurer le nouveau projet :

Project Name
Le nom du projet. Rappelons que chaque projet Java aura son propre dépôt Git. Ici, nous conseillons un nom comme inf103-tp2-<votrenom>.
Project description
Si vous voulez rajouter une description du projet, n’hésitez pas. Pour ce TP, c’est pas necessaire.
Visibility Level
Qui peut voir le dépôt ? Nous conseillons fortement que les dépôts du cours soient Private afin de d’éviter le plagiat de votre travail par quelqu’un d’autre.

Puis cliquer le bouton Create Project.

Basta ! Vous avez créé un dépôt distant pour votre TP. GitLab vous propose quelques ensembles de commandes pour mettre des contenus dans ce dépôt distant, mais on va les ignorer.

SSH

Il y a deux façons dont la commande git peut communiquer avec votre dépôt distant : via HTTPS ou via SSH. La deuxième est un peu plus compliquée à mettre en place mais évite de taper son mot-de-passe à chaque fois qu’on interagit avec le dépôt distant.

Pour utiliser SSH, il faudra :

  1. Créer une clé SSH.
  2. Rajouter cette clé à votre compte GitLab.

SSH utilisent le chiffrage à clé publique. Ainsi, une clef SSH, c’est quelque chose en deux parties :

C’est la partie publique de la clé qu’on va mettre dans GitLab. Tant que vous avez la clé privée sur votre machine, la commande git pourra communiquer avec votre dépôt distant sans mot-de-passe.

Créer une clef sur Linux ou Mac

Si vous avez déjà une clé SSH sur cette machine, vous pouvez passer à la prochaine étape.

Ouvrez un terminal.

Tapez ssh-keygen ↵

Cette commande génère une paire de clés publique/privée. Elle commence par vous demander où mettre les clés. Utilisez le défaut, tapez ↵

Ensuite, on vous demande un mot de passe pour proteger la clé. Si vous la laissez vide, vous n’auriez pas un mot de passe à taper systématiquement. En revanche, il serait primordial de protéger la clé privée — n’importe qui en possession de la clé privée aurait donc accès à vos comptes. Nous conseillons de laisser le mot de passe vide et de protéger la clé privée.

Vous trouverez la clé privée et publique dans un dossier .ssh de votre dossier principal :

Faire un ls .ssh↵ devrait révéler les fichiers id_rsa et id_rsa.pub, ce dernier étant la clé publique que vous pouvez librement partager.

Afficher la clé publique en faisant cat .ssh/id_rsa.pub ↵

→

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAtlnV1GsVsEGb5odmwkmmJxs+TtuPUmmtYr4
vvl3xfovbjDRr+fgXMCgstotO6mmIzxQY5XD+yVels8ZMHHZQETu8n5mJN33BN0gXVcknra
6aOO5QPUFi+jm1Zx4fKpREwEtaEKIf8mYCoI7MM9YEfeUoAxMTn6mSgk+ozOZp36SnSB96+
EMak2v/5vgT4WRnwZ0XzAAoSR4fYEQi6/hp4L2C2hZCyYa5lflCaSMG1c/DGp0umDsnFcWo
eBickLbKkfPuJAXQH0VJlG+Gocy7jTp4mC8m46I9aX8x4DXsazO2v1FaK0VmMtGx/hOAKaU
lH3kTy4YnzJfK/fgIIsiJXw== eaganj@Frog

Puis copier la clé pour qu’on puisse la coller dans GitLab, dessous.

Créer une clef sur Windows avec PuttyGen

  1. Lancez PuTTYgen
  2. Pour “Type of key to generate”, choisissez “SSH-2 RSA”.
  3. Cliquez sur “Generate”.
  4. Bougez la souris dans la zone sous la barre de progrès. Quand il en a assez, le programme génère les clefs.
  5. Si vous laissez vide le champ “Key passphrase”, vous n’auriez pas un mot de passe à taper systématiquement. En revanche, il serait primordial de protéger la clé privée — n’importe qui en possession de la clé privée aurait donc accès à vos comptes. Nous conseillons de laisser le mot de passe vide et de protéger la clé privée.
  6. Cliquez sur “Save private key” et “Save public key”.

Sur Windows, la localisation de la clef privée est un paramètre de l’application qui l’utilise.

Rajouter la clé publique à GitLab

Vous avez créé votre paire de clés publique/privée. Il faut maintenant configurer GitLab pour associer votre clé publique à votre compte.

  1. En haut à droit, cliquer le menu pour votre compte, puis sélectionnez Settings.
  2. Dans le menu à gauche, sélectionnez SSH Keys.
  3. Collez les contenus de la clé publique dans le champs de texte “Key”.
  4. Saisissez un nom pour la clé. Ce nom a typiquement la forme utilisateur@_machine_. Par exemple : eaganj@Frog ou eaganj@ENST.
  5. Rajoutez la clé.

Désormais, GitLab traitera n’importe quelle connexion établie avec votre clé privé comme venant de vous.

Connection à un dépot distant avec GitLab

Vous avez créé votre projet dans GitLab et vous avez configuré GitLab avec votre clé publique. On veut maintenant associer votre dépôt distant (GitLab) à votre dépôt local.

Dans un premier temps, cherchez dans l’adresse de votre dépot distant sur GitLab. Revenez au projet que vous avez créé tout à l’heure (e.g. en naviguant vers Projects &rarr; Your projects &rarr; inf103-tp2).

En haut de la page, on fait apparaitre l’adresse du dépôt distant en cliquant sur la flêche à droite de Clone :

Dépôt distant dans GitLab

L’adresse a la forme suivante:

git@gitlab.enst.fr:INF103/2019_gr3_tp/inf103-tp2.git

Nous voulons ensuite rajouter cette adresse de dépôt distant à notre dépôt local. Dans le Terminal, allez à votre dépôt local, puis tapez la command suivante, en remplaçant l’adresse du dépôt comme il faut :

git remote add origin git@gitlab.enst.fr:INF103/2019_gr3_tp/inf103-tp2.git

Cette commande ajoute le dépot distant de nom origin et d’adresse git@gitlab.enst.fr:INF103/2019_gr3_tp/inf103-tp2.git à votre dépot local. Le nom origin est utilisé par convention pour indiqué le dépôt distant principal du projet, mais vous pouvez utiliser n’importe quel nom, et il pourrait y en avoir plusieurs. Par exemple, vous pourriez rajouter un dépôt distant gitlab et un autre bitbucket si, e.g., vous vouliez avoir deux dépôts distants redondants.

GIT et les clefs SSH

Quand GIT doit contacter le serveur gitlab et utiliser une clef SSH, il lui manque encore une information: où est la clef à utiliser ? Et surtout, vous pourriez utiliser des clefs différentes pour différents sites: une clef pour GitHub, une pour gitlab, etc.

Pour donner cette information à GIT, il faut créer un fichier config dans le dossier .ssh, qui contienne:

Host gitlab.enst.fr
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes

où id_rsa est le nom de votre clef privée.

“Pousser” un dépôt Git

Normalement, le dépôt local contient quelques révisions. Vous avez aussi créé un dépôt distant GitLab et configuré le dépôt local avec un dépôt distant du nom origin.

Par contre, si on regarde dans GitLab, on voit que le dépôt distant est encore vide. Il reste à synchroniser le dépôt local vers le dépôt distant. On appelle ça « pousser un dépôt ».

Revenez au Terminal du dépôt local. La première fois qu’on veut pousser un dépôt, il faut dire à git vers quel dépôt distant pousser, même s’il n’y en a qu’un seul configuré. Git peut parfois être un peu bète.

Tapez la commande git push --set-upstream origin master ↵

Si tout se passe bien, vous verrez quelque chose du genre :

→

Counting objects: 12, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (12/12), 984 bytes | 984.00 KiB/s, done.
Total 12 (delta 0), reused 0 (delta 0)
To gitlab.enst.fr:eaganj/inf103-tp2.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

Si vous voyez des erreurs d’authentification, vérifiez que vous avez bien la clé privée SSH sur votre système et la clé publique dans GitLab.

Désormais, vous n’auriez plus besoin de re-dire à Git quel dépôt distant utiliser. Vous pouvez alors faire tout simplement git push↵.

Git 3

Rajoutez une nouvelle version dans votre dépôt local. Les commandes git status, git diff, et git commit seront sûrement utiles. N’oubliez pas de donner un message utile au commit, du genre « Rajout de tri sélection et tri rapide ».

Travailler avec un dépôt distant

Il est courant de vouloir travailler un projet sur plusieurs machines différents. Par exemple, sur une machine de la salle de TP et sur une machine perso. Plus tard, on vera aussi comment travailler à plusieurs sur un même dépôt. Pour faire cela, nous allons découvrir deux nouvelles commandes : git clone et git pull.

Git clone

Lorsqu’on veut récupérer un dépôt distant qui n’est pas encore sur la machine locale, on utilise la commande git clone. Cette commande cherche un dépôt distant et créé une copie identique de tous les fichiers, de toutes leurs anciennes versions, tous les commits, etc. Ainsi, vous obtiendrez un dépôt local conforme au dépôt distant au moment où vous faites le clone.

Retrouvez l’adresse du dépôt distant en se connectant au GitLab. C’est la même adresse qu’on a utilisée lors de l’exercice précédent, quelque chose comme git@gitlab.enst.fr:eaganj/inf103-tp2.git.

Puis, en remplaçant l’adresse par la bonne, tapez : git clone git@gitlab.enst.fr:eaganj/inf103-tp2.git↵

→

Cloning into 'inf103-tp2'...
remote: Counting objects: 17, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 17 (delta 2), reused 0 (delta 0)
Receiving objects: 100% (17/17), done.
Resolving deltas: 100% (2/2), done.

Voilà ! Vous avez créé un dépôt local conforme au dépôt distant. Il suffit de faire cd inf103-tp2 pour rentrer dans le dépôt.

Erreurs d’authentification et les clés SSH

Si vous voyez une erreur de droits d’accès, c’est peut-être lié aux clés d’accès SSH.

Si vous êtes sur une machine Linux ou Mac :

On peut verifier que le nouveau dépôt local contient non seulement la dernière version du projet mais aussi toutes les version antérieures. Faites git log pour voir l’ensemble des versions dans le dépôt.

Attention aux fichiers non committés

Quand vous faites des opérations Git, par exemple un pull, checkout ou un merge (qu’on ver ra ultérieurement), alors qu’ il y a des fichiers modifiés ou non-suivis dans la copie de travail, alors il peut arriver que vous les perdiez. Normalement, Git vous prévient que vous allez écraser des fichiers non versionnés. Nous avons vu des exemples où ce message était ignoré et l’étudiant a perdu beaucoup de travail.

Quoi qu’il en soit, ajoutez rapidement les nouveaux fichiers à Git, n’ignorez pas de fichiers importants, etc. Avant de faire une opération tel que pull, checkout, ou merge, assurez-vous que votre dépôt est propre en vérifiant que toute modification et tout fichier non-suivi n’est pas important (e.g. avec git status et git diff). Si vous voulez garder les modifs, faites des commits ou un stash (ci-dessous).

Stash

Dans l’avertissement dessus, vous voyez que certaines opérations Git peuvent modifier votre copie de travail. Avant de faire ces opérations, on veut généralement avoir une copie de travail propre, où il n’y a ni fichier modifié ni fichier non-suivi — ou au moins que ces fichiers non-suivis ne sont pas importants.

Parfois, on peut avoir des modifications incomplètes : on n’est pas prêt à faire commit dans une nouvelle version, mais on ne veut pas les perdre non plus. Alors, on peut les mettre dans un « stash » (une planque ou cachette). Planquer notre copie de travail est comme ramasser tous les fichiers modifiés et les mettre dans la cachette. La planque n’est pas une version dans Git, elle n’est pas poussée vers le dépôt distant.

Pour planquer notre travail, on peut faire git stash. Alors on se retrouve avec une copie de travail à la dernière version commitée. Pour retrouver nos modifications, on fait git stash pop, qui enlève les modifications de la planque et les rapplique à notre copie de travail.

Vous avez vu comment cloner un dépôt distant pour créer un nouveau dépôt local, comment mettre à jour un dépôt local à partir d’un dépôt distant (tirer), et comment planquer les modifications locales qu’on n’est pas encore prêt à mettre dans un nouveau commit.

Nous verrons comment résoudre des « conflits » lorsqu’on fait des modifications dans deux dépôts différents.

Git 4

Lors des exercices précédents, vous avez vu comment créer plusieurs dépôts locaux qui sont associés à un dépôt distant. Si on modifie le même code différemment dans deux dépôts, il n’est pas évident de savoir quoi faire lorsqu’on essaie d’intégrer les deux versions. C’est un conflit.

Nous allons recréer la situation.

Je suppose que vous avez un dépôt A connecté avec un dépot distant sur gitlab.

Créez dans un autre dossier un clone du dépôt distant. Si vous avez oublié l’URL du dépôt distant, faites:

git remote -v

Dans le dépôt A. Il vous répond l’URL du remote pour fetch et push (qui peut être différent). Dans un autre dossier, faites git clone avec cette URL ce qui donne un dépôt local B.

Dans le dépôt local A, modifiez un fichier, add, commit, push.

Dans le dépôt local B, modifiez le même fichier, mais d’une autre manière, add, commit, push.

Normalement, vous devriez voir quelque chose comme ceci:

→


CONFLICT (content): Merge conflict in Heap.java
Automatic merge failed; fix conflicts and then commit the result.

Git est vaguement intelligent. Si ces modifications portaient sur deux fichiers différents ou deux méthodes différentes de notre code, il aurait pu intégrer les deux ensembles de modifications automatiquement. Mais ici, nous avons modifié le même code, les mêmes lignes de texte dans les deux versions.
Alors, Git nous demande quoi faire. Avec git status on voit que Heap.java est en conflit.

Si on regarde le code dans Eclipse, on voit que Git a délimité le conflit ainsi :


<<<<<<< identifiant-de-la-version-locale
/* la version du code qui existe dans le dépôt local */
int ceCodePeutEtreSurPlusieursLignes ;
|||||||
// La version qui existait avant les deux modifications
=======
// la version du code qui existe dans le dépôt distant
>>>>>>> identifiant-de-la-version-distante

Pour corriger le conflit, éditez le fichier du conflit et créez la version finale fusionnée à partir des différents éléments, puis git add et git commit.

Vérifiez ce qui s’est passé du point de vue du graphe avec git log --all --decorate --oneline --graph.

Pratique du merge

Clonez le dépôt: git@gitlab.enst.fr:slr201-git-adv/learning-merge.git

Il y a deux branches à merger dans master. Aucune des deux branches ne permet un merge automatique.

En cours, les deux merges ont été faits devant vous.

Clairement, pour cet exercice, utiliser un outil graphique est plus facile. Utilisez Smartgit en version gratuite, son outil de gestion des conflits est vraiment bien.

Faites le merge simple:

git checkout master
git merge refac1

Puis faites la résolution de conflits jusqu’à ce que git status vous dise qu’il n’y a plus de conflits, ou que votre outil graphique n’ait plus de fichier marqué comme en conflit.

Puis git merge --abort pour effacer.

Puis faites le merge complexe:

git checkout master
git merge refactor

Puis faites la résolution de conflits jusqu’à ce que git status vous dise qu’il n’y a plus de conflits, ou que votre outil graphique n’ait plus de fichier marqué comme en conflit. Dans ce merge, le choix entre l’une ou l’autre version n’est pas suffisant: il faut mélanger.

Et voilà. Vous avez fait deux vrais merges réalistes.

Fin du premier TP.