Explorer, tester, corriger : aller plus loin avec Git en solo

Dans notre article précédent — Premiers pas avec Git : suivre l’évolution d’un site simple — nous avons appris à utiliser Git pour créer des versions locales de notre projet, enregistrer nos avancées, et mieux structurer notre travail. Cette première approche nous a permis de comprendre les commandes fondamentales comme git init, add et commit, en alternant entre le terminal et Visual Studio Code.

Mais Git ne se limite pas à versionner. Il nous permet aussi de naviguer dans le temps, de corriger sans tout effacer, ou de tester une idée dans un coin du projet, sans toucher à ce qui fonctionne. C’est ce que nous allons explorer ici, toujours en solo, toujours en local, en utilisant des commandes comme log, checkout, revert, reset, ou branch. Nous verrons comment ces outils nous aident à garder le contrôle, même quand on fait un faux pas ou qu’on veut tenter une nouvelle piste.

Chaque commande sera illustrée concrètement, dans le terminal comme dans Visual Studio Code, avec l’aide de plugins si nécessaire. Et si une action nécessite un détour côté système, nous le ferons. L’objectif reste le même : progresser sans stress, avec des outils qui nous laissent expérimenter, comparer et revenir en arrière.

Lire l’historique avec git log

Git garde la mémoire de chaque version enregistrée, mais encore faut-il savoir y accéder. La commande git log permet de consulter l’historique complet des commits, du plus récent au plus ancien. À chaque ligne, Git affiche un identifiant unique (appelé hash), le nom de l’auteur, la date et le message associé.

Dans le terminal, un simple :

…nous montre l’historique complet. Si la liste est longue, on peut naviguer avec les touches fléchées, ou taper q pour quitter. Pour une vue plus condensée, chaque commit résumé en une ligne :

Cela affiche uniquement les identifiants abrégés (7 caractères) et les messages de commit. C’est très pratique pour se repérer ou copier un identifiant qu’on utilisera avec d’autres commandes (comme checkout, show, revert, etc.).

…et dans Visual Studio Code

Visual Studio Code ne propose pas d’historique Git intégré par défaut, mais avec l’extension GitLens, tout devient visible. Une fois installée, un panneau GitLens apparaît dans la barre latérale, avec une section dédiée à l’historique des commits. Chaque commit y est listé avec son message, sa date, et les fichiers concernés. Un simple clic permet de voir ce qui a changé.

On peut aussi afficher l’historique d’un seul fichier : clic droit sur un fichier > Afficher l’historique Git (si GitLens est actif). Cela permet de voir, ligne par ligne, qui a changé quoi et quand.

Sans GitLens, on peut toujours ouvrir le terminal intégré (Ctrl + ) et taper git log comme dans un terminal classique. L’extension Git Graph est aussi une alternative visuelle, très utile pour les branches.

Utiliser un identifiant de commit : copier, coller, cibler

Chaque commit possède un identifiant unique, appelé hash. Il est généré automatiquement par Git au moment de la validation, et peut être utilisé pour cibler précisément une version passée.

Quand on tape git log --oneline, Git affiche une version abrégée de ces identifiants, comme ici :

99eba2a (HEAD -> master) Ajout de la feuille de style
403c8bc Première version HTML

On peut copier n’importe lequel de ces identifiants (par clic droit ou sélection dans le terminal), et s’en servir ensuite pour afficher, restaurer ou annuler une version. Par exemple :

git show 99eba2a 
# Affiche les modifications enregistrées dans ce commit

git checkout 403c8bc 
# Bascule temporairement le projet à l’état de ce commit (mode détaché)

git revert 403c8bc 
# Crée un nouveau commit qui annule les changements du commit ciblé

Dans Visual Studio Code, si GitLens est activé, chaque commit affiche son identifiant complet (SHA). Un bouton de copie permet de le récupérer facilement. Ce hash long peut ensuite être collé tel quel dans une commande Git — Git l’interprète sans problème. Pour obtenir une version abrégée, on peut utiliser git log --oneline dans le terminal intégré, puis copier les 7 premiers caractères manuellement.

C’est un réflexe à prendre : chaque identifiant est une clé temporelle. On peut s’y référer à tout moment pour naviguer, revenir ou comparer sans jamais se perdre.

Naviguer dans les versions avec git checkout

Maintenant que nous savons consulter l’historique, nous pouvons vouloir revenir temporairement à une version précédente pour relire un état du projet, vérifier un comportement, ou comparer des fichiers.

La commande git checkout permet de basculer vers n’importe quel commit, à condition d’en connaître l’identifiant :

git checkout 403c8bc 
# Bascule temporairement le projet à l’état de ce commit (mode détaché)

Nous entrons alors dans ce qu’on appelle un mode détaché (detached HEAD) : nous ne sommes plus sur une branche, mais simplement positionné sur un point précis dans le temps. Nous pouvons consulter les fichiers, les exécuter, les tester, mais toute modification faite dans cet état sera perdue… sauf si nous créons une branche à partir de là (ce que nous verrons plus tard).

Pour revenir à l’état courant du projet, il suffit de revenir sur la branche principale (souvent main) :

git checkout main

…et dans Visual Studio Code

Dans Visual Studio Code, si nous utilisons GitLens, chaque commit listé dans le panneau latéral propose une action Switch to commit (click droit). Cela revient à faire un git checkout <id> : nous plaçons notre projet dans l’état exact de ce commit, sans être sur une branche. La barre de statut affiche alors un message du type HEAD @ a3f9b1c : nous sommes en mode détaché.

GitLens affiche ce commit dans une « pseudo-branche », mais il ne faut pas la confondre avec une branche Git réelle.

Une fois le switch effectué, aucun panneau ne s’ouvre automatiquement pour montrer les différences. Pour voir ce qu’il y avait dans cette version :

• Il faut ouvrir les fichiers dans l’explorateur comme d’habitude (index.html, style.css, etc.). Ils sont tous remplacés par ceux du commit sélectionné.
• Git ne montre pas de différence visuelle entre les versions précédentes et celle en cours. On est directement dans l’instantané du projet à ce moment-là.
• On peut ensuite comparer manuellement, ou lancer le projet pour tester son comportement dans cette version.

GitLens propose bien une vue du commit courant (Current commit), mais cette vue montre le message de commit et les fichiers modifiés — pas l’ensemble du projet. Pour réellement explorer ce que contenait un ancien commit, il faut naviguer dans les fichiers eux-mêmes, comme si on reprenait le projet à ce moment-là.

Pour revenir à l’état courant du projet après avoir basculé sur un ancien commit, le plus sûr est d’utiliser le terminal avec git checkout main (ou git checkout master, selon le nom de la branche principale). Dans GitLens, on peut aussi refaire un Switch to commit sur le dernier commit de la branche main, mais cela nous place techniquement sur ce commit, pas sur la branche elle-même : on reste alors en mode détaché. Mieux vaut donc privilégier un vrai retour sur la branche via la ligne de commande ou, si besoin, via la palette de commandes de Visual Studio Code en choisissant Git: Checkout to….

Corriger ou annuler avec restore, reset et revert

Git nous permet de revenir en arrière à différents niveaux : parfois, on veut simplement annuler une ligne avant de valider ; parfois, c’est un commit entier qu’on souhaite effacer ou inverser. Trois commandes couvrent ces cas de figure : restore, reset et revert.

1. git restore : revenir sur une modification en cours

Si un fichier a été modifié mais pas encore validé (git add non fait), on peut le remettre dans l’état du dernier commit avec :

git restore index.html

Le fichier revient alors à sa dernière version enregistrée dans l’historique. C’est l’équivalent d’un « Annuler tout » avant validation.

Dans Visual Studio Code, dans l’onglet Source Control, un clic droit sur le fichier modifié > Discard Changes (ou Revert Changes) produit exactement le même effet. Le fichier est restauré à l’état du dernier commit.

2. git reset : retirer un fichier de la zone de préparation

Si on a déjà fait un git add par erreur, mais qu’on ne veut finalement pas inclure ce fichier dans le prochain commit, on peut l’en retirer avec :

git reset index.html

Cela enlève le fichier de la staging area, sans supprimer ses modifications.

Dans Visual Studio Code, on peut simplement cliquer sur l’icône ↩️ (Remove from Staged Changes) à côté du fichier, dans la section Staged.

3. git revert : annuler un commit déjà enregistré

Lorsque le commit est déjà dans l’historique, et qu’on souhaite en annuler les effets, sans supprimer le commit lui-même, la commande adaptée est :

git revert 403c8bc 

Git crée un nouveau commit qui inverse les modifications du commit ciblé. L’historique reste intact, ce qui est préférable dans la plupart des cas.

Dans GitLens, un clic droit sur un commit > Revert Commit lance la même action. C’est utile si l’on veut annuler proprement une étape, tout en conservant sa trace dans l’historique. Par exemple, si l’on a ajouté une règle CSS qui perturbe l’affichage (Ajout d’un fond gris sur le body), on peut utiliser git revert pour revenir à l’état précédent tout en laissant un nouveau commit intitulé Revert "Ajout d’un fond gris sur le body". Cela permet de corriger sans effacer le passé, ce qui est particulièrement important dans un projet partagé ou lorsqu’on veut garder un historique compréhensible.

En résumé :

• restore → annuler une modification locale non commitée.
• reset → retirer un fichier de la zone de préparation.
• revert → créer un commit qui annule un commit précédent.

Créer une branche pour tester une autre approche

Comme pour le CSS, nous allons maintenant ajouter un fichier script.js contenant une première version très simple d’un comportement JavaScript. L’idée est d’afficher une alerte lorsqu’on clique sur un bouton. Pour aller vite, nous allons utiliser un onclick directement dans le HTML.

1. Ajout d’un script simple (inline onclick)

Dans le fichier index.html, on ajoute ce bouton :

<button onclick="saluer()">Clique ici</button>

Et dans un nouveau fichier scripts.js, on place :

function saluer() {
  alert("Bonjour depuis Git !");
}

Enfin, on relie ce script en bas de la page HTML :

<script src="scripts.js"></script>

Une fois le bouton fonctionnel, on enregistre les fichiers, on valide (git add) et on crée un nouveau commit :

git add index.html scripts.js
git commit -m "Ajout d’un script avec onclick HTML"

L’option -m signifie message (message en anglais), et elle permet de fournir directement le message du commit dans la même ligne de commande. C’est une manière rapide de décrire ce que l’on valide, sans ouvrir d’éditeur de texte.

2. Créer une branche pour tester une autre version

Avant de modifier notre script principal, nous allons créer une branche dédiée pour y tester une nouvelle méthode. Cela nous permet de développer une version alternative sans impacter le projet principal, en gardant une séparation claire entre ce qui est validé et ce qui est en cours d’expérimentation.

Dans le terminal, on peut créer cette branche et s’y placer immédiatement avec deux commandes successives :

git branch js-version-eventlistener   ## crée la branche
git checkout js-version-eventlistener ## bascule dessus

Mais Git permet aussi de gagner du temps en combinant les deux actions en une seule :

git checkout -b js-version-eventlistener
## -b indique qu’on veut créer une nouvelle branche
## js-version-eventlistener est le nom donné à cette branche

Une fois cette commande exécutée, notre environnement de travail reste le même, mais nous sommes désormais sur une autre piste de développement. Tout ce que nous allons faire maintenant sera isolé de la branche principale, jusqu’à ce qu’on décide — ou non — de le fusionner.

…et dans Visual Studio Code

Plutôt que d’ouvrir le terminal, nous pouvons créer une branche directement depuis l’interface visuelle. Pour cela, ouvrons le panneau Source Control, puis cliquons sur les trois points en haut à droite du bloc Modifications (menu contextuel). Dans le sous-menu Branch, choisissons Create Branch….

Un champ s’ouvre alors en haut de l’éditeur pour nommer la branche — ici, nous tapons js-version-eventlistener puis validons. Visual Studio Code crée immédiatement la branche et nous y positionne.

En bas à gauche de l’écran, le nom de la branche active s’affiche. Cela permet de vérifier en un coup d’œil qu’on n’est plus sur main, mais bien dans notre piste parallèle.

Deux branches, deux pistes, deux projets en parallèle

À partir du moment où nous avons créé une branche (js-version-eventlistener), notre projet se divise en deux versions parallèles. Ces deux branches partagent un tronc commun — l’historique jusqu’au moment de la séparation — mais à partir de là, chacune évolue de son côté.

Si nous modifions un fichier, ajoutons du code ou supprimons un élément dans la branche js-version-eventlistener, ces changements ne toucheront en rien la branche main. Et inversement : les évolutions que nous ferons plus tard sur main resteront invisibles dans js-version-eventlistener tant qu’aucune fusion n’est réalisée.

C’est une séparation volontaire et structurée. On ne duplique pas un dossier complet, on ne crée pas une copie physique. Git travaille à un autre niveau : celui de l’historique. Chaque branche trace une ligne de développement indépendante, qui garde la mémoire de ses propres décisions.

Pourquoi est-ce si important ?

Parce que c’est ce mécanisme qui permet à plusieurs personnes de travailler simultanément, sur des fonctionnalités différentes, sans écraser les changements des autres. Chacun avance sur sa propre branche, puis on décide ensemble de fusionner, comparer, ou garder séparé.

Dans notre cas, nous avons deux approches du JavaScript : une version simple avec onclick, une autre avec addEventListener. Rien ne nous oblige à choisir immédiatement. Nous pouvons explorer, tester, modifier, valider, sans stress, parce que chaque branche protège son contenu.

Identifier rapidement la branche en cours

Dans Visual Studio Code, il est facile de vérifier sur quelle branche nous nous trouvons. En bas à gauche de la fenêtre, juste à côté des icônes GitLens et de synchronisation, le nom de la branche active est affiché dans une étiquette. Si nous voyons “js-version-eventlistener”, c’est que nous sommes bien sur notre branche secondaire. Pour repasser à main, il suffit de cliquer sur ce nom, puis de sélectionner une autre branche dans la liste qui s’ouvre.

Ce petit détail d’interface devient un réflexe : à chaque ouverture de projet, un coup d’œil suffit pour savoir où l’on travaille.

Modifier notre script dans la branche secondaire

Nous sommes désormais dans la branche js-version-eventlistener, et tout ce que nous allons faire ici ne touchera pas la branche principale. C’est le moment idéal pour tester une nouvelle manière de coder notre interaction.

Dans le fichier index.html, nous allons supprimer l’attribut onclick et lui préférer un identifiant :

<button id="btnSaluer">Clique ici</button>

Et dans scripts.js, nous remplaçons la fonction précédente par un ajout d’événement JavaScript plus classique :

document.addEventListener("DOMContentLoaded", function() {
  document.getElementById("btnSaluer").addEventListener("click", function() {
    alert("Bonjour version EventListener !");
  });
});

Nous enregistrons les modifications, puis les ajoutons et les validons :

git add index.html script.js
git commit -m "Version JS avec addEventListener"

Dans Visual Studio Code, ces étapes peuvent aussi être faites visuellement : les fichiers modifiés s’affichent dans la palette Source Control, et un simple clic sur ✓ permet de créer le commit après avoir saisi un message.

Pendant ce temps, la branche principale évolue aussi…

Dans la vraie vie, les projets ne s’arrêtent pas de bouger pendant qu’on développe une nouvelle fonctionnalité. D’autres personnes peuvent continuer à travailler sur la branche principale, ou bien nous-mêmes pouvons y revenir pour faire avancer d’autres aspects du projet.

Revenons un instant sur la branche master pour y apporter quelques modifications indépendantes du JavaScript. Par exemple, nous pouvons étoffer la page HTML avec une nouvelle section de contenu, comme un bloc de témoignages :

<section>
  <h2>Témoignages</h2>
  <p>“Un site simple, mais efficace.”</p>
</section>

Ou encore, lier une feuille CSS supplémentaire :

<link rel="stylesheet" href="layout.css">

Ces ajouts font évoluer le projet dans une autre direction. Ils peuvent très bien être intégrés, validés, et committés dans la branche master :

git checkout main
# Ajout du HTML et du layout.css
git add index.html layout.css
git commit -m "Ajout d’une section témoignages et d’un fichier de mise en page"

Comparer les deux branches avant de fusionner

Avant de lancer une fusion, il est utile de visualiser ce que contient chaque branche. Cela permet d’anticiper les conflits éventuels et de comprendre quelles parties du projet ont évolué.

Dans le terminal, nous pouvons lister les commits récents de chaque branche :

…et dans Visual Studio Code

GitLens offre une vue graphique pratique. Ouvrons le panneau GitLens > Repositories, puis explorons la section Branches. En sélectionnant main, puis js-version-eventlistener, on voit immédiatement quelles modifications sont associées à chaque branche.

Pour aller plus loin, nous pouvons même comparer les deux branches directement dans l’interface :

• Dans GitLens, clic droit sur une branche (ex. main)
• Choisir Compare with Current
• La liste des fichiers modifiés entre les deux s’affiche, ligne par ligne, avec les ajouts et suppressions en couleur

Ces visualisations permettent de mieux comprendre ce que Git va devoir gérer au moment de la fusion : dans notre cas, nous avons modifié index.html et ajouté un fichier layout.css sur la branche principale, pendant que notre branche secondaire apportait une nouvelle version de script.js. Ces changements ne se connaissent pas encore.

C’est le moment de fusionner… mais pour bien comprendre les limites de Git, nous allons volontairement créer une situation de conflit. Car lorsqu’une même ligne est modifiée dans deux branches différentes, Git ne peut pas deviner laquelle choisir. Et c’est là que nous devons intervenir.

Fusionner deux branches… mais pas sans heurts

C’est le moment de fusionner… mais pour bien comprendre les limites de Git, nous allons volontairement créer une situation de conflit. Lorsqu’une même ligne est modifiée différemment dans deux branches, Git ne peut pas choisir à notre place. Il nous le signale, et c’est à nous de résoudre ce désaccord.

Imaginons qu’en parallèle de notre travail sur la branche js-version-eventlistener, quelqu’un ait modifié le titre principal de la page dans la branche master.

Dans master, ouvrons index.html et modifions le <h1> :

<h1>Page Git — Version principale</h1>

Nous enregistrons, ajoutons et validons cette version :

git add index.html
git commit -m "Modification du titre principal dans master"

Basculons ensuite sur la branche js-version-eventlistener, et modifions la même ligne avec une autre formulation :

<h1>Page Git — Version JS modifiée</h1>

Là aussi, nous enregistrons, ajoutons et validons cette modification :

git add index.html
git commit -m "Modification du titre principal dans branche JS"

Une fusion… et un conflit à résoudre

Nous sommes maintenant dans un cas classique : deux branches ont modifié la même ligne dans le même fichier, chacune dans son propre commit.

Pour fusionner, nous devons nous placer sur la branche qui recevra les changements, autrement dit celle que nous voulons enrichir. Ici, c’est master qui servira de base, et nous allons y injecter les apports de js-version-eventlistener.

Plaçons-nous donc sur main, et lançons la tentative de fusion :

git checkout master
git merge js-version-eventlistener

Git s’arrête aussitôt. Il détecte le conflit et affiche un message clair : certaines modifications ne peuvent pas être automatiquement fusionnées. En l’occurrence, c’est index.html qui pose problème. Tant que ce conflit ne sera pas résolu, Git ne fusionne rien du tout, même pas les fichiers qui ne posent aucun souci. Toute la fusion est suspendue, dans un état intermédiaire.

…et dans Visual Studio Code

Il est possible de fusionner deux branches sans passer par le terminal, mais la démarche n’est pas immédiate. Nous devons d’abord nous placer sur la branche qui recevra les modifications — ici, master. Pour cela, il suffit de cliquer sur le nom de la branche active, tout en bas à gauche de l’interface, et de choisir master dans la palette qui s’ouvre.

Une fois positionné sur master, nous ouvrons le panneau Source Control, puis nous cliquons sur les trois points verticaux pour accéder au menu contextuel. Là, nous choisissons Branches, puis Merge Branch…. Une liste de toutes les branches disponibles s’affiche, et il ne reste plus qu’à sélectionner js-version-eventlistener. Si tout se passe bien, Git fusionne automatiquement. Mais s’il détecte un conflit, aucun fichier n’est encore fusionné : le processus s’interrompt, les fichiers concernés sont signalés, et c’est à nous de résoudre le désaccord.

Visual Studio Code nous bascule alors automatiquement dans le Merge Editor, un espace dédié à la résolution des conflits. Ce mode présente, côte à côte, les deux versions du code : la nôtre (celle de master) et celle entrante (issue de la branche que nous tentons de fusionner). En bas de chaque segment, des boutons permettent d’accepter une version, accepter les deux, ou éditer manuellement le résultat final.

Une fois le conflit résolu, il suffit d’enregistrer le fichier, de l’ajouter à la zone de préparation (git add ou via l’interface), puis de créer un commit. Ce commit spécifique termine la fusion et inscrit son point d’ancrage dans l’historique.

Supprimer une branche après fusion

Une fois la fusion réussie et validée, la branche utilisée pour expérimenter n’est souvent plus nécessaire. C’est le cas ici avec js-version-eventlistener, qui a rempli son rôle. Pour garder un dépôt clair et lisible, on peut la supprimer — cela n’efface aucun historique, tous les commits sont déjà intégrés à la branche principale.

En ligne de commande, il suffit de taper :

git branch -d js-version-eventlistener
# La branche est supprimée, si elle a bien été fusionnée

Git vérifie automatiquement que cette branche a été fusionnée. Si ce n’est pas le cas, il bloque l’opération (sauf si on force avec -D, ce que nous ne ferons pas ici).

Dans Visual Studio Code, on peut faire la même chose depuis le panneau Source Control. Dans le menu contextuel (trois points), choisir Branches > Delete Branch..., puis sélectionner js-version-eventlistener dans la liste proposée.

Cette action de nettoyage est saine : elle n’enlève rien à l’historique, mais nous permet de garder un projet organisé.

À retenir : supprimer avec précaution

Supprimer une branche avec -d est une mesure de sécurité. Git vérifie que tous les changements ont bien été fusionnés avant de l’autoriser. Si ce n’est pas le cas, la commande est bloquée. En revanche, l’option -D supprime la branche sans poser de question, même si elle contient encore du travail non intégré. Mieux vaut donc éviter cette option, sauf si l’on est absolument sûr de ne plus rien vouloir conserver.

Conclusion : comprendre avant de collaborer

Dans ce second article, nous avons franchi une étape essentielle : explorer l’évolution d’un projet dans le temps, créer des versions, corriger des erreurs, et gérer des branches de développement. Ces opérations, réalisées en local, nous permettent déjà de mieux comprendre comment Git fonctionne.

Nous n’avons encore rien envoyé vers l’extérieur. Mais déjà, les enjeux se dessinent : que devient une branche une fois fusionnée ? Comment garder un historique propre ? Et surtout, comment travailler à plusieurs sans s’écraser mutuellement ?

C’est ce que nous verrons dans le prochain article, en abordant la connexion à GitHub, le partage d’un dépôt distant, et les premiers pas de collaboration.