Page 2 sur 10. Préparer le terminal, l’identité et un premier dépôt sans confondre configuration et connexion.
1. Installer et vérifier le terminal
Installez Git depuis le site officiel en choisissant les instructions de votre système. Sur Windows, Git for Windows fournit notamment Git et Git Bash. Ouvrez ensuite un nouveau terminal pour qu’il prenne en compte le chemin de l’installation.
git --version
git helpLa première commande affiche la version installée ; la seconde présente l’aide générale. Si git n’est pas reconnu, vérifiez l’installation et le PATH, puis relancez le terminal. Un compte GitHub n’est pas requis pour les premières manipulations locales.
Git dispose également d’interfaces graphiques. Comprendre les commandes de base reste utile, car elles permettent d’expliquer précisément la différence entre un fichier modifié, une modification préparée et un commit partagé.
2. Configurer son identité
git config --global user.name "Votre Nom"
git config --global user.email "votre-adresse@example.com"
git config --global init.defaultBranch main
git config --show-origin --get user.name
git config --show-origin --get user.emailLe nom et le courriel sont utilisés dans les nouveaux commits. Ils ne connectent pas le terminal à GitHub et ne prouvent pas que vous possédez un compte donné. Utilisez une adresse que vous acceptez de placer dans un historique ; GitHub propose une adresse de confidentialité dans les réglages du compte.
--global configure le compte utilisateur du poste. Dans un dépôt précis, une configuration sans cette option peut définir une identité professionnelle différente. --show-origin aide à comprendre de quel fichier provient une valeur.
git config user.email "adresse-professionnelle@example.com"Cette dernière commande s’exécute dans le dépôt concerné. Le nom de branche par défaut s’applique aux futurs dépôts créés par init ; il ne renomme pas toutes les branches déjà existantes.
3. Préparer un dossier de laboratoire
mkdir nkl-portail-lab
cd nkl-portail-lab
git init -b main
git statusLe dossier est maintenant un dépôt Git. Il contient un répertoire .git, même si votre explorateur masque les fichiers cachés. Aucun commit n’existe encore ; main est le nom prévu pour la première branche.
Évitez d’exécuter init dans un dossier parent contenant tous vos documents. Le périmètre du dépôt doit correspondre au projet. Évitez aussi de créer sans raison un dépôt Git à l’intérieur d’un autre : cela introduit des situations plus avancées, comme les dépôts imbriqués ou les sous-modules.
4. Créer les fichiers de départ
Set-Content -Encoding utf8 README.md "# Portail NKILItech"
Set-Content -Encoding utf8 index.html "<h1>Bienvenue chez NKILItech</h1>"
git status --short?? signale des fichiers non suivis. Ils existent dans le dossier mais ne font pas encore partie de l’historique. README.md présente le projet ; index.html est une page volontairement minimale, suffisante pour pratiquer le versionnement.
Les éditeurs peuvent proposer un enregistrement automatique. Cette fonction ne remplace pas la sélection des changements dans Git. Fermer puis rouvrir le terminal ne crée pas non plus de commit.
5. Définir les exclusions et les conventions de texte
Set-Content -Encoding utf8 .gitignore @"
.env
.env.*
!.env.example
node_modules/
*.log
.DS_Store
"@
Set-Content -Encoding utf8 .gitattributes "* text=auto"
git check-ignore -v .env.gitignore décrit les fichiers non suivis que Git doit ignorer. Ici, les fichiers de configuration locale, les dépendances et les journaux n’entrent pas dans les futurs commits. Le modèle .env.example reste autorisé ; il doit contenir uniquement des noms de variables et des valeurs factices.
.gitattributes permet notamment de documenter une politique de texte. La règle présentée demande à Git de détecter les fichiers textuels et de normaliser leur stockage. Une équipe peut préciser des règles LF ou CRLF selon ses outils ; il faut décider ensemble avant une normalisation massive d’un dépôt existant.
Un fichier déjà suivi ne disparaît pas de l’historique parce qu’on l’ajoute à .gitignore. Ce point sera repris dans le chapitre consacré aux erreurs et aux secrets.
6. Premier diagnostic autonome
| Observation | Vérification | Explication possible |
|---|---|---|
| git introuvable | git --version dans un nouveau terminal | Installation ou PATH incomplet |
| not a git repository | git rev-parse --show-toplevel | Terminal ouvert hors du projet |
| Identité incorrecte | git config --show-origin --get user.email | Valeur locale différente de la valeur globale |
| Fichier absent du status | git check-ignore -v chemin | Motif d’exclusion correspondant |
Lire le message complet avant d’essayer une autre commande évite beaucoup d’erreurs. Conservez un terminal ouvert à la racine du laboratoire et vérifiez son emplacement avant chaque manipulation importante.
Exercices corrigés
Exercice 1 - Identité et accès
Changer user.email connecte-t-il le terminal à GitHub ?
Voir le corrigé détaillé
Non. Ce réglage renseigne les nouveaux commits. L’authentification HTTPS ou SSH et les droits sur le dépôt sont des mécanismes distincts.
Exercice 2 - Exclusion
Un fichier .env déjà suivi disparaît-il des anciens commits après ajout à .gitignore ?
Voir le corrigé détaillé
Non. L’exclusion vise les fichiers non suivis. Retirer un fichier du suivi ne nettoie pas non plus ses versions historiques. Un secret exposé doit être révoqué ou renouvelé.
Avant de passer à la suite
Mon laboratoire est initialisé, mon identité est vérifiée et les exclusions sont définies.
Pour approfondir
Sources officielles consultées pour ce chapitre : Installer Git, Configuration initiale, gitignore. Cours et schémas originaux ; exemples NKILItech pédagogiques. Vérification documentaire : 28 octobre 2026.