Module L06 · Partie F · Coder comme un professionnel

Le terminal, Git et le projet qui tient dans le temps.

Un programme de 50 lignes tient dans un fichier. Un projet de robot, c’est 40 fichiers, trois personnes, six mois et des versions qu’on doit pouvoir retrouver. Ce module donne les outils que tout développeur utilise chaque jour : la ligne de commande, Git, l’organisation d’un dépôt, l’intégration continue. Il se pratique sur votre PC ; la page montre les commandes et fait tourner un « mini-Git » en Python pour comprendre ce qui se passe sous le capot.

Durée : 2 séances · Prérequis : L01. Objectifs : naviguer et scripter dans un terminal, versionner avec Git (commit, branche, fusion, conflit, dépôt distant), structurer un projet Python (paquets, dépendances, tests, README), automatiser les tests avec GitHub Actions.

Fiche de cours · Définitions

Les outils du développeur : définitions précises

Fiche de cours · Formules

Commandes et règles à connaître par cœur

Shell : grep -rn motif ., find . -name "*.py", sort | uniq -c | sort -rn, head/tail -f, xargs, time, ps/kill, ssh/scp, chmod +x. Tests : pytest -x -q, pytest --cov, pytest -k nom, fixtures et @pytest.mark.parametrize.

Fiche de cours · Théorèmes et démonstrations

Ce qu’on peut prouver sur ces outils

Fiche de cours · Méthodes

Méthodes de travail

Pièges : git push --force sur une branche partagée ; commiter venv/ ou des clés ; tests qui dépendent de l’ordre ou de l’heure ; except: pass qui masque le bug qu’on cherche ; optimiser sans mesurer.

Fiche de cours · Exercices corrigés

Exercices corrigés

import pytest
from hypothesis import given, strategies as st
from stats import mediane
def test_impair(): assert mediane([3, 1, 2]) == 2
def test_pair(): assert mediane([1, 2, 3, 4]) == 2.5
def test_un(): assert mediane([7]) == 7
def test_vide():
    with pytest.raises(ValueError): mediane([])
@given(st.lists(st.floats(allow_nan=False, allow_infinity=False), min_size=1))
def test_entre_min_et_max(L): assert min(L) <= mediane(L) <= max(L)
@given(st.lists(st.integers(), min_size=1))
def test_invariante_par_permutation(L):
    import random; M = L[:]; random.shuffle(M); assert mediane(L) == mediane(M)

01 / Terminal

Le terminal : parler à la machine sans intermédiaire

# Se repérer et se déplacer
pwd                    # où suis-je ?
ls -la                 # lister (avec fichiers cachés et détails)
cd projets/robot       # entrer ; cd .. pour remonter ; cd ~ pour le dossier personnel
mkdir -p src/tests     # créer (avec les parents)
cp -r src src_backup   # copier ; mv pour déplacer/renommer ; rm -r pour supprimer (irréversible !)

# Lire et chercher
cat fichier.py         # afficher ; less pour paginer ; head -n 20 ; tail -f journal.log (suivre en direct)
grep -rn "def lire" src/          # chercher récursivement, avec numéros de ligne
find . -name "*.py" | wc -l       # compter les fichiers Python

# Enchaîner : tubes et redirections
python capteur.py > mesures.txt   # sortie vers un fichier (>> pour ajouter)
cat mesures.txt | sort -n | uniq -c | head     # trier numériquement, compter les doublons
python robot.py 2> erreurs.log                 # seulement les erreurs (flux 2)
ls *.csv && echo "il y a des CSV" || echo "aucun"

01 / Terminal

Environnements virtuels et dépendances

# Un environnement par projet : les bibliothèques n'entrent pas en conflit entre projets
python -m venv .venv                 # créer (une fois)
source .venv/bin/activate            # activer (Linux/macOS) ; .venv\Scripts\activate sous Windows
pip install numpy matplotlib pyserial
pip freeze > requirements.txt        # figer les versions exactes
pip install -r requirements.txt      # les réinstaller ailleurs (un autre PC, un serveur, un collègue)

# Version moderne, en un fichier pyproject.toml (outil : uv, poetry ou pip ≥ 23)
[project]
name = "robot-explorateur"
version = "0.1.0"
dependencies = ["numpy>=1.26", "pyserial>=3.5"]
[project.optional-dependencies]
dev = ["pytest", "ruff", "mypy"]

La règle : le dépôt contient requirements.txt ou pyproject.toml, jamais .venv/ (des centaines de Mo, propres à une machine). Un projet qu’on ne peut pas réinstaller en une commande n’est pas reproductible — et en recherche, non reproductible = inexistant.

02 / Git

Ce qu’est vraiment un commit : un mini-Git en Python

02 / Git

Le cycle quotidien

git init                          # créer un dépôt dans le dossier courant (une fois)
git status                        # que s'est-il passé depuis le dernier commit ?
git add robot.py tests/           # mettre dans l'index (la « zone de préparation ») ; git add -p pour choisir par morceaux
git diff --staged                 # relire ce qu'on va valider
git commit -m "Ajoute la détection d'obstacle par ultrason"
git log --oneline --graph --all   # l'historique, en arbre

# Revenir en arrière sans rien perdre
git diff HEAD~1                   # ce qui a changé depuis l'avant-dernier commit
git restore robot.py              # annuler les modifications non validées d'un fichier
git revert a1b2c3                 # créer un commit qui annule le commit a1b2c3 (l'historique reste intact)
git stash / git stash pop         # mettre de côté un travail en cours, le reprendre

02 / Git

Branches, fusion, conflits

git switch -c capteur-ir          # créer une branche et s'y placer (git checkout -b, ancienne syntaxe)
# ... commits sur la branche ...
git switch main
git merge capteur-ir              # fusionner : Git crée un commit avec deux parents
git branch -d capteur-ir          # supprimer la branche fusionnée

# Conflit : deux branches ont modifié les mêmes lignes
git merge experimental
# CONFLICT (content): Merge conflict in robot.py
# Le fichier contient :
<<<<<<< HEAD
VITESSE_MAX = 0.8
=======
VITESSE_MAX = 1.0    # après recalibration
>>>>>>> experimental
# → éditer pour garder la bonne version, supprimer les marqueurs, puis :
git add robot.py && git commit

# Rebase : rejouer ses commits par-dessus main pour un historique linéaire (avant de partager seulement !)
git rebase main

Un conflit n’est pas une erreur : c’est Git qui refuse de deviner. Il arrive quand deux personnes touchent la même ligne. On le résout en lisant les deux versions et en décidant — souvent en parlant à l’autre. Les petits commits fréquents et les branches courtes réduisent les conflits.

02 / Git

Travailler à plusieurs : dépôts distants et pull requests

git clone https://github.com/equipe/robot.git    # récupérer un dépôt existant
git remote -v                                     # origin = le dépôt distant
git pull                                          # récupérer et fusionner les commits des autres (fetch + merge)
git push -u origin capteur-ir                     # publier sa branche

# Le flux « pull request » (GitHub / GitLab « merge request ») :
# 1. branche → 2. commits → 3. push → 4. ouvrir une PR → 5. revue par un pair, tests automatiques
# → 6. corrections → 7. fusion dans main. Personne ne pousse directement sur main.

03 / Projet

Anatomie d’un projet Python sérieux

robot-explorateur/
├── README.md              # quoi, pourquoi, comment installer, comment lancer, captures
├── LICENSE                # MIT, GPL… sans licence, personne n'a le droit de réutiliser
├── pyproject.toml         # métadonnées + dépendances
├── .gitignore
├── .github/workflows/tests.yml    # intégration continue
├── src/robot/             # le code, en paquet importable : from robot.capteurs import Ultrason
│   ├── __init__.py
│   ├── capteurs.py
│   ├── moteurs.py
│   ├── navigation.py
│   └── __main__.py        # python -m robot
├── tests/
│   ├── test_capteurs.py
│   └── test_navigation.py
├── docs/                  # schémas, notes de conception
├── data/                  # petits jeux de données de test (les gros vont ailleurs)
└── scripts/               # outils annexes : calibration, tracés

Le README répond en 30 secondes à « qu’est-ce que c’est ? » et en 2 minutes à « comment je le fais tourner ? ». Un projet de concours, de stage ou de recherche sera jugé d’abord sur son README.

03 / Projet

Intégration continue : les tests tournent à chaque push

# .github/workflows/tests.yml
name: tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.11", "3.12"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - run: pip install -e ".[dev]"
      - run: ruff check src tests
      - run: mypy src
      - run: pytest --cov=robot --cov-report=term-missing

À chaque push, un serveur installe le projet dans un environnement vierge et lance le style, les types et les tests. Une PR avec une croix rouge ne se fusionne pas. Ce filet de sécurité change la façon de travailler : on ose refactoriser, parce que si on casse quelque chose, on le saura dans les cinq minutes. Sur un projet de robot, on y ajoute la compilation du firmware (module L18) et parfois des tests sur matériel réel (hardware-in-the-loop).

03 / Projet

Reproduire un bug avec git bisect : la dichotomie appliquée à l’historique

git bisect start
git bisect bad                 # la version actuelle a le bug
git bisect good v1.2           # cette ancienne version marchait
# Git extrait un commit du milieu ; on teste, puis :
git bisect good   # ou  git bisect bad
# ... 8 fois pour 200 commits ...
git bisect reset

Avec git bisect run pytest tests/test_nav.py, Git fait tout seul les 8 étapes. Voilà pourquoi chaque commit doit rester testable.

Cours

Cours 1 — Le modèle mental de Git : trois zones, un graphe

Le graphe. Les commits forment un DAG (module L05) : chaque commit pointe vers son ou ses parents (deux pour une fusion). Une branche est un pointeur nommé vers un commit qui avance à chaque nouveau commit ; HEAD pointe vers la branche courante (ou directement un commit : « HEAD détaché »). Un tag est un pointeur fixe. git log --graph --oneline --all dessine ce graphe ; apprenez à le lire avant toute opération délicate.

Trois opérations sur le graphe. merge crée un commit à deux parents (l’historique reste vrai) ; rebase recopie des commits ailleurs (nouveaux hachages : ne jamais rebaser ce qui est déjà partagé) ; reset déplace une branche (avec --hard, perd le travail non validé — le seul moyen de vraiment perdre quelque chose avec Git, avec reflog comme filet de sécurité pendant 30 jours).

Cours

Cours 2 — Le shell comme langage : tubes, variables, boucles, codes de retour

# Chaque commande renvoie un code : 0 = succès, autre = échec ; $? le contient ; && et || l'exploitent
python tests.py && echo "tests OK" || echo "ÉCHEC"
# Variables et substitution de commande
N=$(ls *.csv | wc -l); echo "$N fichiers CSV"
# Boucle sur des fichiers, avec protection des espaces ("$f")
for f in data/*.csv; do python convertir.py "$f" "sorties/$(basename "$f" .csv).json"; done
# Filtrer un journal : les 10 erreurs les plus fréquentes
grep ERROR robot.log | cut -d' ' -f3- | sort | uniq -c | sort -rn | head
# Un script robuste commence par : arrêt à la première erreur, variables non définies interdites, tubes stricts
#!/usr/bin/env bash
set -euo pipefail
# Exécuter en tâche de fond, rediriger, et surveiller
python telemetrie.py > tele.log 2>&1 &
tail -f tele.log

Quand passer à Python. Dès qu’il y a des structures de données, des conditions imbriquées ou plus de 30 lignes : subprocess.run([...], check=True, capture_output=True) et pathlib remplacent le shell proprement. Le shell reste imbattable pour enchaîner des outils existants en une ligne.

Cours

Cours 3 — Qualité industrielle : versions, journal des changements, revue

• Versionnage sémantique : MAJEUR.MINEUR.CORRECTIF (2.3.1). Majeur : incompatible ; mineur : ajout compatible ; correctif : bug. Un tag Git par version : git tag -a v2.3.1 -m "…".
• CHANGELOG.md : pour chaque version, « Ajouté / Modifié / Corrigé / Supprimé ». Écrit par les humains, pour les humains ; les messages de commit ne le remplacent pas.
• Messages de commit conventionnels : feat(capteurs): ajoute le filtre médian, fix(serie): borne la ligne à 64 octets, refactor, test, docs. Permet de générer le changelog et de trier l’historique.
• Branches protégées : main n’accepte que des fusions de PR relues avec CI verte. Sur GitHub : Settings → Branches → protection rules.
• Hooks : pre-commit (outil du même nom) lance ruff, black, mypy avant chaque commit ; ce qui ne passe pas n’est pas validé.
• Revue : une PR = un objectif ; description avec « quoi, pourquoi, comment tester » ; captures ou sorties de tests ; relecteur nommé ; on approuve ou on demande des changements, jamais de « LGTM » sans avoir lu.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.6.0
    hooks: [{id: ruff}, {id: ruff-format}]
  - repo: https://github.com/pre-commit/mirrors-mypy
    rev: v1.11.0
    hooks: [{id: mypy}]
# pip install pre-commit && pre-commit install   → actif à chaque git commit

TP guidé

TP — Un projet d’équipe de bout en bout (sur PC, 2 personnes, 2 h)

• Créer et publier. Personne A : dépôt robot-equipe sur GitHub avec README, licence MIT, .gitignore Python, pyproject.toml ; clone local ; premier commit ; git push -u origin main. Personne B : git clone.
• Travailler en parallèle. A sur la branche capteur-ultrason (classe + tests), B sur journal-csv (classe + tests). Chacun : 3 commits atomiques avec messages conventionnels ; git push -u origin <branche> ; ouvrir une PR.
• Relire. Chacun relit la PR de l’autre : au moins deux commentaires précis (une question sur un cas limite, une suggestion de nommage). L’auteur corrige (nouveau commit, la PR se met à jour) ; le relecteur approuve ; fusion via l’interface (« Squash and merge » ou « Merge »).
• Provoquer un conflit. Les deux modifient la même ligne du README sur deux branches ; le second à fusionner résout le conflit localement :

  git switch ma-branche && git fetch origin && git merge origin/main
  # éditer, supprimer les marqueurs <<<< ==== >>>>
  git add README.md && git commit && git push

• CI. Ajouter .github/workflows/tests.yml (module L06 §03) ; pousser ; vérifier la coche verte sur la PR ; activer la protection de main (CI obligatoire). Cassez un test volontairement dans une PR : la fusion doit être bloquée.
• Version et changelog. Fusionner tout, écrire CHANGELOG.md, taguer v0.1.0, créer une « Release » GitHub. git log --graph --oneline --all doit montrer les deux branches fusionnées.
• Livrable. Le lien du dépôt : historique lisible, 2 PR fusionnées avec revue, CI verte, tag. C’est la preuve que vous savez travailler en équipe — mettez-la sur votre CV.

Exercices

Exercices auto-corrigés — raisonner sur Git et le shell

    def _ajouter(self, msg, parents):
        self.n += 1; self.commits[self.n] = {"msg": msg, "parents": parents}; self.branches[self.courante] = self.n; return self.n
    def commit(self, msg):
        h = self.branches[self.courante]; return self._ajouter(msg, [h] if h else [])
    def branche(self, nom): self.branches[nom] = self.branches[self.courante]
    def switch(self, nom): self.courante = nom
    def ancetres(self, i):
        vus, pile = set(), [i]
        while pile:
            c = pile.pop()
            if c and c not in vus: vus.add(c); pile.extend(self.commits[c]["parents"])
        return vus
    def merge(self, nom):
        moi, lui = self.branches[self.courante], self.branches[nom]
        if moi in self.ancetres(lui): self.branches[self.courante] = lui          # fast-forward
        elif lui not in self.ancetres(moi): self._ajouter(f"merge {nom}", [moi, lui])
    def log(self):
        out, c = [], self.branches[self.courante]
        while c: out.append(self.commits[c]["msg"]); c = self.commits[c]["parents"][0] if self.commits[c]["parents"] else None
        return out
    def commits_by_msg(self, msg): return next(i for i, c in self.commits.items() if c["msg"] == msg)

def grep(motif, lignes): return (l for l in lignes if motif in l)
def cut(lignes, k): return (" ".join(l.split(" ")[k - 1:]) for l in lignes)
def uniq_c(lignes):
    from itertools import groupby
    return ((len(list(g)), k) for k, g in groupby(lignes))
def top(n, paires): return sorted(paires, key=lambda p: (-p[0], p[1]))[:n]

04 / Défis

Défi ★ — Premier dépôt

04 / Défis

Défi ★★ — Provoquer et résoudre un conflit, puis bissecter

04 / Défis

Défi ★★★ — Esprit prépa : diff par plus longue sous-suite commune

def diff(a, b):
    n, m = len(a), len(b)
    L = [[0] * (m + 1) for _ in range(n + 1)]
    for i in range(n - 1, -1, -1):
        for j in range(m - 1, -1, -1):
            L[i][j] = L[i + 1][j + 1] + 1 if a[i] == b[j] else max(L[i + 1][j], L[i][j + 1])
    i = j = 0; sortie = []
    while i < n and j < m:
        if a[i] == b[j]: sortie.append("  " + a[i]); i += 1; j += 1
        elif L[i + 1][j] >= L[i][j + 1]: sortie.append("- " + a[i]); i += 1
        else: sortie.append("+ " + b[j]); j += 1
    sortie += ["- " + l for l in a[i:]] + ["+ " + l for l in b[j:]]
    return "\n".join(sortie)
print(diff(ancien, nouveau))

Référence

Les mots à retenir

Pour continuer

Vous travaillez comme une équipe

Module suivant : le langage C et OCaml, les deux langages de la prépa MP2I/MPI — pointeurs, mémoire, compilation, et la programmation fonctionnelle typée.

À faire chez soi

• Faire les 20 premiers niveaux de Learn Git Branching (site interactif gratuit).
• Mettre tous vos projets du parcours dans un dépôt GitHub avec README et CI.
• Lire les chapitres 1 à 3 de Pro Git.

← L05SommaireL07 : C et OCaml →