Projet complet et mémento

1. Le cahier des charges du mini-projet

L’équipe pédagogique NKILItech veut un petit portail statique avec un accueil, un point de contact et une documentation. Le travail doit être réparti en contributions lisibles. Une modification de texte concurrente devra être résolue, puis une première version devra être identifiée.

Les livrables attendus sont un dépôt organisé, des commits cohérents, une branche de fonctionnalité, une pull request documentée dans votre dépôt d’exercice, un contrôle automatique et un tag de version. Pour un entraînement entièrement hors ligne, remplacez la pull request par une fiche de revue locale et utilisez un dépôt distant sur disque.

Les critères sont concrets : les pages existent, le README explique la vérification, aucun secret réel n’est enregistré, la branche principale contient le résultat validé et le graphe permet de retrouver les étapes.

2. Étape 1 : initialiser et documenter

Dans un nouveau dossier d’exercice, reprenez la configuration des chapitres 2 et 3. Préparez README.md, index.html, .gitignore et .gitattributes. Enregistrez le premier état après avoir lu le diff préparé.

Le README doit présenter le but, la manière d’ouvrir la page et les vérifications attendues. Utilisez une adresse de contact factice dans les exemples. Vérifiez le résultat avec status et log avant de relier le dépôt distant.

git status
git diff --cached
git log --oneline --decorate --graph --all

Le critère de réussite n’est pas seulement l’absence d’erreur dans le terminal : il faut pouvoir expliquer ce qui a été préparé, ce qui a été commité et ce qui reste hors de l’historique.

3. Étape 2 : proposer puis améliorer la fonctionnalité

Créez une issue « Ajouter un point de contact ». Précisez le texte attendu et un lien depuis l’accueil. Développez le changement dans feature/contact-client, vérifiez les deux pages puis créez un commit ciblé.

Envoyez la branche et ouvrez une pull request vers main. Dans la description, présentez le besoin, les changements et les vérifications manuelles. Demandez une revue dans le cadre prévu pour votre exercice, puis apportez une correction sur la même branche.

Si vous êtes seul, relisez la proposition après une pause en suivant les mêmes critères. Vous pouvez pratiquer les échanges Git entre deux clones, mais cela ne remplace pas une approbation indépendante lorsque l’équipe ou les règles du dépôt l’exigent.

4. Étape 3 : résoudre, contrôler et livrer

Créez un conflit d’entraînement sur un fichier factice comme tarif.txt, selon le chapitre 5. Résolvez le sens de la modification, pas seulement ses marques. Vérifiez ensuite qu’aucune opération n’est restée en cours.

Ajoutez le script de contrôle et son workflow. Faites d’abord réussir la commande localement, puis vérifiez son exécution sur GitHub. Une fois la proposition intégrée selon votre méthode de fusion, actualisez main localement et créez le tag v1.0.0 sur le commit réellement validé.

Rédigez les notes : contenu ajouté, méthode de vérification et limites. Cette étape distingue un ensemble de commits d’une version expliquée et reproductible.

5. Mémento : choisir la commande par intention

Ces commandes servent de repères. Une commande contenant un nom de branche ou un identifiant suppose que ce nom existe et corresponde à votre intention. Lisez les messages plutôt que de recopier une suite de commandes destinée à une autre situation.

6. Évaluer sa maîtrise

1. Expliquez pourquoi un fichier modifié après add peut contenir deux versions différentes entre l’index et le dossier de travail.
2. Montrez un graphe avec une avance rapide et un autre avec un commit de fusion.
3. Expliquez pourquoi origin/main peut être ancien avant fetch.
4. Résolvez un conflit en justifiant le contenu final.
5. Choisissez revert pour une correction partagée et expliquez pourquoi reset ne produit pas le même historique.
6. Distinguez le succès d’un workflow du déploiement d’un produit.

Vous pouvez poursuivre ensuite avec des usages plus spécialisés : worktrees pour plusieurs dossiers de travail, bisect automatisé, sous-modules, Git LFS ou politiques de signature. Le socle reste le même : savoir quelle référence et quel contenu chaque commande modifie.

Exercices corrigés