TP B-A-ba Git

的 Joseph Razik, last modified 在 2026-02-13

1   Objectif

L'objectif de ce TP est de découvrir l'outil de versionning GIT et ses commandes de bases, et lier son projet à un dépôt distant tel que gitlab.

2   Configuration minimale

Pour une utilisation simple il y a peu de chose à configurer et cela évitera à git de vous le demander à chaque fois.

  • Configuration du nom d’utilisateur :

    git config --global user.name "Votre Nom"

  • Configuration de l’adresse Email :

    git config --global user.email "votre.email@example.com"

  • Configuration de la branche par défaut :

    git config --global init.defaultBranch main

Vous pouvez vérifier la configuration actuelle de git avec la commande suivante :

git config --list

3   Création d'un dépôt local

Le principe de git est de travailler dans un dépôt (repository) dans lequel il va suivre les modifications et gérer les différentes versions de votre projet.

Pour initialiser un dépôt git, il faut se placer dans le répertoire de travail et faite la commande

$> git init

Voilà c'est fini, le répertoire est devenu un répertoire suivi.

En apparence rien n'a changé mais si on affiche les fichiers et répertoires cachés on verra l'existence d'un répertoire .git/ qui contient ce qui est nécessaire à git.


La convention de base est de placer dans votre répertoire / dépôt un fichier README décrivant votre projet. Celui-ci est un simple fichier textuel qui peut suivre des formats de mise en page tels que Markdown, ReStructuredText, Org-mode ou rien.

4   Premiers pas

  1. Créez dans /tmp/ un répertoire de travail pour votre projet nommé Test,
  2. Transformez ce répertoire en dépôt local git,
  3. Créez un fichier README.txt avec un peu de contenu.

Et ensuite ? et git là-dedans ?

Pour le moment rien de spécial, votre fichier est là et c'est tout. L'étape suivante consiste à indiquer à git de suivre le fichier README.txt.


La commande la plus importante de git :

git status

Cette commande vous indique :

  • les fichiers non suivis,
  • les fichiers suivi modifiés (nouveaux, modifiés, effacés) depuis le dernier commit (point de validation des modifications, c'est-à-dire la dernière version connue de git).

Pour ajouter un fichier à suivre il faut utiliser la commande :

git add fichier

Dorénavant votre fichier sera suivi par git.


Le principe de git n'est pas de conserver le moindre changement dans votre fichier mais uniquement son état au moment où vous le décidez. La convention est de ne faire conserver par git que des modifications finalisées, pas des versions inachevées. Par exemple si on doit ajouter une fonction, on ne fera conserver que la version avec la fonction totalement écrite, pas quand elle n'est qu'à moitié écrite.

Ces versions s'appellent des commit, et donc si faite un commit vous validez vos modifications. À chaque opération commit (point de sauvegarde) est associé un numéro qui va permettre d'identifier chaque commit pour d'autres commandes.

git commit -m "description du commit"
  1. Vérifiez l'état de suivi de votre projet,
  2. Ajoutez le fichier README.txt comme étant un fichier à suivre,
  3. Vérifiez l'état de suivi de votre projet,
  4. Validez l'ajout du fichier README.txt,
  5. Modifiez le fichier README.txt,
  6. Vérifiez l'état de suivi de votre projet,
  7. Validez votre modification,
  8. Vérifiez l'état de suivi de votre projet.

Il est possible de suivre les différentes versions validées avec la commande:

git log

On remarque l'intérêt des commentaire pour ainsi suivre ce qu'il s'est passé dans le projet.

5   Seconds pas

Le message associé à un commit décrit succinctement ce qui a été ajouté à ce nouveau point de sauvegarde. Pour connaître le détail de ce qui a changé il existe la commande

git diff

Cette commande permet d'afficher les différences entre deux version du projet ou d'un fichier. Cela peut être entre la version de travail et le dernier commit, entre deux commits, etc.

  1. Modifiez de nouveau votre fichier README.txt,
  2. Visualisez les différences avec le dernier commit,
  3. Visualisez les différences avec le premier commit,
  4. Visualisez les différences entre le premier et le second commit.

Il est possible d'indiquer à git d'ignorer la présence de certains fichiers qui n'ont pas besoin d'être suivi. C'est le cas par exemple des fichiers compilés à partir d'un fichier .c.


Pour cela il est possible de créer un fichier .gitignore à la racine de votre projet et d'indiquer dedans les fichiers (ou motifs de fichiers) à ignorer.

  1. Créez un fichier C qui affiche « bonjour »,
  2. Compilez le en un exécutable d'extension .exe,
  3. Vérifiez l'état de suivi de votre projet,
  4. Créez le fichier .gitignore afin d'ignorer tous les fichiers se terminant par .exe,
  5. Vérifiez l'état de suivi de votre projet,
  6. Validez (versionnez) l'ajout du fichier .gitignore,
  7. Validez (versionnez) l'ajout du fichier .c,
  8. Visualisez l'historique des versions.

6   Dépôt distant

Git est aussi et surtout fait pour travailler à plusieurs sur un même projet. Pour cela il faut un dépôt centralisé en plus de chaque dépôt local.

Principalement deux méthodes existent:

  • mettre en place un serveur git,
  • utiliser une forge, c'est-à-dire un serveur mais avec une interface et des outils de gestion de projet.

Une forge GitLab a été installée sur le machine http://sinfo7.univ-tln.fr. Le but de la forge n'est pas d'éditer votre projet dans celle-ci mais uniquement de suivre votre projet.

6.1   Authentification par clé SSH

Pour plus de sécurité, et pour ne plus entrer votre mot de passe sans arrêt, il est possible d'utiliser une authentification par clé SSH.


Pour cela déposez votre clé SSH publique (dans ~/.ssh/) sur de serveur git.

6.2   Lier un projet local à un dépôt distant

Deux cas apparaissent : soit votre projet était déjà versionné mais uniquement localement, soit votre projet n'est pas encore versionné.

Votre projet est déjà versionné

Dans ce cas:

  • créez un projet vide sur la forge,

  • lié votre projet local à celui sur la forge avec la commande suivante si vous n'avez pas mis votre clé SSH

    git remote add origin http://sinfo7.univ-tln.fr/{nom d'utilisateur}/{nom_projet}.git
git push --set-upstream origin main

ou si vous avez mis votre clé SSH

git remote add origin git@sinfo7.univ-tln.fr:{nom d'utilisateur}/{nom_projet}.git
git push --set-upstream origin main

Votre projet n'est pas encore versionné

Dans ce cas:

  • créez un projet vide sur la forge

  • clonez le projet existant

    git clone http://sinfo7.univ-tln.fr/{nom d'utilisateur}/{nom_projet}.git

ou si vous avez mis votre clé SSH

git clone git@sinfo7.univ-tln.fr:{nom d'utilisateur}/{nom_projet}.git
  • ensuite soit vous travaillez dans le répertoire créé, soit vous y déplacez votre projet local, soit vous copiez dans votre projet le répertoire .git.

On peut ensuite synchroniser les dépôts avec les commandes

git push

pour envoyer vos nouveaux commit locaux vers le serveur distant

git pull

pour récupérer les nouveaux distant à votre projet local.


Il faut bien faire attention à ce que les dépôts évoluent de manière synchronisée, sinon vous rencontrerez des conflits qui peuvent être difficiles à résoudre pour reconstruire un suivi de version cohérent.

6.3   Travail à plusieurs

Pour éviter les conflits, il est préférable de mettre en place des règles de fonctionnement, comme par exemple ne pas travailler en même temps sur le même fichier, ou bien utiliser des branches avec une personne responsable des fusions.


Les branches permettent de créer des évolutions parallèles du projet à partir d'un commit commun, pour plus tard intégrer les modifications proposées dans la branche vers la racine du projet par une fusion.

Avant de fusionner il faudra intégrer les évolutions de la branche principale. Dans les fait, une branche est un pointeur vers un commit.


Les commandes manipulant les branches sont les suivantes :

git branch    # lister les branches existantes, avec * devant celle active
git branch nom_de_branche     # créer une nouvelle branche
git switch nom_de_branche     # se placer sur une autre branche
git merge nom_de_branche      # fusionne la branche indiquée dans la branche active

Si vous avez des fichiers en conflits (modifications sur une même partie de fichier), les fichiers incriminés contiendront des sections marquées par <<<<<<<, =======, et >>>>>>> pour indiquer les parties en conflit issues de la branche principale et de la modification locale.

Il faudra les résoudre manuellement (corriger pour ne plus avoir de tels marqueurs) et générer un nouveau commit.

Lien vers un site proposant des tutoriaux sur le branching https://learngitbranching.js.org/?locale=fr_FR .