Activité pratique

Consignes globales

Cette activité se déroule en deux parties. La première se fait seul(e), la seconde en binôme (un trinôme au maximum si le compte est impair).

Le fil conducteur est un projet uv, comme celui que vous avez créé en séance 2. Ce n’est pas un détail de mise en scène : uv init place d’emblée votre projet sous contrôle de version, et le .gitignore qu’il écrit répond à la question la plus importante du versionnage – qu’est-ce qu’on partage, et qu’est-ce qu’on ne partage pas ?

En première partie, vous versionnez ce projet seul(e) et le publiez sur GitLab. En seconde partie, vous travaillez à deux sur le même dépôt, vous provoquez délibérément des conflits, et vous les résolvez.

Contenu de l’activité

Versionner un projet uv

Cette partie se fait en autonomie. Elle vous fait parcourir seul(e) le cycle complet : créer, enregistrer, publier, puis vérifier que quelqu’un d’autre pourrait repartir de votre dépôt.

Installer Git

Git est un logiciel qui s’installe sur votre machine, indépendamment de GitLab qui n’est qu’un serveur. Il est peut-être déjà présent : c’est souvent le cas sous MacOS et Linux.

Sous Windows, gardez les valeurs par défaut proposées par l’installeur. Sous MacOS, si une fenêtre propose d’installer les « outils de développement en ligne de commande », acceptez : c’est ainsi que MacOS fournit Git.

Vérifier son installation

Vérifions maintenant que Git répond, ainsi que uv installé en séance 2.

git --version
uv --version

git --version
uv --version

git --version
uv --version

git --version
uv --version

Chaque commande doit afficher un numéro de version, 2.28 ou plus récent pour Git. Si Git n’est pas reconnu dans un nouveau terminal, ou si sa version est plus ancienne, appelez l’encadrant(e).

Configurer Git

Avant le premier commit, Git réclame deux réglages : votre nom et votre adresse électronique. C’est ce qu’il inscrira dans chacune de vos versions.

On vous demande également d’effectuer deux autres réglages pour garantir que Git se comportera de la même façon sur toutes les machines de la salle, quelle que soit sa version :

• init.defaultBranch main : donne le nom main à la branche créée avec chaque nouveau dépôt. Historiquement, Git l’appelait master ; l’usage est aujourd’hui main, et c’est ce qu’attend GitLab.
• pull.rebase false : indique à git pull de fusionner le travail distant avec le vôtre. Sans ce réglage, les versions récentes de Git refusent le pull dès que vous et votre binôme avez tous les deux travaillé, ce qui arrivera dans la seconde partie.

L’option --global enregistre ces réglages une fois pour toutes sur votre machine : vous n’aurez plus à y toucher, ni pour ce TP ni pour les suivants.

git config --global user.name "Prénom Nom"
git config --global user.email prenom.nom@imt-atlantique.net
git config --global init.defaultBranch main
git config --global pull.rebase false
git config --list --show-origin

git config --global user.name "Prénom Nom"
git config --global user.email prenom.nom@imt-atlantique.net
git config --global init.defaultBranch main
git config --global pull.rebase false
git config --list --show-origin

git config --global user.name "Prénom Nom"
git config --global user.email prenom.nom@imt-atlantique.net
git config --global init.defaultBranch main
git config --global pull.rebase false
git config --list --show-origin

git config --global user.name "Prénom Nom"
git config --global user.email prenom.nom@imt-atlantique.net
git config --global init.defaultBranch main
git config --global pull.rebase false
git config --list --show-origin

La dernière commande doit afficher, parmi d’autres, les lignes user.name=..., user.email=..., init.defaultbranch=main et pull.rebase=false. Si l’une manque ou contient une faute de frappe, relancez simplement la commande correspondante : la nouvelle valeur remplace l’ancienne.

Créer un projet et découvrir le dépôt qu’il contient

uv init ne fait pas que préparer un projet Python : il exécute aussi git init pour vous. Vous allez donc vous trouver, sans avoir tapé une seule commande Git, dans un dépôt déjà constitué.

Les commandes ci-dessous supposent que votre arborescence est dans Documents, comme dans l’exemple de la séance 2. Si vous l’avez rangée ailleurs, adaptez le chemin de la première commande. La commande suivante affiche le dossier dans lequel se trouve votre terminal : vérifiez qu’il se termine bien par calculatrice avant d’aller plus loin.

:: Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd %USERPROFILE%\Documents\imt\s5\info\env\session3\calculatrice
cd

:: Initialiser un projet uv
uv init --no-package

:: Vérifier que uv a bien préparé le dépôt Git du projet
git rev-parse --show-toplevel
git status

# Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd ~\Documents\imt\s5\info\env\session3\calculatrice
pwd

# Initialiser un projet uv
uv init --no-package

# Vérifier que uv a bien préparé le dépôt Git du projet
git rev-parse --show-toplevel
git status

# Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd ~/Documents/imt/s5/info/env/session3/calculatrice
pwd

# Initialiser un projet uv
uv init --no-package

# Vérifier que uv a bien préparé le dépôt Git du projet
git rev-parse --show-toplevel
git status

# Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd ~/Documents/imt/s5/info/env/session3/calculatrice
pwd

# Initialiser un projet uv
uv init --no-package

# Vérifier que uv a bien préparé le dépôt Git du projet
git rev-parse --show-toplevel
git status

git rev-parse --show-toplevel affiche le dossier racine du dépôt dans lequel vous vous trouvez. Il doit se terminer par calculatrice : c’est la preuve que le dépôt est celui de votre projet, et de rien d’autre.

Enregistrer une première version

Deux étapes séparent votre travail d’une version enregistrée : git add choisit ce qui entrera dans la version, git commit l’enregistre avec un message. Prenez le réflexe d’encadrer chaque commande par un git status, qui vous montre l’effet de ce que vous venez de faire.

git add .
git status
git commit -m "Initialise le projet uv de la calculatrice"
git log --oneline

git add .
git status
git commit -m "Initialise le projet uv de la calculatrice"
git log --oneline

git add .
git status
git commit -m "Initialise le projet uv de la calculatrice"
git log --oneline

git add .
git status
git commit -m "Initialise le projet uv de la calculatrice"
git log --oneline

Ajouter une dépendance et observer ce que Git en dit

C’est ici que le choix d’un projet uv prend tout son sens : une seule commande va modifier trois choses sur votre disque, et Git ne va en voir que deux.

uv add numpy
git status
git add pyproject.toml uv.lock
git commit -m "Ajoute numpy aux dependances du projet"

uv add numpy
git status
git add pyproject.toml uv.lock
git commit -m "Ajoute numpy aux dependances du projet"

uv add numpy
git status
git add pyproject.toml uv.lock
git commit -m "Ajoute numpy aux dépendances du projet"

uv add numpy
git status
git add pyproject.toml uv.lock
git commit -m "Ajoute numpy aux dépendances du projet"

Publier le projet sur GitLab

Votre dépôt est pour l’instant purement local, et il fonctionne très bien ainsi. Lui associer un dépôt distant ajoute deux choses : une sauvegarde ailleurs, et la possibilité de partager.

Connectez-vous sur https://gitlab-df.imt-atlantique.fr pour créer le projet. N’ajoutez pas de README : votre dépôt local a déjà son histoire, et un commit créé par GitLab entrerait immédiatement en conflit avec elle.

Dans le menu Code du projet, GitLab propose deux URL de clonage. Prenez celle en HTTPS : elle fonctionne immédiatement, votre adresse et votre mot de passe GitLab servant d’identifiants au premier push. Elle a la forme suivante :

https://gitlab-df.imt-atlantique.fr/<votre identifiant>/calculatrice.git

La première commande déclare le dépôt distant sous le nom origin, la deuxième affiche les dépôts distants déclarés pour vérification, et la dernière envoie votre branche main sur GitLab. Entre les deux, git branch -M main renomme votre branche courante en main : si Git l’a créée sous le nom master, ce qui arrive sur les machines dont Git est ancien ou mal configuré, le push échouerait sinon avec le message src refspec main does not match any. Si elle s’appelle déjà main, la commande ne fait rien.

git remote add origin https://gitlab-df.imt-atlantique.fr/<votre identifiant>/calculatrice.git
git remote -v
git branch -M main
git push -u origin main

git remote add origin https://gitlab-df.imt-atlantique.fr/<votre identifiant>/calculatrice.git
git remote -v
git branch -M main
git push -u origin main

git remote add origin https://gitlab-df.imt-atlantique.fr/<votre identifiant>/calculatrice.git
git remote -v
git branch -M main
git push -u origin main

git remote add origin https://gitlab-df.imt-atlantique.fr/<votre identifiant>/calculatrice.git
git remote -v
git branch -M main
git push -u origin main

git remote -v doit afficher deux lignes commençant par origin https://gitlab-df.imt-atlantique.fr/. Si l’adresse est fausse (mauvaise instance, faute de frappe, <votre identifiant> laissé tel quel), corrigez-la avec git remote set-url origin <bonne adresse> plutôt que de refaire un git remote add, qui échouerait car origin existe déjà.

Rechargez la page du projet sur GitLab : vos fichiers et vos commits doivent y être, sur la branche main.

Vérifier que le projet est reproductible

C’est le test qui compte : quelqu’un d’autre peut-il faire tourner votre code à partir du seul dépôt ? Jouons ce rôle en clonant votre propre projet ailleurs sur le disque.

:: Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd %USERPROFILE%\Documents\imt\s5\info\env\session3\essai
cd

:: Récupérer le projet depuis GitLab : un dossier calculatrice est créé ici
:: Changez <url du depot distant> (chevrons inclus) par l'url de votre depot
git clone <url du depot distant>
cd calculatrice

:: Reconstruire l'environnement, puis lancer le programme
uv sync
uv run python main.py

# Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd ~\Documents\imt\s5\info\env\session3\essai
pwd

# Récupérer le projet depuis GitLab : un dossier calculatrice est créé ici
git clone <url du depot distant>
cd calculatrice

# Reconstruire l'environnement, puis lancer le programme
uv sync
uv run python main.py

# Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd ~/Documents/imt/s5/info/env/session3/essai
pwd

# Récupérer le projet depuis GitLab : un dossier calculatrice est créé ici
# Changez <url du depot distant> (chevrons inclus) par l'url de votre depot
git clone <url du depot distant>
cd calculatrice

# Reconstruire l'environnement, puis lancer le programme
uv sync
uv run python main.py

# Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd ~/Documents/imt/s5/info/env/session3/essai
pwd

# Récupérer le projet depuis GitLab : un dossier calculatrice est créé ici
# Changez <url du depot distant> (chevrons inclus) par l'url de votre depot
git clone <url du depot distant>
cd calculatrice

# Reconstruire l'environnement, puis lancer le programme
uv sync
uv run python main.py

Travailler à plusieurs

Constituez un binôme. Dans ce qui suit, l’une des deux personnes est désignée comme A, l’autre comme B. Vous allez partir du dépôt de A et y travailler à deux.

Partager un dépôt

Donner accès à quelqu’un se fait entièrement côté GitLab : Git, lui, ne connaît pas la notion de membre. Le rôle Developer suffit pour pousser du code.

:: Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd %USERPROFILE%\Documents\imt\s5\info\env\session3\binome
cd

:: Récupérer le projet de A depuis GitLab
git clone <url du depot de A>
cd calculatrice

:: Reconstruire l'environnement, puis lancer le programme
uv sync
uv run python main.py

# Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd ~\Documents\imt\s5\info\env\session3\binome
pwd

# Récupérer le projet de A depuis GitLab
git clone <url du depot de A>
cd calculatrice

# Reconstruire l'environnement, puis lancer le programme
uv sync
uv run python main.py

# Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd ~/Documents/imt/s5/info/env/session3/binome
pwd

# Récupérer le projet de A depuis GitLab
git clone <url du depot de A>
cd calculatrice

# Reconstruire l'environnement, puis lancer le programme
uv sync
uv run python main.py

# Se placer au bon endroit dans le terminal (adaptez le chemin à votre organisation)
cd ~/Documents/imt/s5/info/env/session3/binome
pwd

# Récupérer le projet de A depuis GitLab
git clone <url du depot de A>
cd calculatrice

# Reconstruire l'environnement, puis lancer le programme
uv sync
uv run python main.py

Le dossier binome n’est pas un détail : B a déjà son propre dossier calculatrice dans session3, et git clone refuse d’écrire dans un dossier qui existe déjà. Pour toute la suite de la partie, B travaille dans binome/calculatrice.

Mettre du code dans le projet

Le projet ne contient encore que le main.py d’exemple. Ajoutons-y de quoi travailler à deux.

"""Une calculatrice minimale, en ligne de commande."""

def addition(a, b):
    return a + b

def soustraction(a, b):
    return a - b

def multiplication(a, b):
    return a * b

def division(a, b):
    if b == 0:
        return "Erreur : division par zéro."
    return a / b

def main():
    print("Bienvenue dans la calculatrice !")
    print("1. Addition")
    print("2. Soustraction")
    print("3. Multiplication")
    print("4. Division")

    choix = input("Votre choix (1/2/3/4) : ")
    if choix not in ["1", "2", "3", "4"]:
        print("Choix invalide.")
        return

    a = float(input("Premier nombre : "))
    b = float(input("Second nombre : "))
    operations = {"1": addition, "2": soustraction, "3": multiplication, "4": division}
    print(f"Résultat : {operations[choix](a, b)}")

if __name__ == "__main__":
    main()

git add calculatrice.py
git commit -m "Ajoute la calculatrice et ses quatre operations"
git push

git add calculatrice.py
git commit -m "Ajoute la calculatrice et ses quatre operations"
git push

git add calculatrice.py
git commit -m "Ajoute la calculatrice et ses quatre opérations"
git push

git add calculatrice.py
git commit -m "Ajoute la calculatrice et ses quatre opérations"
git push

Provoquer un conflit sur les dépendances

Voici un conflit très fréquent en projet, et propre aux projets uv : deux personnes ajoutent une bibliothèque en même temps. Le premier push passe, le second est refusé.

uv add scipy
git add pyproject.toml uv.lock
git commit -m "Ajoute une dependance"
git push

uv add scipy
git add pyproject.toml uv.lock
git commit -m "Ajoute une dependance"
git push

uv add scipy
git add pyproject.toml uv.lock
git commit -m "Ajoute une dépendance"
git push

uv add scipy
git add pyproject.toml uv.lock
git commit -m "Ajoute une dépendance"
git push

La personne dont le push est refusé récupère le travail de l’autre avec git pull --no-rebase. L’option n’est pas un détail : si Git est configuré pour rebaser par défaut sur votre machine, la suite de cet exercice ne se déroulerait pas comme décrit ici, et --ours ne désignerait plus la même version. Avec elle, tout le monde part du même état.

Le pull signale alors un conflit dans uv.lock, et le plus souvent un autre dans pyproject.toml.

git checkout --ours uv.lock
uv lock
git add pyproject.toml uv.lock
git commit -m "Fusionne les dependances scipy et matplotlib"
git push

git checkout --ours uv.lock
uv lock
git add pyproject.toml uv.lock
git commit -m "Fusionne les dependances scipy et matplotlib"
git push

git checkout --ours uv.lock
uv lock
git add pyproject.toml uv.lock
git commit -m "Fusionne les dépendances scipy et matplotlib"
git push

git checkout --ours uv.lock
uv lock
git add pyproject.toml uv.lock
git commit -m "Fusionne les dépendances scipy et matplotlib"
git push

L’autre personne termine par un git pull puis un uv sync, et vérifie que scipy et matplotlib sont disponibles.

Provoquer un conflit sur le code

Le conflit précédent portait sur des fichiers de configuration. Voyons maintenant celui que vous rencontrerez le plus souvent : deux personnes modifient les mêmes lignes du même fichier de code.

• Tâche 1 – Ajouter une opération modulo, qui renvoie le reste de la division du premier nombre par le second, et l’ajouter au menu et au dictionnaire operations.
• Tâche 2 – Valider les entrées : refuser proprement une saisie qui n’est pas un nombre, en affichant un message clair plutôt qu’une trace d’erreur.

Faites ensuite un git pull --no-rebase, ouvrez le fichier dans VS Code et utilisez l’éditeur de fusion pour construire une version qui contient les deux contributions. Terminez par le cycle habituel add, commit, push, et vérifiez que le binôme récupère bien le résultat.

Documenter le projet

GitLab affiche automatiquement le fichier README.md placé à la racine du dépôt, sur la page d’accueil du projet. C’est la première chose que verra quelqu’un qui découvre votre travail – correcteur(rice) inclus(e).

Votre README.md doit contenir au minimum :

1. ce que fait le projet, en deux phrases ;
2. comment l’installer et le lancer – soit exactement les deux commandes que B a tapées après le clonage ;
3. la liste des opérations disponibles ;
4. les noms des deux contributeur(rice)s.

Pour la syntaxe, voyez la référence Markdown et les spécificités GitLab.

Gérer le dépôt depuis VS Code

Tout ce que vous venez de faire en ligne de commande est aussi accessible depuis l’IDE. Maintenant que vous savez ce qui se passe dessous, l’interface graphique devient un confort et non une boîte noire.

Vous y retrouverez, dans l’ordre : la liste des fichiers modifiés, le bouton + qui ajoute à l’index, la zone de message de commit, et le bouton de synchronisation qui envoie vers le dépôt distant.

Pour aller plus loin dans l’intégration, installez l’extension GitLab pour VS Code et authentifiez-vous auprès de l’instance de l’école. Il vous faudra créer un jeton (token) depuis votre profil GitLab, avec la portée api. Activez ensuite l’affichage des auteurs ligne par ligne, via le réglage git.blame.editorDecoration.enabled :

En plaçant le curseur sur une ligne, VS Code indique le message de commit, l’auteur(e) et la date de sa dernière modification.

Pour aller plus loin

Travailler sur une branche

Jusqu’ici, vous avez tous les deux travaillé sur main, d’où les conflits. La pratique courante en équipe est de créer une branche par tâche, puis de la fusionner quand elle est terminée.

git switch -c ajout-modulo
git push -u origin ajout-modulo

git switch -c ajout-modulo
git push -u origin ajout-modulo

git switch -c ajout-modulo
git push -u origin ajout-modulo

git switch -c ajout-modulo
git push -u origin ajout-modulo

Sur GitLab, cette branche peut alors faire l’objet d’une merge request : votre binôme relit vos modifications et les commente avant qu’elles n’entrent dans main. C’est le mode de travail que vous adopterez pour le projet du semestre.

Retrouver un état antérieur

Tout l’intérêt de versionner est de pouvoir revenir en arrière. Explorez l’historique, puis affichez l’état d’un fichier à un commit donné.

git log --oneline --graph --all
git show <debut du hash>:calculatrice.py

git log --oneline --graph --all
git show <debut du hash>:calculatrice.py

git log --oneline --graph --all
git show <début du hash>:calculatrice.py

git log --oneline --graph --all
git show <début du hash>:calculatrice.py

Et si on avait versionné .venv ?

Pour bien mesurer l’intérêt du .gitignore, essayez : retirez .venv du .gitignore, faites git add ., et regardez le nombre de fichiers que git status annonce, puis la taille du dossier. Ne validez pas ce commit : annulez avec git restore --staged . et remettez la ligne dans .gitignore.

Pour aller encore plus loin