Versionner un projet NestJS avec Git et GitHub (.gitignore, commits, push)

Pourquoi versionner dès le premier jour ?

• Sauvegarde: un ordinateur perdu ou en panne ne fait pas perdre le travail.
• Historique: on sait ce qui a changé, quand et pourquoi, et on peut revenir en arrière.
• Travail en équipe: plusieurs personnes modifient le même projet sans s'écraser.
• Portfolio: vos dépôts GitHub montrent vos compétences aux recruteurs.

Configurer Git (une seule fois par ordinateur)

git config --global user.name "Prénom Nom"
git config --global user.email "adresse@exemple.com"   # celle de votre compte GitHub
git config --global init.defaultBranch main

Le cycle de travail

On prépare (add), on valide (commit), on publie (push) ; pull et clone récupèrent le travail.

git status                         # que s'est-il passé ?
git add .                          # préparer toutes les modifications
git commit -m "feat: route GET /version"
git push                           # publier sur GitHub
git log --oneline                  # historique résumé

Ce qui ne doit jamais être versionné

Le .gitignore généré par la CLI exclut déjà l'essentiel. Vérifiez qu'il contient au moins :

# dépendances et code compilé : recréés par npm install / npm run build
node_modules/
dist/

# résultats de tests et journaux
coverage/
*.log

# secrets : mots de passe, clés (chapitre 10)
.env
.env.*
!.env.example

# éditeurs
.idea/

Des messages de commit clairs

Un bon message dit ce que fait le commit. La convention Conventional Commits est très répandue :

À éviter : "modif", "update", "ça marche". Faites des commits petits et fréquents: un commit = une modification cohérente.

Créer le dépôt GitHub et pousser

1. Sur github.com/new, créez un dépôt vide portant le nom du projet (sans README, sans .gitignore, sans licence : le projet local les fournit).
2. Reliez et poussez :

git remote add origin https://github.com/VOTRE-COMPTE/api-formation.git
git branch -M main
git push -u origin main

Lors du premier push, Git demande de vous authentifier. Sous Windows, le gestionnaire d'identifiants installé avec Git ouvre une fenêtre de connexion GitHub. Ailleurs, utilisez un jeton d'accès personnel (GitHub → Settings → Developer settings → Personal access tokens) à la place du mot de passe, ou la commande gh auth login de GitHub CLI.

Les branches

On ne développe pas directement sur main, qui doit toujours fonctionner. On crée une branche par fonctionnalité :

git switch -c feature/module-groupes   # créer la branche et s'y placer
# … travail, commits …
git push -u origin feature/module-groupes
git switch main
git merge feature/module-groupes       # ou une Pull Request sur GitHub

Sur GitHub, une Pull Request permet de relire les modifications d'une branche avant de les fusionner dans main: c'est la pratique standard en entreprise.

Les étiquettes de version (tags)

git tag -a v0.1.0 -m "Première version de l'API"
git push origin v0.1.0

Une étiquette marque une version précise du projet (rendu de TP, mise en production). Elle apparaît dans l'onglet Releases / Tags du dépôt.

Récupérer un projet depuis GitHub

git clone https://github.com/VOTRE-COMPTE/api-formation.git
cd api-formation
npm install            # recrée node_modules
cp .env.example .env   # puis compléter les valeurs
npm run start:dev

Activités

git rm -r --cached node_modules
git commit -m "chore: retrait de node_modules du dépôt"
git push

git switch -c feature/route-version
git add src/
git commit -m "feat: route GET /version"
git push -u origin feature/route-version
# Sur GitHub : Compare & pull request → Create → Merge
git switch main
git pull