Préparer son dépôt GitHub pour l'E5 et l'E6

Un dépôt prêt pour l'examen du BTS SIO contient un README qui explique le projet et son installation, un .gitignore et un .env.example à la place des secrets, une licence, un CHANGELOG, des versions étiquetées et un historique de commits lisible, accessible à la commission. Ce chapitre détaille chacun de ces éléments, donne un modèle de README, explique comment ouvrir l'accès à un dépôt privé et comment travailler avec Git pendant l'heure de réalisation de l'E6. Il se termine par une liste de vérification à passer une semaine avant l'épreuve.

Ce que la commission regarde

À l'E6 SLAM, ton dossier numérique donne accès aux éléments techniques de tes deux réalisations, et le dépôt Git en est le cœur : la commission y lit ton code avant de rédiger l'expression des besoins qu'elle te soumettra (le dossier E6). Pendant l'épreuve, tu fais évoluer ce code et tu montres ta démarche. Ce que le dépôt prouve :

À l'E5, commune aux deux options, le dépôt sert de preuve pour certaines réalisations et pour la compétence « Travailler en mode projet » ; ton portfolio peut lui-même être un site publié depuis un dépôt (le portfolio de l'E5). Un dépôt de notes de veille en Markdown, avec un commit par semaine, date chaque note de façon vérifiable (outils de veille).

Le README : la page d'accueil du projet

Le README.md, à la racine, s'affiche sous la liste des fichiers sur GitHub. C'est la première chose que lit la commission. Un modèle pour une réalisation :

# Sorbier Frais

Application Web de gestion des notes de frais de Sorbier Logistique :
les salariés saisissent leurs notes, les comptables les valident ou les refusent.

![CI](https://github.com/ton-pseudo/sorbier-frais/actions/workflows/ci.yml/badge.svg)

## Fonctionnalités
- Saisie d'une note avec justificatif (salarié)
- Validation ou refus motivé (comptable)
- Export CSV mensuel des notes validées

## Technologies
API REST Node.js 24 et Express 5, front React, base MySQL 8.4, tests Jest et supertest.

## Installation
Prérequis : Node.js 24, MySQL 8.4.

```bash
git clone https://github.com/ton-pseudo/sorbier-frais.git
cd sorbier-frais
cp .env.example .env          # puis renseigner les valeurs
mysql -u root -p < sql/schema.sql
mysql -u root -p sorbier_frais < sql/jeu-essai.sql
npm ci
npm run dev
```

L'application répond sur http://localhost:3000.

## Comptes de test
| Rôle | Identifiant | Mot de passe |
|---|---|---|
| Salarié | salarie1@sorbier.test | Test-Salarie-2026 |
| Comptable | compta1@sorbier.test | Test-Compta-2026 |

## Tests
`npm test` lance les tests unitaires et d'intégration (base `sorbier_test`).

## Documentation
- [Documentation de l'API](docs/api.md)
- [Modèle de données](docs/modele-donnees.md)
- [Guide utilisateur](docs/guide-utilisateur.md)

## Auteurs
Lina Morel (API, base de données), Hugo Dupré (front React).

Les rubriques à ne pas oublier : ce que fait l'application, en une phrase ; comment l'installer, avec des commandes qui marchent sur une machine neuve ; les comptes de test par rôle ; comment lancer les tests ; qui a fait quoi dans un projet d'équipe. Teste ton README en le suivant toi-même dans un dossier vide : c'est ce que fera la commission.

Les autres fichiers du dépôt

La licence. Sans fichier LICENSE, ton code est protégé par le droit d'auteur par défaut : les autres peuvent le lire sur GitHub, mais pas le réutiliser. Pour un projet personnel ou un portfolio que tu veux partager, la licence MIT est la plus simple : chacun peut réutiliser le code à condition de garder la mention de l'auteur. GitHub propose un assistant (Add file, Create new file, nommer le fichier LICENSE, puis Choose a license template). Pour un projet réalisé en stage, le code appartient en général à l'entreprise : ne le publie pas sans son accord écrit, et ne lui choisis pas de licence toi-même.

Public ou privé, et l'accès de la commission

Le jour où tu remets ton dossier, teste l'accès depuis une fenêtre de navigation privée, sans être connecté : un dépôt privé ou un lien mort découvert par la commission te met en difficulté avant même l'épreuve. Si ton établissement fournit sa propre forge (GitLab, Gitea), suis ses consignes.

Pour un projet de stage confidentiel, prépare une version que tu peux montrer, sans les données ni le code sensibles de l'entreprise, avec son autorisation : la commission doit pouvoir accéder aux éléments sur lesquels elle t'interroge.

Publier son portfolio avec GitHub Pages

GitHub Pages publie gratuitement un site statique (HTML, CSS, JavaScript) directement depuis un dépôt : c'est la solution la plus simple pour mettre en ligne le portfolio de l'E5 si tu l'as codé toi-même.

1. Pousse ton site dans un dépôt, avec un fichier index.html à la racine.
2. Dans Settings, Pages, choisis la source Deploy from a branch, la branche main et le dossier / (root), puis Save.
3. Après une minute environ, le site répond à l'adresse https://ton-pseudo.github.io/nom-du-depot/. Si le dépôt s'appelle exactement ton-pseudo.github.io, le site répond directement à https://ton-pseudo.github.io/.

Chaque git push sur main republie le site. Avec l'offre gratuite, le dépôt doit être public ; vérifie donc qu'il ne contient ni secret, ni coordonnées que tu ne veux pas exposer. Pour un site construit par un outil (React, un générateur de site statique), la source GitHub Actions lance la construction avant la publication (déployer avec GitHub Actions). Un nom de domaine personnel se configure dans la même page, avec un enregistrement DNS chez ton registraire.

Un historique qui raconte ta démarche

Tu ne peux pas inventer un historique, mais tu peux le rendre lisible :

• commite par étape qui marche : la migration de la base, la route, l'écran, les tests ; pas un commit par jour ;
• des messages explicites, dans une seule langue et une seule forme (chapitre 2) ;
• nettoie tes branches personnelles avant de les fusionner : un rebase interactif regroupe les « wip » et les « oups » (chapitre 7) ;
• ne réécris pas l'historique de main une fois partagé, même pour l'embellir : la commission compare parfois les dates.

Dans un projet d'équipe, git shortlog -sn compte les commits par auteur, et git log --author="Lina" --oneline montre les tiens. Vérifie que tous tes commits portent bien ton nom et ton adresse : un poste de salle mal configuré peut avoir signé tes commits au nom d'un camarade. Un fichier .mailmap à la racine regroupe sous une seule identité les commits faits avec plusieurs adresses.

Git pendant l'heure de réalisation de l'E6

L'expression des besoins te demande de faire évoluer ton application en une heure (la phase 2 de l'E6). Git est ton filet de sécurité :

git status                       # 1. le dépôt est propre avant de commencer
git switch -c e6-export-pdf      # 2. une branche pour l'évolution demandée
# ... première étape qui fonctionne ...
git add -A
git commit -m "Ajoute la colonne date_export à la table note"
# ... deuxième étape ...
git commit -am "Ajoute la route GET /notes/:id/pdf"
# ... une piste qui ne mène nulle part ...
git restore .                    # 3. retour au dernier commit qui marchait
git log --oneline                # 4. pendant la recette, montrer la démarche
git diff main --stat             # 5. résumer les fichiers modifiés depuis le départ

Un commit après chaque étape qui fonctionne te permet de revenir en arrière en une commande si une modification casse tout à la cinquantième minute. Pendant l'entretien, git log --oneline et git diff main montrent à la commission exactement ce que tu as fait et dans quel ordre.

La liste de vérification

Une semaine avant la date de remise du dossier :

• git status est propre et tout est poussé (Your branch is up to date with 'origin/main', après un git fetch)
• le README décrit l'application, l'installation, les comptes de test et les tests
• un clone neuf, dans un dossier vide, s'installe et démarre en suivant le README
• aucun secret dans le dépôt ni dans son historique (git log -p | grep -i "password" ne renvoie que des valeurs factices), un .env.example à la place
• un .gitignore adapté au langage ; ni node_modules, ni vendor, ni bin dans le dépôt
• le script SQL de création et le jeu d'essai sont présents
• la dernière version est étiquetée (v1.2.0) et le CHANGELOG est à jour
• le pipeline d'intégration continue est vert
• tes commits portent ton nom et ton adresse
• le dépôt s'ouvre depuis une fenêtre de navigation privée, ou le compte de la commission a l'accès
• une copie du dépôt et de la base de démonstration est prête sur une clé USB

Exercices