Utilisation de Git (avancé)

Git est bien plus qu’un simple outil de versionnement. Il vous permet aussi de naviguer dans l’historique de votre projet, de revenir à une version antérieure, d’explorer l’origine d’un bug ou encore d’expérimenter en toute sécurité sur des branches parallèles. Grâce à ses commandes, vous pouvez isoler des fonctionnalités, fusionner ou réorganiser vos travaux, et même annuler proprement des modifications, que vous travailliez seul ou en équipe. Dans ce module, nous allons découvrir comment tirer parti de ces possibilités : explorer les commits passés, manipuler les branches, comprendre les fusions (merge et rebase), se déplacer dans l’arbre des versions avec des références relatives, et annuler des changements avec précision. Comprendre ces déplacements dans l’historique de Git vous donnera une grande liberté et une meilleure compréhension de l’évolution de votre code.

Branches dans Git

Les branches sont des copies indépendantes de votre code créées à un instant précis. Elles vous offrent un espace d'expérimentation où vous pouvez tester des idées et développer des fonctionnalités sans affecter le code principal. Chaque branche évolue en parallèle avant d'être éventuellement fusionnée.

La branche principale (main/master) sert de référence : elle représente la version stable et fonctionnelle de votre projet, contenant uniquement les modifications validées et testées. Le développement de nouvelles fonctionnalités et la correction de bugs se font systématiquement sur des branches dédiées.

    En octobre 2020, GitHub a changé la terminologie de "master" à "main" pour des raisons d'inclusivité. Les anciens projets utilisent souvent encore "master", tandis que les nouveaux projets utilisent "main.

Les préfixes les plus courants pour les nouvelles branches créees que vous verrez dans les noms de branches sont :

  • feat/ ou feature/ : indique que vous ajoutez une nouvelle fonctionnalité.
    Exemple : feature/hyperparametrage ou feature/previsions
  • fix/ ou bugfix/ : implique que vous ne prévoyez pas d'ajouter de nouvelles fonctionnalités, mais que vous corrigez un problème dans une fonctionnalité existante.
    Exemple : bugfix/erreur-pretraitement ou fix/modele-churn

Les branches dans Git sont extrêmement légères : ce ne sont que des pointeurs vers un commit donné. Cela signifie qu’il n’y a pratiquement aucun coût en termes de mémoire ou de performance à en créer, ce qui encourage la bonne pratique : branchez tôt, branchez souvent.

Création d'une branche

Travailler avec plusieurs branches vous permet d’isoler des modifications, de tester sans risquer de casser la version principale, et de collaborer plus efficacement. Une branche représente l’intention d’inclure un ensemble de commits, à partir d’un point précis de l’historique.

Il existe deux manières de créer une branche :

Depuis votre machine (local) :

  • Clonez d’abord le dépôt (git clone <URL>).
  • Créez la branche sur votre machine (git checkout -b nom-de-la-branche), effectuez vos modifications puis poussez-la vers GitHub (git push -u origin nom-de-la-branche).
  • GitHub recevra alors automatiquement cette nouvelle branche.

Depuis l’interface GitHub :

  • Créez directement la branche dans le navigateur (interface web GitHub).
  • Ensuite, soit vous clonez le dépôt, soit vous récupérez cette branche spécifique (git fetch suivi de git checkout) pour travailler dessus localement.

L’avantage de cette deuxième méthode est que Github (ou tout autre hébergeur Git) représente la source de vérité centralisée. Si vous créiez la branche uniquement sur votre machine, vous auriez d’abord besoin de récupérer la version la plus récente de la branche principale (en exécutant un git pull) avant de basculer dessus, afin d’éviter de travailler sur une version obsolète. Rien de compliqué, mais un pas supplémentaire.

Vous pouvez cependant choisir la méthode qui vous semble la plus simple ou la plus pratique.

Nous allons voir comment ces branches interagissent entre elles lors des opérations de fusion (merge) ou de réécriture de l’historique (rebase). La gestion des branches est l’un des aspects les plus puissants mais aussi les plus délicats de Git. Bien la comprendre, c’est poser les bases d’un flux de travail solide et maîtrisé.

Exercice pratique

Pour connaître les branches présentes dans votre projet, tapez la commande suivante :

git branch

Dans un premier temps, vous n’aurez que :

git branch
* main

L’étoile signifie que vous êtes actuellement sur la branche main, et que c’est sur celle-ci que vous réalisez vos modifications.

Nous avons notre branche main, et nous souhaitons maintenant créer la branche nouvelle-feature. Pour cela, tapez : 

git branch nouvelle-feature

Cette commande va créer la branche nouvelle-feature en local. Vous pouvez vérifier les branches disponibles en tapant à nouveau :

git branch
* main
nouvelle-feature

Vous voyez maintenant votre branche principale (main) et votre nouvelle branche nouvelle-feature. L’étoile indique que vous êtes toujours sur la branche main.

Pour basculer sur la branche nouvelle-feature, utilisez la commande :

git checkout nouvelle-feature

Après avoir basculé, vous verrez :

git branch
main
* nouvelle-feature

La branche nouvelle-feature fonctionne comme un dossier virtuel. Avec git checkout, vous êtes téléporté dans ce dossier virtuel. Vous pouvez maintenant réaliser vos modifications sans toucher à la branche main, qui contient votre code principal fonctionnel.

Si nécessaire, vous pouvez re-basculer à tout moment sur la branche main, sans impacter les modifications de la branche nouvelle-feature.

Résumé des commandes Git pour la gestion des branches :

  • git branch : Affiche la liste des branches locales.
  • git branch nouvelle-branche : Crée une nouvelle branche.
  • git switch main ou git checkout main : Change de branche.
  • git checkout -b nouvelle-branche : Crée et bascule sur une nouvelle branche.
  • git branch -m ancien-nom nouveau-nom : Renomme une branche.

Fusionner des branches

Maintenant que nous avons vu les commits et la gestion de branches, il est temps de voir comment combiner le travail effectué sur différentes branches. Voyons comment réunir le travail de deux branches. Imaginez : vous créez une branche pour ajouter une nouvelle fonctionnalité (c'est un peu ce que nous avons fait dans la section précédente), puis vous ramenez les modifications effectuées dans la branche principale (main ou master). C'est ce qu'on appelle fusionner ou merge des branches.

Fusionnez votre travail avec la commande git merge

La première méthode pour fusionner deux branches est git merge. Elle crée un commit spécial qui combine les modifications des deux branches. Cela préserve l'historique de chaque branche, montrant clairement quand et où les changements ont été faits. C'est comme si vous aviez deux chemins distincts qui se rejoignent à un point précis.

Pour illustrer le merge, reprenons l'exemple de la branche nouvelle-feature que nous avons créée précédemment. On a donc développé une nouvelle fonctionnalité avec plusieurs commits et pushs. Le travail est maintenant terminé et testé.

L'étape suivante consiste à intégrer ces modifications dans la branche principale main. Pour cela, nous utiliserons la commande git merge.

Cette commande doit s'utiliser à partir de la branche dans laquelle nous voulons apporter les évolutions. Dans notre cas, la commande s’effectuera donc dans la branche main. Pour y retourner, utilisez la commande :

# Changer pour la branche principale
git checkout main

Maintenant que vous êtes dans votre branche principale main, vous pouvez fusionner votre branche nouvelle-feature à celle-ci grâce à la commande suivante : 

# Fusionner la branche nouvelle-feature dans main   
git merge cagnotte
      Contrairement à git merge qui crée un commit de fusion, git rebase réécrit l'historique en plaçant vos commits à la suite de la branche cible. Exemple : git rebase main depuis nouvelle-feature déplace vos commits après ceux de main , créant un historique linéaire.

Proposer vos modifications avec une Pull Request

Dans les sections précédentes, nous avons vu comment fusionner des branches localement avec git merge. Cependant, en contexte professionnel, le workflow est différent. La branche principale (main) est généralement protégée : vous ne pouvez pas y pousser directement vos modifications. Avant toute fusion, votre code doit être validé par l'équipe. C'est ici qu'interviennent les Pull Requests (PR).

Une Pull Request (PR) est un mécanisme qui permet de proposer vos modifications à une équipe ou ensemble de développeurs avant leur intégration dans la branche principale. Au lieu de fusionner directement, vous soumettez vos changements pour revue et validation.

Les prérequis pour créer une Pull Request (PR) sont :

  • Avoir créé une branche de travail (ex: feature/nouvelle-fonctionnalite).
  • Avoir développé et commité vos modifications sur cette branche.
  • Avoir poussé cette branche sur le dépôt distant (Github) avec git push.

Après avoir poussé votre branche sur GitHub, le site détecte automatiquement la nouveauté et affiche un bandeau jaune proposant de créer une Pull Request. Cliquez sur "Compare & pull request", vérifiez que la branche de destination est bien main et que votre branche de travail est correctement sélectionnée. Rédigez un titre clair et une description expliquant vos modifications, leurs raisons et la manière de les tester. Cliquez ensuite sur "Create pull request" pour finaliser la création.

Le processus de revue de code

Sur les projets professionnels en entreprise et open source, votre code ne peut être fusionné immédiatement dans la branche principale. Il doit d'abord passer par une revue de code (Code Review). Cette étape permet de :

  • Détecter les erreurs potentielles.
  • Améliorer la qualité du code.
  • Partager les connaissances au sein de l'équipe.
  • Valider les choix techniques.

Les membres de votre équipe examineront votre Pull Request, commenteront des lignes spécifiques, suggéreront des améliorations ou demanderont des modifications. Vous recevrez des notifications pour chaque commentaire et pourrez y répondre ou pousser de nouveaux commits sur la même branche pour effectuer les ajustements demandés.

Une fois que les reviewers ont approuvé votre Pull Request, elle peut être fusionnée dans la branche principale. Cliquez sur "Merge pull request" puis confirmez avec "Confirm merge". Vos modifications sont maintenant intégrées dans main. Vous pouvez ensuite supprimer la branche de fonctionnalité directement depuis l'interface GitHub.

Corriger les erreurs courantes

Malgré toutes les précautions, il arrive parfois de faire des erreurs avec notre dépôt local ou distant. Heureusement, Git offre plusieurs outils pour corriger ces erreurs sans perdre notre travail. Nous allons explorer quelques-unes des situations et voir comment les gérer efficacement.

Que faire si j'ai modifié la mauvaise branche ?

Parfois, vous devez changer de branche alors que vous avez des modifications non commitées, ou vous réalisez que vous avez travaillé sur la mauvaise branche par erreur. La commande git stash vous permet de mettre ces modifications de côté temporairement.

Supposons que vous ayez modifié des fichiers sur main alors que ces changements auraient dû être effectués sur une branche séparée. La solution consiste à mettre temporairement vos modifications en attente, basculer vers une nouvelle branche, et récupérer ensuite votre travail.

# Vérifier l'état des modifications    
git status

# Ranger les modifications temporairement
git stash   

# Confirmer que les modifications ont bien été mise de côté 
git status

# Créer la branche appropriée
git checkout -b feature/ma-branche  

# Récupérer les modifications (git stash apply + git stash drop)
git stash pop

Vos modifications sont maintenant sur la bonne branche, prêtes à être commitées ! Le stash vous permet de corriger cette erreur courante sans perdre votre travail ni polluer l'historique de main.

Que faire si j'ai fait un commit sur main par erreur ?

Si vous avez non seulement modifié des fichiers sur main, mais aussi commité ces changements, vos modifications sont maintenant enregistrées dans l'historique de la branche principale, là où elles ne devraient pas être. Pour corriger cette erreur, vous devez d'abord identifier le commit problématique.

La première étape consiste à identifier le commit fautif avec git log, qui liste vos commits du plus récent au plus ancien. Notez le hash (identifiant unique) du commit à corriger.

    Chaque commit contient des métadonnées (date, auteur, message) ainsi qu'une référence au commit parent. Cette structure en chaîne permet à Git de reconstituer l'historique complet du projet

Attention : Si vous avez déjà poussé ce commit sur un dépôt distant (GitHub), modifier l'historique peut compliquer les choses pour les autres collaborateurs. Assurez-vous de communiquer avec votre équipe avant de procéder.

Pour revenir sur un commit précédent et le déplacer vers une nouvelle branche, suivez les étapes ci-dessous:

Commencez par afficher l’historique des commits avec la commande suivante :

git log
ca83a6dff817ec66f443420071545390a954664949 Author: Louis 
Date: Mon Mar 11 18:02:11 2025 -0733

Maintenant que vous disposez de l’identifiant du commit, gardez-le bien de côté.

Vérifiez que vous êtes sur votre branche principale et réalisez la commande suivante pour supprimer le dernier commit de la branche principale :

git reset --hard HEAD^

Cette commande va supprimer de la branche principale votre dernier commit. Le HEAD^ indique que c'est bien le dernier commit que nous voulons supprimer. L’historique sera changé, et les fichiers seront supprimés.

Créez et basculez vers une nouvelle branche avec la commande suivante :

git checkout -b nouvelle-branche

Renouvelez la commande git reset, qui va appliquer ce commit sur votre nouvelle branche :

git reset --hard ca83a6df

Il n'est pas nécessaire d'écrire l'identifiant en entier. Seuls les 8 premiers caractères sont nécessaires.

Avec Git, remonter dans le temps pour explorer des versions précédentes de votre projet est à la fois simple et puissant. Que ce soit via l’interface de votre éditeur (comme la section Commits de VS Code) ou en ligne de commande avec git log, chaque commit est identifié par un hash unique, une sorte d’empreinte numérique. Pour revenir à un état antérieur du code, il suffit d’utiliser la commande git checkout <hash_du_commit>.

Plus vos commits sont petits, fréquents et accompagnés de messages clairs, plus il sera facile de localiser l’introduction d’un bug. Une bonne hygiène de versionnage permet souvent d’éviter des retours en arrière trop brutaux, voire de contourner complètement le besoin d’un revert. D’ailleurs, Git ne se limite pas à des déplacements linéaires dans l’historique : il offre une grande souplesse pour naviguer, expérimenter et restructurer votre travail.

Que faire si le message de mon commit est erroné ?

Lorsque l'on travaille sur un projet avec Git, il est important de marquer correctement les modifications effectuées dans le message descriptif. Cependant, si vous faites une erreur dans l'un de vos messages de commit, il est possible de changer le message après coup.

L'exécution de cette commande, lorsqu'aucun élément n'est encore modifié, vous permet de modifier le message du commit précédent. L'option -m permet de transmettre le nouveau message :

git commit --amend -m "Votre nouveau message de commit"

Cette commande fonctionne uniquement pour le dernier commit réalisé. Si vous avez déjà poussé ce commit sur un dépôt distant, veillez à communiquer avec votre équipe avant de modifier l'historique.

Que faire si j’ai oublié un fichier dans mon dernier commit ?

Imaginons une situation courante : vous venez de commiter votre travail, mais vous réalisez soudain qu'un fichier a été oublié. Un premier réflexe serait probablement de faire un git add du fichier manquant suivi d'un nouveau git commit. Bien que cete approche fonctionne techniquement, elle présente un inconvénient majeur : elle crée un commit supplémentaire qui n'apporte pas de valeur réelle à l'historique du projet. Cette pollution de l'historique peut sembler anodine sur le moment, mais transposée à l'échelle d'un projet professionnel avec plusieurs collaborateurs, l'accumulation de ces commits peut rendre rapidement l'historique illisible. La conséquence directe est la perte de l'un des principaux atouts de Git : maintenir une traçabilité claire et compréhensible de l'évolution du projet.

Dans notre cas, on va utiliser la commande git commit --amend sans l'option -m, qui sert à modifier le message du commit. 

# Ajout du fichier oublié
git add fichier.txt

Après avoir ajouté le fichier oublié avec git add, vous pouvez exécuter la commande suivante pour inclure ce fichier dans le dernier commit sans modifier son message :

# Modifier le dernier commit pour inclure le fichier ajouté
git commit --amend --no-edit

Le fichier oublié a été ajouté à votre dernier commit, et grâce à l'option --no-edit, le message du commit n'a pas été modifié.

Si aucun changement n'est en attente, l'option --amend peut être utilisée pour modifier uniquement le message du dernier commit en ajoutant l'option -m.

Comment annuler un commit ? git revert vs git reset

Il arrive parfois que vous deviez annuler des commits. Git propose deux approches principales : git revert, qui préserve l’historique, et git reset, qui le réécrit. Chaque méthode s’applique à des contextes différents.

git revert : Annuler sans toucher à l’historique

La commande git revert crée un nouveau commit qui inverse les modifications d’un commit précédent. L’historique reste intact : le commit original existe toujours, suivi de son annulation. 

# Annule le dernier commit               
git revert HEAD    
                 
# Annule un commit spécifique
git revert abc1234

Si votre commit a ajouté, par exemple, une ligne de code, git revert crée un commit qui supprime cette ligne. Le résultat final est identique à avant le commit problématique, mais l’historique montre les deux étapes.

Quand l’utiliser :

  • Sur des branches partagées (main, dev).
  • Après avoir poussé vos commits.
  • En production pour corriger rapidement.
  • Quand vous voulez une traçabilité complète.

⚠️ Attention : Commitez ou stashez vos modifications en cours avant d’exécuter git revert.

git reset : Réécrire l’historique (branches locales uniquement)

La commande git reset déplace votre branche vers un commit antérieur, supprimant les commits suivants de l’historique. Il existe trois modes selon ce que vous voulez conserver :

git reset --hard : Tout effacer

 git reset --hard HEAD~1  # ou : git reset --hard HEAD^

Cette commande efface les commits suivants dans l’historique, les modifications non commitées et les fichiers stagés.

⚠️ Attention: Cette commande est irréversible. Tout est perdu définitivement. L'utiliser sur une branche locale privée où vous voulez recommencer de zéro.

git reset --mixed : Conserver les modifications (mode par défaut)

git reset HEAD~    # ou : git reset --mixed HEAD~

Cette commande efface les commits de l’historique et elle conserve vos modifications de fichiers (désindexées). L’utiliser quand vous voulez refaire votre commit différemment. Les fichiers restent modifiés, vous pouvez les ajuster puis recommiter.

git reset --soft : Tout conserver

git reset --soft HEAD~3     # Annule 3 commits, garde tout stagé

Cette commande efface les commits de l’historique. Elle concerve les modifications et staging (prêt à commiter). L'utiliser quand on veut regrouper plusieurs petits commits en un seul.

git reset --soft HEAD~5

# Un seul commit propre
git commit -m "feat: fonctionnalité complète"

Pour résumer:

  • Branche partagée ou commits poussés : Utilisez git revert.
  • Branche locale privée : Utilisez git reset (mode selon besoin).
Comment retrouver et restaurer une ancienne version tout en identifiant les contributeurs ?

La commande git log affiche l'historique des commits par ordre chronologique inversé (du plus récent au plus ancien). Chaque commit montre son identifiant SHA, l'auteur, la date et le message descriptif.

git log

Le SHA (Secure Hash Algorithm) est l'identifiant unique de chaque commit. Cette longue chaîne de caractères vous permet de revenir précisément à n'importe quel point de l'historique.

Pour un historique encore plus complet, utilisez git reflog. Cette commande enregistre absolument toutes vos actions locales : commits, merges, resets, modifications de messages, changements de branches, entre autres.

git reflog

Avec cette commande, vous pouvez revenir à un état spécifique de votre projet en utilisant l'identifiant SHA correspondant.

git checkout e789e7c
Comment récupérer un commit spécifique d'une autre branche ?

Sur des projets d'équipe, vous aurez parfois besoin d'intégrer un commit spécifique d'une branche sans fusionner toute la branche. C'est le rôle de git cherry-pick. Cependant, cette commande est peu recommandée car elle duplique des commits.

Immaginez que vous travaillez sur une branche nouvelle-branche avec plusieurs commits. Votre collègue a besoin d'une seule de ces évolutions pour la livrer au client, mais pas des autres. git cherry-pick permet de récupérer ce commit spécifique sur la branche principale sans fusionner toute votre branche. 

# Se placer sur la branche principale
git checkout main

# Copie un commit spécifique
git cherry-pick d356940

# Copie plusieurs commits
git cherry-pick d356940 de966d4

Cette commande duplique les commits sélectionnés (via leur SHA) sur la branche actuelle. Les commits originaux restent dans nouvelle-branche, créant ainsi des doublons dans l'historique.

Utilisez git cherry-pick uniquement en dernier recours. Un workflow de branches bien organisé avec des merges réguliers évite généralement d'en avoir besoin.

Comment réorganiser l'historique avec git rebase ?

Git rebase permet de réécrire l'historique en déplaçant ou combinant des commits pour maintenir un historique propre et linéaire.

Considérons un scénario fréquent dans le travail collaboratif. Vous développez consciencieusement sur votre branche feature, en prévoyant de la fusionner avec main une fois votre travail terminé. Pendant ce temps, votre équipe découvre et corrige un problème critique sur la branche principale. Votre branche, qui partait initialement du dernier commit de main, se retrouve maintenant désynchronisée, et vous devez impérativement intégrer ce correctif dans votre travail en cours. La solution immédiate qui vient à l'esprit consiste à se placer sur votre branche feature et effectuer un git merge main. Cette approche fonctionne et intègre effectivement le correctif via un commit de merge, mais elle présente le même défaut récurrent : elle complexifie inutilement l'historique du projet. Le commit de merge créé n'apporte pas de valeur fonctionnelle et rend la lecture de l'historique moins claire, particulièrement lorsque cette situation se répète fréquemment dans un projet actif.

C'est ici qu'intervient git rebase, une commande qui permet de réécrire l'historique de votre branche feature. Plutôt que de créer un commit de merge, le rebase déplace littéralement votre branche pour la faire repartir de la pointe actuelle de main, comme si vous aviez créé votre branche après l'application du correctif. L'historique reste ainsi linéaire et lisible, comme le montre l'image ci-dessous

Le rebase interactif (git rebase -i) vous permet de modifier l'historique local en combinant, réorganisant ou supprimant des commits. Cela est particulièrement utile pour nettoyer l'historique avant de partager votre travail.

# Réécrit les 3 derniers commits
git rebase -i HEAD~3

Utilisez git rebase pour maintenir un historique linéaire, en particulier sur des branches locales avant de les fusionner dans la branche principale. Vous pouvez cependant utiliser git merge pour conserver l'historique complet des branches, en particulier sur des branches partagées.

⚠️ Attention :Ne jamais rebaser des commits déjà poussés sur une branche partagée. Cela peut entraîner des conflits et des problèmes pour les autres contributeurs.

Comment annuler un commit problématique ?

Il arrive parfois que vous deviez annuler des commits. Git propose deux approches principales : git revert, qui préserve l’historique, et git reset, qui le réécrit. Chaque méthode s’applique à des contextes différents.

Pour annuler efficacement un commit problématique, encore faut-il savoir lequel cibler. Git met à disposition plusieurs approches pour cette recherche. Face à un bug dont l'origine dans l'historique reste floue, git bisect applique une stratégie de recherche binaire qui permet d'isoler rapidement le commit recherché.

# Démarrer git bisect
git bisect start

# Pour indiquer que le commit le plus récent contient le problème
git bisect bad HEAD

# Pour récupérer un sha-commit-valide
git log

# Indiquer un commit fonctionnel
git bisect good sha-commit-valide

=== À partir de là, Git va automatiquement vous placer sur un commit intermédiaire ====

# Répétez cette étape jusqu'à ce que Git identifie le commit problématique ou non
git bisect good ou git bisect bad

=== Une fois le commit problématique identifié, Git vous l'indique - Copiez le sha-commit-problématique ====

# Pour terminer la recherche et revenir à l'état initial
git bisect reset

# Pour annuler le commit problématique une fois identifié
git revert sha-commit-problématique

La commande git revert crée un nouveau commit qui inverse les modifications d’un commit précédent. L’historique reste intact : le commit original existe toujours, suivi de son annulation. 

# Annule le dernier commit               
git revert HEAD    
                  
# Annule un commit spécifique
git revert abc1234

Si votre commit a ajouté, par exemple, une ligne de code, git revert crée un commit qui supprime cette ligne. Le résultat final est identique à avant le commit problématique, mais l’historique montre les deux étapes.

Quand l’utiliser :

  • Sur des branches partagées (main, dev).
  • Après avoir poussé vos commits.
  • En production pour corriger rapidement.
  • Quand vous voulez une traçabilité complète.

⚠️ Attention : Commitez ou stashez vos modifications en cours avant d’exécuter git revert.

git reset : Réécrire l’historique (branches locales uniquement)

La commande git reset déplace votre branche vers un commit antérieur, supprimant les commits suivants de l’historique. Il existe trois modes selon ce que vous voulez conserver :

git reset --hard : Tout effacer

git reset --hard HEAD~1  # ou : git reset --hard HEAD^

Cette commande efface les commits suivants dans l’historique, les modifications non commitées et les fichiers stagés.

⚠️ Attention : Cette commande est irréversible. Tout est perdu définitivement. L'utiliser sur une branche locale privée où vous voulez recommencer de zéro.

Le rôle de HEAD

Un concept central dans Git est HEAD. Il s’agit d’un pointeur symbolique qui désigne le commit actuel – autrement dit, le point de départ de toutes vos actions. En général, HEAD pointe vers le dernier commit d’une branche (par exemple, bugFix).

Chaque fois que vous effectuez un commit, Git enregistre les modifications, met à jour la branche active et avance automatiquement HEAD vers ce nouveau commit. C’est pourquoi HEAD est au cœur de nombreuses commandes Git comme commit, merge ou rebase.

Utiliser les identifiants de commits

Dans la pratique, vous n’aurez pas toujours un graphique visuel de l’historique à portée de main. Pour explorer les commits, il faudra souvent utiliser git log, qui vous fournit les identifiants uniques (hashes) de chaque commit.

Références relatives : une navigation simplifiée

Plutôt que de manipuler des identifiants complexes, Git offre une syntaxe plus simple et intuitive : les références relatives. Elles permettent de partir d’un point de référence connu (comme HEAD ou main) et de remonter l’historique avec des opérateurs :

L’opérateur ^
L’accent circonflexe (^) permet de remonter d’un parent. Par exemple :
main^ désigne le parent immédiat du dernier commit sur la branche main.
main^^ pointe vers le grand-parent (deux générations en arrière).

git checkout main^

L’opérateur ~
Le tilde (~) permet de remonter plusieurs commits d’un coup :
HEAD~4 signifie « 4 commits en arrière à partir de HEAD ».

git checkout HEAD~4

Les références relatives sont également utiles pour réorganiser les branches. Avec l’option -f, vous pouvez forcer une branche à pointer vers un autre commit :

git branch -f main HEAD~3

Cette commande replace la branche main trois commits avant HEAD. C’est un outil efficace pour corriger l’historique ou repositionner des branches lors de manipulations avancées.

Comprendre HEAD

HEAD représente votre position actuelle dans l’historique :

  • HEAD : Commit actuel.
  • HEAD~1 ou HEAD~ : Commit précédent.
  • HEAD~2 : Deux commits en arrière.
  • HEAD~3 : Trois commits en arrière.

Gestion des versions avec les Tags Git

Les tags Git constituent un mécanisme pour identifier et marquer les étapes importantes d'un projet. Contrairement aux commits qui sont destinés au développement, les tags peuvent être utilisés pour signaler les versions stables pour la production.

Un tag Git fonctionne comme une étiquette permanente attachée à un commit spécifique, permettant de retrouver facilement des versions importantes sans mémoriser des identifiants de commit. Le versionnage sémantique (v1.0.0, v1.2.3) s'impose comme standard pour structurer les releases de manière cohérente et prévisible.

git tag <nom-tag>        # Créer un tag sur le commit actuel
git checkout <nom-tag>   # Revenir à une version taguée
git tag v1.0.0               # Exemple avec versionnage sémantique

Trois approches se distinguent : les tags de version (v1.0.0) pour marquer des releases spécifiques, le tag "stable" pour identifier la dernière version fiable, et le tag "latest" pointant vers la version la plus récente. Cette flexibilité permet d'adapter le système de versionnage aux besoins spécifiques de chaque projet tout en maintenant une communication claire sur l'état des versions disponibles.

Pour aller plus loin

Je recommande vivement d’explorer cet outil interactif pour visualiser et expérimenter les concepts abordés ici. Il permet de manipuler HEAD, les références relatives (^, ~), et les branches dans un environnement visuel, ce qui facilite grandement la compréhension de Git.

Bonnes pratiques Git
1 modification = 1 commit
Essayez de garder vos commits petits, ciblés et cohérents. Ce n’est pas une règle absolue, mais suivre le principe “commitez tôt, commitez souvent” facilite la relecture, les tests et les retours en arrière.

Pour aller plus loin
Ce guide n’a pas pour objectif d’offrir une formation exhaustive sur Git.
Il se concentre volontairement sur les bases et les étapes clés d’un workflow Git courant.
Git est un outil puissant, avec de nombreuses fonctionnalités avancées que nous n’avons pas abordées ici.

  • 🔍 Visualiser et expérimenter Git – Visualizing Git
  • Learn Git Branching (version française)
  • GitHub – Git Cheat Sheet (PDF)
  • GitLab – Git Cheat Sheet (PDF)

Commandes Git avancées

Une fois à l'aise avec les bases, ces commandes enrichiront votre workflow :

Gestion des branches :

  • git branch : Liste toutes les branches locales
  • git branch -d feature-login : Supprime une branche fusionnée
  • git checkout -b nouvelle-feature : Crée et bascule sur une nouvelle branche
  • git switch main ou git checkout : Méthodes pour changer de branche

Navigation et historique :

  • git log --oneline : Affiche l'historique de manière compacte
  • git log --graph : Visualise l'arbre des commits
  • git diff : Montre les modifications non commitées

Collaboration avancée :

  • git merge feature-branch : Intègre une branche dans la branche courante
  • git rebase main : Réapplique vos commits sur une base mise à jour
  • git stash : Met temporairement de côté vos modifications
Contents