TP3 : Synchronisation à distance et ignorer des fichiers
Objectifs¶
Le but de ce TP est de comprendre les concepts et les commandes suivantes :
Graphe d’historique¶
Pour mieux comprendre cette notion, nous allons regarder le graphe de l’historique des versions de notre projet courant.
Exécutez
git log --onelinepour afficher l’historique du dépôt où chaque commit correspond à une ligne commençant par un code, appelé commit hash, permettant d’identifier le commit, suivi du message du commit.
q
qPetit rappel : q pour quitter le log.
Exécutez
git log --oneline --graphpour voir le graphe (dessiné en ASCII dans le terminal) associé à ces commits, où chaque sommet est représenté par une étoile.
Votre graphe devrait être linéaire (un chemin).
Lorsque vous apprendrez à gérer plusieurs branches dans votre dépôt, vous pourrez ajouter les options --decorate (pour afficher le nom de la branche à côté des commits) et --all (pour voir toutes les branches) à la commande git log --oneline --graph.
Définissez la nouvelle commande
git graphen tant qu’alias de la manière suivante :
git config --global alias.graph "log --oneline --graph --decorate --all"N’abusez pas les alias
Ne créez pas d’alias pour chaque commande, car vous pourriez oublier les commandes standard et le vocabulaire après un certain temps. Dans ce cours, nous n’utiliserons les alias que lorsque cela est explicitement mentionné.
Exécutez
git graph.
Diff et Pull¶
Rendez vous sur le Remote Repo sur GitLab.
Cliquez sur Code puis Web IDE dans Open with.
Créez un nouveau répertoire
TP3/et un fichierhello-world.cppavec le code suivant.
#include <iostream>
using namespace std;
int main() {
cout << "Hello World!" << endl;
return 0;
}Vous pouvez voir un 1 sur la barre à gauche, indiquant qu’un changement a été effectué.
Si vous cliquez dessus, vous verrez un changement concernant le fichier hello-world.cpp et l’option pour sauvegarder et diffuser sur la branche main (Commit and push to ‘main’).
Ajoutez un message de commit.
Cliquez sur le bouton Commit and push to ‘main’.
Cliquez sur Continue lorsque l’on vous demande si vous souhaitez sauvegarder sur la branche par défaut (main).
Retournez sur votre Local Repo et supposons qu’un collaborateur a effectué des changements, puis les a diffusés sur le Remote Repo sans que vous en soyez informé.
Exécutez
git fetch, puisgit status.
Commencez par git fetch && git status !
git fetch && git status !En pratique, lorsque vous travaillez sur un projet, il est fréquent qu’entre deux sessions de travail, quelqu’un d’autre ait modifié une partie du code. Si vous commencez une session de travail sans vérifier l’état de vos dépôts, vous risquez de rencontrer des conflits à résoudre (par exemple, si vous modifiez les mêmes parties de code de manière différente).
Bien que nous allons parler de la résolution de conflits dans ce cours, il est préférable de les éviter. C’est pourquoi il est essentiel de toujours commencer par git fetch && git status avant de décider ce qu’il faut faire !
Vous pouvez également exécuter git diff origin/main pour voir précisément les modifications qui ont été effectuées.
Exécutez
git diff origin/mainpour voir les différences entre les deux dépôts.
git diff
git diffLa commande git diff origin/main nous montre la différence entre la version courante de nos fichiers (dans le Working Tree) avec la version des mêmes fichiers dans le Remote Repo (vu localement à travers la remote-tracking branch, autrement dit, la version connue depuis la dernière commande git fetch). Vous pouvez naviguer ce diff dans le terminal à l’aide des flèches sur votre clavier.
Le diff est affiché comme suit :
La ligne index correspond à des identifiants internes de Git. Ce n’est pas utile pour une lecture normale.
Le préfixe
a/correspond à la version dansorigin/main.Le préfixe
b/correspond à la version dans le Working Tree.Si le fichier a été créé ou supprimé, alors il n’existe que dans l’une des deux versions, et donc
a/oub/peuvent être remplacés par/dev/null.Les blocs
@@ -ligneVersionA,nbLignes +ligneVersionB,nbLignes @@indiquent les lignes modifiées. Par exemple@@ -1,4 +2,8 @@que la zone qui commence de la ligne 1 et qui dure 4 lignes dans le fichier venant dea/a été modifiée et elle correspond maintenant à la zone qui commence de la ligne 2 et qui dure 8 lignes dans le même fichier mais dans la versionb/.Une ligne qui commence par
-en rouge est une ligne dea/qui n’est pas dansb/.Une ligne qui commence par
+en vert est une ligne deb/qui n’est pas dansa/.Une ligne blanche indique une ligne qui n’a pas changé.
Pour télécharger les modifications sur le Remote Repo qui ne sont pas encore sur votre Local Repo, exécutez
git pull.
Show¶
Exécutez
git graphpour voir le graphe d’historique de votre projet.
Choisissez un commit hash d’un commit passé et exécutez
git show <commit hash>. Observez.
Par exemple:
git show acbd123Rappel q pour quitter
q pour quitterQuand vous ouvrez des logs avec git log, git graph, git diff ou git show, vous pouvez utiliser la touche q pour quitter.
Pour voir un fichier spécifique dans un commit passé, exécutez
git show <commit hash>:<fichier>.
Par exemple :
git show acbd123:TP1/my-first-file.txtIgnorer des fichiers¶
Ouvrez le répertoire
TP3/où se trouve le fichierhello-world.cpp.Compilez le code avec
g++ -o <nom du fichier> <nom du fichier>.cpp.
Par exemple :
g++ -o hello-world hello-world.cppExécutez l’exécutable
hello-worldavec la commande./hello-world.
Les exécutables font partie des fichiers que nous souhaitons ignorer.
Pourquoi ignorer des fichiers ?
Lors du développement, certains fichiers doivent être systématiquement ignorés (par exemple, les fichiers générés lors de la compilation), car ils encombrent inutilement le dépôt.
Par exemple, un moteur de jeu complexe comme Unity peut nécessiter jusqu’à 1 Go de fichiers pour exécuter certains modules, parfois inutilisés par votre jeu. Si ces fichiers ne sont pas ignorés, vous pourriez être contraint de télécharger ou de diffuser 1 Go à chaque synchronisation de vos dépôts, alors que les fichiers spécifiques à votre jeu ne représentent que quelques Mo.
Les fichiers de configurations peuvent également provoquer des problèmes de compatibilité, notamment lorsque vous synchronisez des fichiers de configuration spécifiques à certaines machines avec d’autres.
Créez le fichier
.gitignore.
Pourquoi .gitignore commence par un . ?
.gitignore commence par un . ?Les fichiers dont les noms commencent par . sont des fichiers cachés (qui ne s’affichent pas quand vous utilisez un gestionnaire de fichiers). Ce sont souvent des fichiers de configurations.
Pour afficher les fichiers cachés dans un gestionnaire de fichiers, vous pouvez souvent appuyer sur Ctrl + H (comme ‘Hidden’).
Le répertoire .git est ignoré par Git de manière native.
Écrivez le nom de l’exécutable
hello-worlddans.gitignore.
Si votre éditeur a généré d’autres fichiers à ignorer...
Dans ce cas, il faut ajouter les noms de ces fichiers ou répertoires dans .gitignore.
Par exemple, .vscode, .vsconfig, etc.
Exécutez
git add .gitignore,git commit -m "<message>"etgit pushpour envoyer le fichier.gitignoresur le Remote Repo.Exécutez
git status. Qu’est-ce qui change par rapport à d’habitude ?
Où sont mes fichiers non suivis ?
Normalement, comme nous n’avons pas ajouté l’exécutable hello-world avec git add, git status nous indique qu’il y a un fichier non suivi, potentiellement important. Cependant, grâce au fichier .gitignore, Git reconnaît que nous avons choisi d’ignorer hello-world et ne suivra jamais les modifications apportées à ce fichier.
Remplacez le code du fichier
.gitignoreavec le code suivant.
*
!*.*
!*/Je dois ignorer d’autres types de fichiers...
Vous avez peut-être utilisé un éditeur qui génère d’autres types de fichiers à ignorer, en plus des fichiers sans extension que nous avons déjà exclus avec le code ci-dessus.
Par exemple, si des fichiers .o ont été générés et que vous souhaitez les ignorer à l’avenir, ajoutez la ligne suivante à votre fichier .gitignore
*.o*.opermettent d’ignorer tous les fichiers portant cette extension.
Autre exemple : si votre éditeur a généré un dossier build/, vous pouvez ajouter la ligne suivante :
build/Cela exclura tout le contenu des dossiers nommés build, quel que soit leur emplacement dans le projet.
Vous pouvez même tout combiner pour ignorer à la fois les fichiers sans extension, les fichiers .o et les dossiers build/ (ainsi que leur contenu) avec les expressions suivantes pour votre .gitignore.
*
!*.*
!*/
*.o
build/Exécutez
add,commitetpushpour synchroniser vos dépôts.
Supprimer des fichiers¶
Ouvrez le répertoire
TP3/et créez un fichierto-be-removed.txt.Add, commit, et push ce fichier sur le Remote Repo.
git rm
git rmVous pouvez utiliser git rm <nom du fichier> pour supprimer un fichier qui a déjà été synchronisé sur les deux dépôts. git rm fonctionne de manière similaire à git add, mais pour supprimer des fichiers. Ensuite, vous pouvez faire un git commit suivi d’un git push, comme d’habitude, pour diffuser ces changements (suppressions).
Un fichier qui se trouve uniquement sur le Working Tree peut être supprimé simplement via un gestionnaire de fichiers ou avec la commande rm (sans git). Si vous avez déjà ajouté (git add) ce fichier aux modifications suivies (staged changes), vous pouvez le retirer grâce à git restore --staged <nom du fichier>.
Supprimez le fichier
to-be-removed.txtet synchronisez avec le Remote Repo.
Dans votre Local Repo et Remote Repo, vous devez maintenant avoir la structure suivante (sans tenir compte du .git caché qui doit être dans tous les projets suivis par Git) :
TP1/
├── my-first-file.txt
├── my-second-file.txt
TP2/
├── <un fichier texte>.txt
TP3/
├── hello-world.cpp
.gitignoreD’autres fichiers peuvent être présents sur votre Working Tree mais vérifiez bien qu’ils sont ignorés (dans le .gitignore et puis avec git status).
Si vous avez des fichiers indésirables, supprimez-les et synchronisez avec le Remote Repo.
Revenez aux objectifs et cochez les points que vous avez maîtrisés. Entraînez-vous sur les commandes et les notions que vous n’avez pas encore bien comprises. Faites appel à votre encadrant si besoin.
Quiz !
N’oubliez pas de compléter le quiz du TP sur Moodle !