Ch. 1 — Compilation et gestion de version

Pourquoi compiler à la main ?

Les IDE (Eclipse, IntelliJ, VSCode, VSCodium, Apache NetBeans) et les outils de construction (Apache Ant, Maven, Makefile) automatisent tout. Alors pourquoi savoir compiler soi-même ? Le cours donne trois raisons : configurer son IDE en connaissance de cause ; déterminer si un « bug » vient de la configuration de l'IDE ou du code lui-même ; développer en mode bac-à-sable, hors de tout projet.

Deux commandes suffisent, avec leurs options :

javac [options] <sourcefiles>           # compiler
java  [options] <classname> [args]      # exécuter une classe
java  [options] -jar <filename> [args]  # exécuter une archive

Deux options reviennent sans cesse. -d <chemin> fixe le répertoire de destination des fichiers binaires ; -cp <chemin> (classpath) indique où trouver les binaires nécessaires — à la compilation comme à l'exécution. Un projet bien organisé sépare src/ (sources), bin/ (binaires, même hiérarchie que src/), lib/ (archives comme MaLibrairie.jar) et res/ (ressources : images, CSV).

Trois compilations progressives

Sans rien. Depuis le répertoire des sources, javac A.java dépose le binaire à côté du source ; java A l'exécute.

Depuis la racine. javac src/A.java compile pareil, mais l'exécution devient java -cp src A : le classpath pointe vers le répertoire qui contient le binaire.

Avec paquetage. La classe vit dans src/mypkg/A.java et déclare package mypkg; :

javac -d bin src/mypkg/A.java   # le binaire respecte la hiérarchie : bin/mypkg/A.class
java  -cp bin mypkg.A           # exécution par nom pleinement qualifié

La hiérarchie des paquetages est celle des répertoires : javac -d bin recrée l'arborescence sous bin/, et l'exécution exige le nom pleinement qualifié (mypkg.A), le classpath pointant vers la racine des paquetages.

Centralisé ou décentralisé ?

Sans organisation suffisamment éprouvée, la collaboration mène au ballet des rapport_final (1).docx : travail fastidieux et méthodique, rigueur exigée même seul, impossible dès que plusieurs personnes participent. D'où le VCS (Version Control System). Les systèmes centralisés — CVS (vieillissant), SVN (en déclin) — ne connaissent qu'un seul dépôt des versions : usage contraignant, notamment hors connexion ou pour les branches expérimentales. Les systèmes décentralisés — Git, Mercurial (Hg), Bazaar — facilitent l'usage individuel sans connexion permanente, avec des opérations rapides car locales.

L'anatomie d'un dépôt Git

Un dépôt se décompose en trois espaces :

• le dépôt (repository) : le répertoire .git, qui contient toutes les données dont Git a besoin pour gérer l'historique ;
• la copie de travail (working copy) : les fichiers effectivement présents dans le répertoire géré, dont l'état peut différer du dernier commit de l'historique ;
• l'index : l'espace temporaire des modifications prêtes à être « committées » — créations, modifications, suppressions de fichiers.

Chaque commit est une photo de l'état de tous les fichiers du projet, caractérisée par une date, un auteur, une description textuelle et un lien vers le commit précédent. Le stockage est différentiel, donc très efficace. Gitk visualise l'historique de manière interactive.

Les commandes du quotidien

git init <path>              # initialise un dépôt : crée le sous-répertoire .git
git add <filename>           # place un fichier dans l'index
git reset <filename>         # le retire de l'index
git commit -m "message"      # enregistre les modifications indexées
git status / git diff        # résumé / détail des changements en cours
git log / git show <id>      # liste des révisions / détail d'un commit
git checkout <révision>      # charge une révision

Une révision se désigne par son identifiant (git checkout 5a8891) ou relativement : HEAD~1 remonte d'un commit, HEAD~2 de deux. La lecture d'un git diff a sa grammaire : @@ encadre la portion de code affectée, + marque les lignes modifiées dans leur nouvelle version, - dans leur ancienne, les lignes sans préfixe fournissent le contexte. Bilan en dépôt local : add/reset relient la working copy à l'index, commit relie l'index au dépôt, checkout fait le trajet inverse.

Le dépôt distant

À distance, on n'échange plus des fichiers individuellement mais des commits — des états cohérents de l'ensemble des fichiers. git clone <url> <path> copie le dépôt distant et le déclare automatiquement comme dépôt distant sous le nom origin ; git remote add <nom> <chemin> lie un dépôt existant à un distant — opération à faire une seule fois par dépôt distant, pour pouvoir interagir avec lui.

git fetch   # récupère les commits, SANS impacter la copie de travail
git pull    # récupère les commits, EN mettant à jour l'espace local
git push    # publie ses commits

Scénario du cours : un push réussi depuis la salle TP rend le push suivant impossible depuis votre PC — le dépôt distant a avancé. Il faut pull (récupérer et fusionner), push, puis pull sur l'autre machine : tout tourne autour du dépôt distant.

Le workflow standard

Trois réflexes : committer souvent ; des changements indépendants dans des commits différents ; des messages de commit significatifs. On versionne tout ce qui n'est pas généré par un outil — fichiers sources, scripts, fichiers de ressources — jamais les temporaires, binaires ou la documentation générée : sinon des conflits surviennent « gratuitement ». Le fichier .gitignore les exclut :

doc/
bin/
.vscode/ltex.*.txt
**/*.class

A retenir

• javac -d bin puis java -cp bin pkg.Classe : le paquetage est une arborescence de répertoires ;
• un commit est une photo datée, signée, décrite et chaînée à la précédente ; le stockage est différentiel ;
• trois espaces — working copy, index, dépôt — reliés par add/reset, commit, checkout ;
• fetch récupère sans toucher à la copie de travail, pull met à jour, push publie ;
• on versionne les sources, jamais ce qui se génère : le .gitignore veille.