Aller au contenu principal

Gestion des versions avec Git

Notions théoriques​

Pourquoi versionner son projet Spring Boot ?​

Comme pour Symfony, il est indispensable de versionner son code source dès le début du projet. Git permet de :

  • Sauvegarder l'historique de chaque modification
  • Collaborer sans écraser le travail des autres
  • Revenir à une version précédente en cas d'erreur
  • Déployer plus facilement sur un serveur
Comparaison avec Symfony

En Symfony, vous avez appris à utiliser Git depuis le premier jour. La démarche est identique en Java. Seul le .gitignore change pour s'adapter aux spécificités de Maven et d'IntelliJ IDEA.

Initialiser Git dans le projet​

# Dans le dossier racine du projet Spring Boot
git init
git add .
git commit -m "Initial commit : projet Spring Boot généré via start.spring.io"

Spring Initializr génère automatiquement un fichier .gitignore adapté à Spring Boot. Vous pouvez l'enrichir avec les éléments spécifiques à votre environnement.

Le .gitignore adapté Java/Maven/IntelliJ​

# Maven : dossier de build (comme vendor/ en PHP)
target/

# IntelliJ IDEA
.idea/
*.iml
*.iws
*.ipr

# Fichiers Java compilés
*.class

# Fichiers JAR/WAR/EAR
*.jar
*.war
*.ear

# Configuration locale (secrets, comme .env.local en Symfony)
application-local.properties
application-local.yml

# macOS
.DS_Store

# Logs
*.log
logs/
Ne jamais committer les secrets

Comme en Symfony où vous ne commitez pas le fichier .env contenant APP_SECRET et DATABASE_URL, en Spring Boot vous ne devez jamais committer le fichier application-local.properties qui contient le mot de passe de la base de données.

Ajoutez application-local.properties au .gitignore avant de créer ce fichier.

Que versionner ou non ?​

FichierCommitter ?Raison
pom.xmlOuiDépendances du projet
src/OuiCode source
application.propertiesOuiConfiguration (sans secrets)
application-local.propertiesNonContient des secrets
target/NonFichiers compilés, recréés par Maven
.idea/NonConfiguration IDE personnelle
*.classNonBytecode compilé

Branches et workflow​

# Voir les branches existantes
git branch

# Créer une branche pour une nouvelle fonctionnalité
git checkout -b feature/ajout-articles

# Revenir sur la branche principale
git checkout main

# Fusionner la branche
git merge feature/ajout-articles

Publier sur GitHub​

# Après avoir créé le dépôt sur github.com
git remote add origin https://github.com/votre-pseudo/monblog.git
git branch -M main
git push -u origin main

Exemple pratique​

Voici un exemple de fichier .gitignore complet pour un projet Spring Boot avec IntelliJ IDEA :

# === Maven ===
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/

# === IntelliJ IDEA ===
.idea/
*.iml
*.iws

# === Java ===
*.class

# === Secrets Spring Boot ===
**/application-local.properties
**/application-local.yml
**/*-local.properties

# === Logs ===
*.log
spring.log

# === Système ===
.DS_Store
Thumbs.db
info

spring-boot-starter-parent configure Maven pour produire le build dans target/. Ce dossier peut faire plusieurs dizaines de Mo — versionner ces fichiers compilés n'aurait aucun sens.

Test de mémorisation/compréhension​


Quel dossier Maven contient les fichiers compilés et ne doit PAS être commité ?


Quel fichier Spring Boot contient les secrets (mot de passe DB) et ne doit pas être commité ?


Quelle commande Git crée une nouvelle branche ET se déplace dessus ?


Quel dossier IntelliJ IDEA contient la configuration de l'IDE et ne doit pas être commité ?


Quelle commande Git envoie le code local vers GitHub pour la première fois ?


TP pour réfléchir et résoudre des problèmes​

Dans ce TP, vous allez configurer Git sur votre projet MonBlog et faire votre premier commit.

Étape 1 — Vérifier le .gitignore​

Spring Initializr génère déjà un .gitignore. Vérifiez qu'il contient bien les entrées importantes. Ajoutez application-local.properties s'il est absent.


Bonne pratique - .gitignore avant les fichiers secrets

Ajoutez toujours une entrée dans .gitignore avant de créer le fichier qu'elle protège. Si vous créez d'abord le fichier et l'ajoutez accidentellement avec git add ., le secret est exposé dans l'historique Git — même si vous le supprimez ensuite.

Étape 2 — Faire le premier commit​


Bonne pratique - Messages de commit descriptifs

Un bon message de commit décrit ce qui change et pourquoi, pas comment. Exemples :

  • Bon : "Ajout de l'entité Article avec ses champs de base"
  • Mauvais : "modif" ou "test" ou "update"

Étape 3 — Connecter à GitHub et pousser​

Créez un dépôt vide sur github.com, puis reliez votre projet local.


Bonne pratique - Committer souvent, pousser régulièrement

Commitez après chaque fonctionnalité terminée et qui fonctionne. Poussez au moins en fin de journée. Un dépôt distant sert aussi de sauvegarde : si votre ordinateur tombe en panne, vous ne perdez pas votre travail.

📌 Une solution