Git : gestion de versions

En bref

Résumé de l’article

Git enregistre l’histoire d’un projet sous forme de versions successives, appelées commits, et permet à plusieurs personnes de travailler sur les mêmes fichiers sans se marcher dessus. Cet article présente les quatre zones qu’il faut avoir en tête – répertoire de travail, index, dépôt local, dépôt distant – puis les commandes qui font passer votre travail d’une zone à la suivante.

La dernière partie traite des conflits : ce qui les provoque, ce que Git affiche, et ce que vous avez à faire. Un conflit n’est pas une panne, c’est le moment où Git vous demande une décision qu’il ne peut pas prendre à votre place.

Points clés à retenir

• Un commit est une version locale. Rien n’est envoyé sur le serveur avant un push, et rien n’est enregistré avant un commit.
• L’index (staging) est une étape volontaire : git add sert à choisir ce qui entrera dans la prochaine version, fichier par fichier.
• git status répond à presque toutes les questions. Prenez le réflexe de le taper avant et après chaque commande.
• pull avant de push. Plus vous récupérez souvent le travail des autres, moins les divergences à résoudre sont grosses.
• Les conflits se résolvent toujours en local, puis se propagent par un add, commit, push ordinaire.

Contenu de l’article

Ce que Git gère, et ce que GitLab ajoute

Git est un système de contrôle de version distribué gratuit et open source conçu pour gérer tout, des petits aux très grands projets, avec rapidité et efficacité.

(source : git-scm.com)

L’objectif de l’utilisation de Git avec une plateforme de développement collaboratif comme GitLab est de permettre à différentes personnes de travailler sur un projet commun (partage), et de s’assurer que tout le travail précédent reste disponible à tout moment (versionnage).

Avec Git, les fichiers sont organisés en dépôts (repositories). On crée un dépôt Git sur la plateforme pour héberger les fichiers d’un projet, et chaque contributeur(rice) du projet dispose d’un dépôt local qui est une copie de ce dépôt distant.

Les quatre zones

• Le répertoire de travail (working tree) est le dossier local contenant les fichiers sur lesquels vous travaillez : codes sources, documentation, images…
• L’index (staging) contient les modifications que vous avez choisi de faire entrer dans la prochaine version.
• Le dépôt local contient toutes les versions déjà enregistrées. Chaque version est un commit.
• Le dépôt distant est un autre dépôt Git, souvent hébergé sur une plateforme web dédiée (GitLab, GitHub…). C’est lui que partagent toutes les personnes travaillant sur le projet.

Comprendre ces quatre zones, c’est comprendre Git : chaque commande ne fait que déplacer du contenu de l’une vers la suivante.

Le déroulé le plus simple

1. Créer un projet dans GitLab ; un dépôt Git distant est créé au passage.

2. Cloner (clone) ce dépôt distant sur votre ordinateur.

   

3. Les autres membres du projet clonent également le dépôt pour travailler en parallèle.

4. Indiquer à Git le travail local à retenir (add) : les fichiers concernés entrent dans l’index.

   

5. Créer une version locale (commit) accompagnée d’un message décrivant le changement.

   

6. Envoyer cette version vers le dépôt distant (push).

   

7. Les autres récupèrent ces modifications (pull) pour mettre à jour leur dépôt local.

   

8. Résoudre localement les conflits lorsque deux personnes ont fait des modifications incompatibles.

Cloner un dépôt distant existant

git clone <url du depot distant>

git clone <url du depot distant>

git clone <url du depot distant>

git clone <url du depot distant>

Documentation détaillée : git-scm.com/docs/git-clone.

Créer un dépôt local et l’associer à un dépôt distant

Vous pouvez créer un dépôt Git n’importe où sur votre ordinateur, sauf à l’intérieur d’un dépôt existant :

cd chemin\vers\mon\projet
git init

cd chemin\vers\mon\projet
git init

cd chemin/vers/mon/projet
git init

cd chemin/vers/mon/projet
git init

Un dépôt créé de cette façon n’a encore aucun dépôt distant. Pour lui en associer un, puis vérifier la liste des dépôts distants connus :

git remote add origin <url du depot distant>
git remote -v

git remote add origin <url du depot distant>
git remote -v

git remote add origin <url du depot distant>
git remote -v

git remote add origin <url du depot distant>
git remote -v

Par convention, origin est le nom donné au dépôt distant principal. Un dépôt local peut être associé à plusieurs dépôts distants. Documentation détaillée : git-scm.com/docs/git-init et git-scm.com/docs/git-remote.

Connaître l’état de son dépôt

git status

git status

git status

git status

Cette commande vous dit, en une fois : sur quelle branche vous êtes, quels fichiers sont modifiés mais pas encore dans l’index, quels fichiers sont dans l’index, quels fichiers Git ignore, et si votre dépôt local est en avance ou en retard sur le distant. Elle propose en général la commande suivante à taper. Documentation détaillée : git-scm.com/docs/git-status.

Ajouter des modifications à l’index

git add fichier1.py fichier2.py
git add .

git add fichier1.py fichier2.py
git add .

git add fichier1.py fichier2.py
git add .

git add fichier1.py fichier2.py
git add .

La forme git add . ajoute tout ce qui a changé dans le dossier courant et ses sous-dossiers. Elle est pratique mais aveugle : relisez git status avant de l’utiliser. Documentation détaillée : git-scm.com/docs/git-add.

Créer une version avec un message

git commit -m "Ajoute l'operation modulo a la calculatrice"

git commit -m "Ajoute l'operation modulo a la calculatrice"

git commit -m "Ajoute l'opération modulo à la calculatrice"

git commit -m "Ajoute l'opération modulo à la calculatrice"

Documentation détaillée : git-scm.com/docs/git-commit.

Envoyer ses versions vers le dépôt distant

git push origin main

git push origin main

git push origin main

git push origin main

Documentation détaillée : git-scm.com/docs/git-push.

Récupérer le travail des autres

Si quelqu’un a poussé des modifications sur le dépôt distant, il faut les récupérer avant de pouvoir envoyer les vôtres. Deux façons de faire :

• fetch met à jour votre dépôt local, mais pas vos fichiers. Il faut ensuite un merge pour mettre le répertoire de travail à jour.
• pull fait les deux d’un coup. C’est plus court, et c’est là que les conflits apparaissent.

git fetch
git merge origin main

git pull

git fetch
git merge origin main

git pull

git fetch
git merge origin main

git pull

git fetch
git merge origin main

git pull

Documentation détaillée : git-fetch, git-merge, git-pull.

Ce que Git ne versionne pas

Un dépôt ne doit contenir que ce qui est nécessaire pour reconstruire le projet : votre code, vos données d’exemple, votre documentation. Tout ce qui se régénère automatiquement – un environnement virtuel .venv, des fichiers compilés, des caches – n’a rien à y faire : c’est volumineux, propre à votre machine, et cela provoque des conflits inextricables.

C’est le rôle du fichier .gitignore, placé à la racine du dépôt : il liste des motifs de fichiers que Git ignorera complètement. Ils n’apparaîtront ni dans git status, ni dans un git add ..

# .gitignore produit par uv
.venv
__pycache__/
*.py[oc]

uv init crée ce fichier pour vous, avec les bonnes valeurs pour un projet Python. Vous verrez en activité pratique que c’est exactement ce qui vous évite d’envoyer votre environnement virtuel sur le serveur.

En cas de conflits

Les divergences entre dépôt local et dépôt distant sont gérées par l’action merge. Commençons par le cas simple : votre commit est en retard sur le dernier commit distant, mais aucune ligne n’est touchée deux fois. Le pull fusionne alors les deux histoires tout seul, et vous pouvez pousser. Le merge est transparent, Git le fait pour vous.

Parfois, le conflit est dans le code lui-même : deux personnes ont modifié les mêmes lignes du même fichier. Voici ce que Git affiche lorsque vous tentez de pousser dans cette situation :

$ git push origin main
To gitlab-df.imt-atlantique.fr:exemple/projet.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'gitlab-df.imt-atlantique.fr:exemple/projet.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.

Puis, au pull, Git vous demande comment réconcilier les deux histoires :

$ git pull
hint: You have divergent branches and need to specify how to reconcile them.
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
fatal: Need to specify how to reconcile divergent branches.

La plupart du temps, et pour cette séance, la réponse est de fusionner (merge). S’il n’y a pas de conflit ligne à ligne, Git s’en sort seul :

$ git merge
Merge made by the 'ort' strategy.
 calculator.py | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

S’il y a un vrai conflit, il vous le dit et s’arrête :

$ git merge
Auto-merging calculator.py
CONFLICT (content): Merge conflict in calculator.py
Automatic merge failed; fix conflicts and then commit the result.

Git insère alors dans le fichier des marqueurs délimitant les deux versions concurrentes :

<<<<<<< HEAD
    return a % b          # votre version
=======
    return a - b * (a // b)   # la version récupérée
>>>>>>> origin/main

À vous de choisir : gardez l’une, l’autre, ou écrivez une troisième version, puis supprimez les marqueurs. Git ne peut pas décider à votre place, mais il vous montre précisément où trancher – et Visual Studio Code propose pour cela un éditeur de fusion côte à côte.

Documentation détaillée : git-scm.com/docs/git-merge.

Pour aller plus loin

Éviter les conflits plutôt que les résoudre

Deux habitudes réduisent énormément le nombre de conflits :

• pull souvent, push souvent. Plus vous synchronisez, moins votre histoire locale diverge, et plus les fusions sont petites.
• Parlez-vous. Mieux les tâches sont réparties – « toi le menu, moi les opérations » –, moins vous éditez les mêmes lignes en même temps. La plupart des conflits sont un problème d’organisation avant d’être un problème d’outil.

Retrouver qui a écrit quoi

git log déroule l’historique, et git blame indique pour chaque ligne d’un fichier le commit, l’auteur(e) et la date de sa dernière modification :

git log --oneline --graph --all
git blame calculator.py

git log --oneline --graph --all
git blame calculator.py

git log --oneline --graph --all
git blame calculator.py

git log --oneline --graph --all
git blame calculator.py

C’est précieux en phase de débogage : vous voulez savoir quand une ligne est apparue, et avec quel message elle a été justifiée.

Le livre de référence

Le livre Pro Git est disponible gratuitement et en français. Les chapitres 2 et 3 couvrent tout ce qui précède, avec beaucoup plus de détails et les cas particuliers.