Dans Préparer Git côté local : démarrer dans de bonnes conditions, nous avons installé Git, vérifié son bon fonctionnement et connecté notre éditeur de code pour travailler dans de bonnes conditions. Nous allons maintenant franchir une nouvelle étape : utiliser Git pour suivre l’évolution réelle d’un petit site web.
Pour cela, nous allons créer un mini-projet très simple : une page HTML, quelques styles CSS, puis un peu de JavaScript. Chaque évolution du code nous permettra de découvrir une commande Git essentielle, en contexte. Nous pourrons ainsi apprendre à enregistrer une version, voir ce qui a changé, revenir en arrière, tester une idée dans une branche, ou encore fusionner différentes pistes de travail.
Tout se fera en local, sans connexion à un service distant. L’objectif est de comprendre comment Git nous accompagne, seul·e face à notre code, avant d’envisager un travail collaboratif ou une synchronisation avec GitHub.
Initialiser le projet avec Git
Nous commençons avec un dossier vide que nous nommons git-website. Dedans, nous créons un simple fichier index.html avec une structure minimale, juste de quoi afficher un titre dans la page. À ce stade, aucun style, aucun script, juste du HTML. C’est souvent comme ça qu’on débute un projet web : une idée, une page.
Pour que Git puisse suivre ce que nous allons construire, il faut lui dire que ce dossier est un dépôt. C’est ce que fait la commande suivante, à exécuter dans un terminal ouvert à la racine du dossier :
Git crée alors un dossier invisible .git, qui contient toute la mémoire du projet. Pour l’instant, cette mémoire est vide : aucun fichier n’a été enregistré, aucune version n’existe encore. C’est une feuille blanche, mais Git est en place.
Nous pouvons déjà vérifier que Git est bien actif, en demandant l’état du dépôt :
La page index.html apparaît en rouge : elle existe, mais Git ne la suit pas encore. C’est le tout début du suivi, et rien n’a encore été validé.
…à propos de Dreamweaver
Dans notre exemple, un dossier ._notes/ est apparu aux côtés de index.html. C’est un dossier généré automatiquement par Dreamweaver, que nous utilisons ici pour montrer que Git peut aussi suivre un projet initié dans un éditeur visuel. Dans un usage courant, on choisira de l’exclure via un fichier .gitignore, mais pour l’instant, ce n’est pas bloquant : Git détecte simplement sa présence et nous laisse décider si nous voulons l’inclure ou non.
…et dans Visual Studio Code
Si nous avons ouvert le dossier git-website dans Visual Studio Code, un onglet Contrôle de code source nous indique que Git est actif. C’est automatique dès qu’un dépôt est initialisé dans le dossier.
Nous voyons alors, visuellement, les fichiers non suivis listés comme dans le terminal : ici index.html et .notes/, en attente d’une décision. Aucun commit n’a encore été fait, et le projet est considéré comme vierge.
Si cet onglet n’apparaît pas, vérifions que le dossier a bien été ouvert comme un projet (via Fichier > Ouvrir le dossier), et que Git est bien installé sur le système. Un redémarrage de VSC peut parfois être nécessaire.
Comprendre le dossier .git
Dès que nous exécutons git init, Git crée un dossier caché nommé .git à la racine de notre projet. C’est ce dossier qui transforme un simple dossier en dépôt Git. Il contient toutes les informations nécessaires au suivi de l’historique : les versions, les identifiants, les messages, la position actuelle dans le projet, et bien plus encore.
Il ne s’agit pas d’une base de données externe, mais simplement d’un ensemble de fichiers et de sous-dossiers organisés. Chaque modification, chaque validation, chaque branche repose sur un fichier ou une référence interne. Git fonctionne en local, en toute autonomie : tant que ce dossier est là, l’historique complet du projet est conservé.
Voici une vue simplifiée des éléments que l’on y trouve :
Élément
Rôle principal
HEAD
Pointeur vers le dernier commit actif
config
Paramètres du dépôt (nom, auteur, format de diff…)
objects/
Versions des fichiers, commits et arbres, compressés
refs/
Références vers les branches et les tags
logs/
Historique des déplacements dans l’arborescence Git
hooks/
Scripts exécutés automatiquement à certains moments
Description textuelle (utile sur certains serveurs)
Ce dossier .git ne doit pas être modifié à la main, mais c’est lui qui permet à Git de fonctionner. Si on le supprime, Git oublie tout l’historique ; si on le copie, on duplique tout le dépôt, versions comprises.
Ajouter un fichier au suivi : staging area
Avant de créer une version officielle du projet, Git passe par une étape intermédiaire appelée staging area. C’est une sorte de sas : nous y plaçons les fichiers que nous souhaitons inclure dans le prochain commit. Cela permet de ne pas tout enregistrer d’un coup, mais de sélectionner avec précision les éléments qui feront partie de la version. On peut ainsi avancer par étapes claires, en validant ce qui est prêt, sans se presser pour le reste.
Notre fichier index.html est en place. Pour que Git commence à suivre ses changements, il faut donc l’ajouter à cette staging area, aussi appelée « zone de préparation ». Dans le terminal, cela se fait avec la commande suivante :
Terminal
gitaddindex.html## Place le fichier dans la zone de préparation
Le fichier passe alors dans l’état « prêt à être validé ». Une nouvelle commande permet de vérifier que Git l’a bien détecté :
… et dans Visual Studio Code
Dans la palette Source Control de Visual Studio Code, index.html apparaît maintenant dans la section Changes (Modifications), avec une icône +. Il suffit de cliquer dessus pour effectuer l’équivalent du git add en ligne de commande. Le fichier passe alors dans la section Staged Changes, prêt à être validé.
Cette opération ne crée pas encore de version : elle prépare simplement le fichier à être inclus dans un futur commit. La zone de message en haut du panneau nous permettra bientôt de nommer cette première version.
Retirer un fichier ajouté par erreur
Il arrive qu’on ajoute un fichier sans le vouloir, ou qu’on souhaite le retirer de la prochaine version avant de valider. Git permet de faire marche arrière tant qu’on n’a pas encore effectué de commit. Dans le terminal, nous pouvons utiliser :
Terminal
gitresetindex.html## Retire le fichier de la zone de préparation (mais ne le supprime pas)
Cela enlève simplement le fichier de la staging area, et il redevient visible comme un fichier modifié non pris en compte. À ce stade, aucune modification du contenu n’est perdue.
… et dans Visual Studio Code
Dans le panneau Source Control, si un fichier est passé dans la section Staged Changes, il suffit de survoler son nom et de cliquer sur l’icône de retrait (↩️) pour le faire revenir dans la section Changes. Cela correspond exactement à un git reset : le fichier n’est plus prêt à être validé, mais reste modifié dans le projet.
C’est utile, par exemple, si on veut valider uniquement certains fichiers, ou exclure un fichier temporairement avant de faire un commit plus propre.
Valider et nommer une version
Une fois les bons fichiers placés dans la staging area, nous pouvons enregistrer une version complète de notre projet. C’est ce qu’on appelle un commit. Chaque commit représente une étape claire dans l’évolution du code : il capture l’état exact des fichiers concernés, et l’associe à un message explicite, que nous écrivons nous-mêmes. Dans le terminal, la commande est la suivante :
Terminal
gitcommit-m"Première version HTML"## Crée une version validée du projet, avec un message
Ce message sera visible dans l’historique. Il est essentiel de le formuler avec clarté : « ajout CSS de base », « ajout du menu responsive », ou « correction bug formulaire ». Il doit permettre, plus tard, de savoir rapidement ce que chaque version contient.
… et dans Visual Studio Code
Dans le panneau Source Control, une fois les fichiers ajoutés à la zone Staged Changes, un champ de saisie de message apparaît en haut. Il suffit d’écrire notre description (« Première version HTML »), puis de cliquer sur la coche (✓) pour effectuer le commit.
Une notification ou un retour visuel confirme la validation, et les fichiers disparaissent de la liste des modifications : ils sont désormais alignés avec la dernière version validée.
Que contient un commit ?
Chaque commit conserve :
le contenu exact des fichiers à cet instant,
le nom de l’auteur,
la date et l’heure,
et bien sûr, le message de description.
C’est la première véritable étape dans la construction d’un historique de projet. Même si nous travaillons seul·e et en local, cela nous permet déjà de naviguer dans le temps, comparer les évolutions, ou revenir en arrière en toute sécurité.
Consulter l’historique et explorer un commit
Une fois notre premier commit effectué, Git nous permet de naviguer dans l’historique du projet pour relire les messages, visualiser les versions passées ou analyser les modifications. Dans le terminal, la commande git log affiche la liste complète des commits, avec l’auteur, la date et le message associé. Pour une vue plus synthétique, git log --oneline présente l’historique sous forme abrégée, avec l’identifiant court et le titre de chaque commit.
Nous pouvons aussi consulter le contenu exact d’un commit. En tapant git show, Git affiche les détails du dernier commit réalisé : le message, les fichiers concernés, et les différences ligne à ligne par rapport à l’état précédent. Il est également possible d’examiner un commit précis en ajoutant son identifiant (git show abc1234), ou simplement en ciblant le plus récent avec git show HEAD.
Dans Visual Studio Code, si nous avons installé l’extension GitLens, l’explorateur latéral nous donne accès à un historique complet du dépôt. Chaque commit peut y être ouvert pour voir ce qui a changé, fichier par fichier. Sans GitLens, un clic droit sur un fichier suivi par « File History > Open File History » qui permet déjà de retrouver les grandes étapes du projet, surtout si les messages sont clairs.
Ainsi, dès les premiers commits, nous disposons déjà d’un véritable journal de bord technique. Même sur un petit projet local, cette mémoire chronologique devient vite précieuse pour comprendre, justifier ou corriger une évolution.
Exclure certains fichiers avec .gitignore
Certains fichiers n’ont pas besoin d’être suivis par Git : éléments temporaires, sauvegardes, ou dossiers générés par des outils comme .notes/ de Dreamweaver. Pour les exclure, il suffit de créer un fichier .gitignore à la racine du projet, et d’y inscrire une règle par ligne, sans virgule.
#exclsuion typique pour DW.notes/*.logtemp/*.bak
Chaque ligne représente un motif à ignorer. Il n’y a pas besoin de virgules, seulement des retours à la ligne. On peut commenter une ligne avec #.
Aperçu des motifs les plus fréquents dans un fichier .gitignore
Exemple
Effet
notes.txt
Ignore uniquement ce fichier précis
*.log
Ignore tous les fichiers avec l’extension .log
temp/
Ignore tout le dossier temp
*.pdf
Ignore tous les fichiers PDF, quel que soit le dossier
debug/*_old.js
Ignore tous les fichiers se terminant par _old.js dans le dossier debug/
*secret*
Ignore tous les fichiers contenant secret dans leur nom
!keep.txt
Force Git à suivre ce fichier même s’il est ignoré ailleurs
Dans Visual Studio Code, le fichier .gitignore est reconnu automatiquement. On peut l’éditer manuellement comme n’importe quel fichier texte. Si l’extension GitLens est installée, elle propose des modèles courants. D’autres extensions comme Ignore This permettent d’ajouter des règles en un clic depuis l’explorateur de fichiers.
Si un fichier est déjà suivi par Git, .gitignore ne suffit pas à l’en exclure. Il faut d’abord le retirer avec git rm --cached nom_du_fichier, sans le supprimer du disque.
Le fichier .gitignore est lui-même versionné, ce qui garantit que toutes les personnes travaillant sur le projet partagent les mêmes règles d’exclusion.
Observer les modifications avant de valider
Avant d’ajouter un nouveau fichier, nous allons modifier légèrement index.html, par exemple en ajoutant un paragraphe. Git détecte aussitôt cette modification : un simple git status indique que le fichier est modifié. Pour voir ce qui a changé ligne par ligne, la commande git diff affiche une comparaison entre la version actuelle et la dernière version validée, avec les ajouts en vert et les suppressions en rouge.
Dans Visual Studio Code, il suffit de cliquer sur le nom du fichier modifié dans l’onglet Source Control pour ouvrir automatiquement une vue de comparaison. À gauche, l’ancienne version ; à droite, la nouvelle. Même sans extension, cette fonctionnalité est native à VSC et permet de vérifier visuellement ce que l’on s’apprête à enregistrer.
Comprendre : enregistrer, valider, commit
Lorsque nous travaillons avec Git, trois étapes se succèdent souvent, mais chacune a un rôle bien distinct. Pour éviter toute confusion, voici ce qu’elles signifient réellement.
1. Enregistrer (save)
C’est l’action la plus connue : nous appuyons sur Ctrl+S ou Cmd+S pour sauvegarder le fichier sur le disque. Git n’intervient pas à ce stade : il ne bloque rien, il n’automatise rien. Mais dès qu’un fichier enregistré a été modifié depuis le dernier commit, Git le remarque et le considère comme modifié. Il l’affiche comme tel dans git status ou dans Visual Studio Code (marqué par un « M »).
Valider signifie indiquer à Git quels fichiers modifiés doivent être inclus dans le prochain commit. Cette étape se fait manuellement avec git add, ou via l’icône + dans Visual Studio Code. Cela permet de préparer ce que l’on souhaite versionner, sans pour autant valider l’ensemble des fichiers modifiés.
Cette distinction est utile : on peut ne versionner qu’une partie des fichiers, ou faire plusieurs commits séparés selon la logique des changements. À ce stade, aucun historique n’est encore écrit, on ne fait que remplir la staging area.
Valider = sélectionner ce que Git doit inclure dans la prochaine version.
3. Committer (git commit)
C’est l’étape où Git enregistre une vraie version, horodatée, numérotée, et accompagnée d’un message. Tout ce qui a été validé (add) est inclus dans le commit, et devient une étape officielle dans l’historique du projet. Rien d’autre n’est ajouté. Si des fichiers ont été modifiés mais non validés, ils ne seront pas inclus.
C’est cette version que l’on pourra consulter plus tard avec git log, comparer avec git diff, ou restaurer.
Commit = créer un instantané nommé du projet, basé sur ce qu’on a validé.
Ajouter un fichier CSS et valider une nouvelle version
Nous allons maintenant ajouter un fichier style.css pour améliorer l’apparence de notre page HTML. Une fois créé et enregistré, Git le considère comme un fichier non suivi. On peut le vérifier avec :
Terminal
gitstatus
Il s’affiche alors en rouge : il existe dans le projet, mais Git ne le prend pas encore en compte. Pour qu’il devienne une partie officielle de notre historique, nous devons suivre les étapes vues précédemment : d’abord le valider avec git add, puis le committer.
Terminal
gitaddstyle.cssgitcommit-m"Ajout de la feuille de style"
Dans Visual Studio Code, le fichier apparaît dans la section Changes, accompagné d’un symbole U (Untracked). Un clic sur l’icône + permet de l’ajouter à la zone de validation. Une fois le message saisi (par exemple « Ajout de la feuille de style »), nous validons avec la coche (✓), ce qui crée le nouveau commit.
Ce commit devient une nouvelle étape du projet : désormais, notre dépôt contient à la fois le HTML initial, les ajustements sur index.html, et une feuille de style dédiée. Nous avons enrichi le projet, tout en conservant une trace claire de chaque évolution.
Conclusion
Nous avons découvert, étape par étape, comment utiliser Git en local pour suivre l’évolution d’un projet simple. Sans passer par GitHub, nous avons appris à initialiser un dépôt, valider des fichiers, créer des commits, observer nos modifications, et gérer les ajouts ou exclusions avec précision.
Cette base suffit déjà à structurer notre travail, conserver un historique clair et avancer avec confiance, même en solo. Nous avons entrevu la commande git log, qui permet de consulter les différentes étapes validées du projet. Dans le prochain article, nous l’explorerons plus en détail pour comparer deux versions, revenir sur une modification, ou tester une nouvelle idée sans casser ce qui fonctionne. Ce sera le moment d’aborder les branches, et de libérer encore davantage le potentiel de Git.
