Pendant longtemps, beaucoup de développeurs utilisent Git de la même manière. Un dépôt, un dossier, une branche active à la fois. On change de branche, on stash, on revient, on oublie parfois ce qu’on avait laissé derrière. Ça marche, jusqu’au jour où le rythme se complique. Une feature en cours, un correctif urgent à sortir, une revue à reprendre après déjeuner, et tout à coup votre répertoire devient une salle d’attente pleine.

C’est là que git worktree commence à faire sens. L’idée est presque décevante de simplicité. Au lieu de faire vivre toutes vos branches dans le même dossier de travail, Git vous autorise à attacher plusieurs répertoires au même dépôt. Chaque répertoire peut pointer vers sa propre branche. Vous n’avez plus besoin de démonter votre contexte chaque fois qu’un autre sujet arrive.

Pourquoi changer de branche dans le même dossier finit par fatiguer

Le problème n’est pas seulement technique. Il est mental. Quand vous changez souvent de branche dans un même répertoire, vous devez sans arrêt vérifier l’état des fichiers, penser à stash ce qui traîne, vous rappeler sur quoi vous étiez, puis restaurer le bon contexte plus tard. Sur le papier, Git sait gérer. Dans la vraie vie, ça use l’attention.

Avec un worktree, vous gardez un dossier par sujet actif. Votre branche de correctif peut vivre dans un répertoire propre, votre feature dans un autre, votre branche de revue dans un troisième. Vous ouvrez simplement le bon dossier et vous retrouvez tout de suite le bon état mental. C’est bête à dire, mais ce confort change vraiment la fluidité de la journée.

Les cas où worktree devient immédiatement utile

Le premier cas, c’est l’urgence. Vous êtes en plein milieu d’un développement et on vous demande de corriger un bug en production. Sans worktree, vous commencez à jongler avec vos changements locaux. Avec worktree, vous créez un nouveau dossier lié à une branche de correctif, vous traitez le problème, puis vous revenez à votre travail initial sans avoir tout déplacé entre-temps.

Le deuxième cas, c’est la revue. Vous voulez tester une branche d’un collègue sans salir votre espace courant. Un worktree dédié règle le problème proprement. Le troisième cas, c’est le multi sujet classique d’une semaine normale, où plusieurs branches avancent en parallèle et où vous en avez assez de perdre le fil.

Dans ce type d’organisation, bien comprendre aussi la différence entre git fetch et git pull reste très utile, parce que chaque worktree continue à vivre avec ses remotes et ses mises à jour. Le confort vient du découpage des répertoires, pas d’une disparition magique des bonnes pratiques.

Ce que worktree ne fait pas à votre place

Il faut être honnête. git worktree ne remplace pas une méthode de travail. Si vos branches sont floues, elles resteront floues. Si vous ouvrez des sujets trop gros, vous aurez toujours des revues pénibles et des merges pénibles. Worktree enlève surtout la friction liée au changement de contexte.

Il ne faut pas non plus le voir comme un gadget réservé aux experts Git. La commande est plus simple qu’elle n’en a l’air. Une fois qu’on a créé deux ou trois worktrees, on comprend très vite le principe. Le plus dur, finalement, c’est souvent d’accepter qu’on peut arrêter de tout faire dans un seul dossier par habitude.

Pourquoi cette commande reste sous utilisée

Je pense qu’elle reste discrète pour une raison simple. Beaucoup de développeurs survivent très bien sans elle pendant des années. Donc ils ne vont pas spontanément chercher mieux. Ils ont appris à stasher, à changer de branche, à revenir en arrière, à recoller les morceaux. Ils se sont adaptés à la friction au lieu de la supprimer.

Pourtant, dès qu’on touche à des contributions parallèles ou à des remotes multiples, on sent vite l’intérêt. Si vous passez aussi par un dépôt personnel pour contribuer ou tester vos changements, vous croiserez tôt ou tard des situations où un fork Git est plus pratique qu’un simple clone. Là encore, worktree ne remplace pas le fork, mais il se combine très bien avec lui pour garder plusieurs contextes ouverts sans désordre.

Le déclic arrive souvent la première semaine d’usage. On ne gagne pas seulement quelques commandes. On récupère surtout une manière plus calme de passer d’un sujet à l’autre. Et quand un outil vous rend ce calme là, vous commencez vite à vous demander pourquoi vous avez attendu si longtemps avant de l’adopter.

Dès qu’on parle de revue de code, il y a deux excès qui arrivent vite. Le premier, c’est l’absence totale de cadre. Chacun pousse sur la branche principale et on espère que tout ira bien. Le second, c’est l’usine à gaz où chaque petit changement attend trois validations, deux cérémonies et une lune favorable. Entre les deux, il existe une façon très simple de travailler avec Git sans transformer la revue en punition.

Le point le plus important à comprendre, c’est que la revue n’a pas vocation à bloquer chaque geste du développeur. Elle intervient avant l’intégration dans la branche partagée, pas avant chaque sauvegarde de code ni avant chaque commit local. Cette précision change déjà beaucoup de malentendus.

La bonne unité de revue, ce n’est pas le commit isolé

Un commit peut être utile pour raconter l’avancée du travail, mais il n’est pas toujours la meilleure unité pour demander un avis. Ce qu’on relit vraiment, c’est un ensemble cohérent de modifications liées à un besoin, un bug ou une fonctionnalité. D’où l’intérêt de travailler sur une branche dédiée, puis d’ouvrir une pull request quand le sujet commence à ressembler à quelque chose de lisible.

Ça paraît banal, mais ça évite beaucoup de discussions stériles. Si vous demandez une revue sur un paquet de changements clair, avec un objectif compréhensible, les retours deviennent meilleurs. Si vous demandez une revue sur un amas de commits mal regroupés, même un bon collègue aura du mal à vous aider.

Une branche courte vaut mieux qu’une branche héroïque

Le vrai ennemi d’une revue fluide, ce n’est pas Git. C’est la branche qui reste ouverte trois semaines et accumule tout. À la fin, personne n’a envie de relire huit cents lignes touchant à la fois au backend, au CSS, à la config et aux tests. La revue devient lourde, donc elle traîne, donc elle agace, donc on cherche à la contourner.

Mieux vaut ouvrir des branches plus courtes, plus nettes, plus fréquentes. Une petite pull request reçoit plus vite un vrai retour. Elle se fusionne plus facilement. Elle produit aussi moins de conflits quand la branche principale bouge entre-temps.

Si votre équipe se mélange un peu dans les mises à jour distantes, ça vaut le coup de clarifier aussi ce qui change vraiment entre git fetch et git pull. Une revue se passe mieux quand chacun sait remettre sa branche à jour sans créer du bruit inutile.

Ce qu’on attend vraiment d’une revue utile

Une bonne revue ne sert pas à jouer au professeur sévère. Elle sert à repérer ce que l’auteur ne voit plus, à vérifier l’intention et à partager un peu de contexte. Ça peut être un bug potentiel, une convention oubliée, un nom trompeur, une complexité évitable, ou simplement une question honnête sur le choix technique.

Le ton compte énormément. Une remarque agressive transforme très vite la revue en sport de défense. Une remarque précise et calme aide tout le monde. Dire « je ne comprends pas cette condition, tu peux expliquer le cas métier ? » est souvent plus utile que lâcher un verdict sec sur la qualité du code.

On oublie aussi que la revue a une valeur collective. Elle diffuse les habitudes du projet. Elle montre comment les autres résolvent un problème. Avec le temps, elle évite que la connaissance reste coincée dans la tête de deux personnes.

Le fork, les droits et le bon niveau d’isolation

Selon le contexte, la revue peut se faire dans le dépôt principal ou à travers un fork. Dans une équipe interne, un simple workflow par branches suffit souvent. Sur des contributions externes, ou quand vous voulez isoler proprement le travail avant de le proposer, le fork rend la mécanique plus propre.

Si ce sujet vous parle, j’ai détaillé ici quand il vaut mieux utiliser un fork Git plutôt qu’un simple clone. Le choix du workflow influe directement sur la façon dont la revue se passe et sur le confort des personnes qui contribuent.

Le meilleur cadre, au fond, n’est pas le plus rigide. C’est celui qui rend la revue normale. Ouvrir une branche claire, écrire une demande relisible, répondre vite aux remarques utiles, fusionner sans drame et passer au sujet suivant. Quand une équipe arrive à ce rythme, Git cesse d’être un gardien et redevient ce qu’il aurait toujours dû rester, un outil de coordination assez simple pour laisser la place au vrai travail.

Le fork a longtemps eu une réputation un peu intimidante. On l’associe aux gros projets open source, aux pull requests publiques, à des workflows qui semblent réservés aux équipes bien rodées. Pourtant, l’idée est beaucoup plus simple que ça. Un fork, c’est une copie du dépôt sur votre propre espace distant. Un clone, lui, c’est juste une copie locale sur votre machine. Les deux servent à travailler. Ils ne servent pas à travailler dans la même relation avec le projet d’origine.

Quand on comprend cette nuance, on arrête de choisir entre fork et clone par imitation. On choisit selon le niveau d’autonomie qu’on veut garder et selon la façon dont on compte proposer ses modifications.

Le clone suffit très souvent

Si vous travaillez dans votre propre dépôt, ou dans celui de votre équipe avec les bons droits d’écriture, un clone suffit largement. Vous récupérez le projet sur votre machine, vous créez des branches, vous poussez vos changements et la journée continue. Pas besoin d’ajouter une couche de complexité pour le plaisir.

Le clone est aussi idéal quand la relation est directe. Vous appartenez à l’organisation, vous avez le droit de pousser, et la revue de code passe par des branches internes. Dans ce cas, multiplier les remotes avec un fork ne vous apporte pas grand-chose.

Ce qui compte ici, c’est de ne pas transformer Git en rituel. Si un clone répond au besoin, gardez le clone.

Le fork devient intéressant quand vous voulez une vraie zone à vous

Le fork prend tout son sens quand vous n’avez pas de droits d’écriture sur le dépôt source, ou quand vous préférez isoler votre travail sur votre propre dépôt distant. C’est le cas le plus connu dans l’open source. Vous créez votre fork sur GitHub ou GitLab, vous clonez ce fork sur votre machine, puis vous proposez vos changements au projet d’origine avec une pull request.

Cette approche a un autre avantage, moins spectaculaire mais très pratique. Votre fork vous appartient. Vous pouvez y pousser des branches de test, y garder des expérimentations, y faire le ménage à votre rythme sans salir le dépôt principal. C’est une vraie zone tampon.

Quand on découvre les bases de synchronisation distante, il vaut aussi la peine de bien distinguer ce que fait git fetch et ce que fait git pull. Si le sujet vous a déjà créé des surprises, vous pouvez lire aussi la différence entre git pull et git fetch. Dans un workflow avec fork, cette différence devient vite concrète.

Le rôle du remote upstream que beaucoup oublient

Le piège classique avec un fork, c’est de croire qu’une fois la copie créée, tout va se synchroniser magiquement. En réalité, votre fork peut vieillir très vite si le projet d’origine bouge tous les jours. C’est pour ça qu’on ajoute souvent un remote upstream qui pointe vers le dépôt source.

À partir de là, le schéma devient simple. origin désigne votre fork. upstream désigne le projet d’origine. Vous pouvez alors faire un git fetch upstream, récupérer les nouveautés du dépôt principal, puis remettre votre branche locale à niveau avant de pousser vers votre propre fork.

Dit autrement, le fork ne remplace pas la discipline Git. Il ajoute un étage de séparation entre votre espace et l’espace du projet principal. C’est utile, mais ça suppose de comprendre qui parle à qui.

Le fork et la revue de code vont très bien ensemble

Le fork est aussi confortable quand vous voulez proposer une contribution proprement empaquetée. Vous travaillez chez vous, vous poussez sur votre fork, puis vous ouvrez une demande de fusion. Le dépôt principal reste calme jusqu’au moment où quelqu’un décide d’intégrer votre travail. Cette logique est saine, surtout sur des projets où la qualité compte vraiment.

Si vous cherchez à mettre un peu de méthode dans les validations sans transformer l’équipe en administration, j’ai aussi détaillé comment organiser une revue de code avec Git sans ralentir l’équipe. Le fork n’est pas obligatoire pour relire du code, mais il se marie très bien avec une logique d’approbation claire.

Ce qui aide le plus, au fond, c’est de poser une question très simple avant de commencer. Est-ce que je travaille directement dans le dépôt principal, ou est-ce que j’ai intérêt à garder mon propre espace distant entre le projet et moi ? Si la réponse est la deuxième, le fork devient une évidence. Sinon, le clone fera très bien le travail, sans posture et sans bruit.

On voit souvent ces deux commandes comme des cousines tellement proches qu’on finit par les confondre. Dans les faits, elles n’ont pas le même effet psychologique sur votre journée. git fetch vous montre ce qui a bougé sans toucher à votre branche courante. git pull ramène les changements et essaye tout de suite de les intégrer. Dit comme ça, la différence a l’air minime. En réalité, elle change votre niveau de contrôle.

Le problème, ce n’est pas la syntaxe. Le problème, c’est le moment où vous découvrez qu’un collègue a poussé quelque chose qui entre en collision avec ce que vous faisiez depuis deux heures. Si vous utilisez Git tous les jours, ce détail finit par compter plus que la définition officielle.

Pourquoi ces deux commandes sont si souvent mélangées

La confusion vient d’un raccourci très humain. On veut simplement récupérer la dernière version du dépôt. Comme les deux commandes parlent au serveur et ramènent des nouveautés, beaucoup de développeurs se disent qu’elles font la même chose avec un emballage différent. Ce n’est pas faux, mais ce n’est pas suffisant pour travailler proprement.

Avec git fetch, Git met à jour vos références distantes. En clair, il télécharge l’état récent de origin/main, origin/dev ou d’autres branches distantes, mais il ne mélange rien dans votre branche locale. Vous pouvez regarder, comparer, respirer et décider.

Avec git pull, Git fait d’abord ce téléchargement, puis enchaîne avec une intégration. Selon votre configuration, ce sera souvent un merge, parfois un rebase. C’est pratique quand vous savez exactement ce que vous attendez. C’est moins confortable quand vous préférez inspecter avant de laisser Git toucher à votre branche.

Pourquoi git fetch est souvent le meilleur réflexe

J’aime bien git fetch pour une raison simple. Il n’impose rien. Il me laisse voir le delta avant de le subir. Après un fetch, je peux lancer un git log HEAD..origin/main, un git diff main origin/main ou juste vérifier si la branche distante a avancé plus que prévu.

Cette petite étape évite beaucoup de friction. Quand on travaille sur un dépôt un peu vivant, avec plusieurs merges dans la journée, faire un fetch revient à jeter un coup d’oeil avant d’ouvrir la porte. Vous savez si la maison est calme ou si quelqu’un a déplacé tous les meubles.

Si vous travaillez aussi avec des forks, cette habitude devient encore plus utile. Le jour où vous devez resynchroniser votre copie avec le dépôt d’origine, le mécanisme est le même. J’en parle plus en détail ici : quand utiliser un fork Git plutôt qu’un simple clone. Comprendre fetch dans ce contexte évite de bricoler à l’aveugle avec un remote upstream.

Quand git pull reste le bon outil

Il ne faut pas diaboliser git pull. Quand vous êtes sur une branche locale très simple, que vous savez qu’elle suit une branche distante précise et que vous voulez juste vous remettre à jour rapidement, c’est efficace. Beaucoup de gens commencent leur journée avec un pull sur main et ça se passe très bien.

Le vrai piège apparaît quand on lance git pull comme un réflexe nerveux au milieu d’un travail en cours. C’est là qu’on se retrouve avec un merge surprise, un conflit qu’on n’avait pas anticipé, ou pire, une branche locale modifiée qu’on comprend de moins en moins. Le souci n’est pas la commande. Le souci, c’est le manque de contexte au moment où on l’exécute.

Si votre équipe alterne entre plusieurs tâches, correctifs et revues, le besoin de contrôle devient encore plus visible. Dans ce cas, travailler avec des répertoires séparés peut faire gagner un temps fou. C’est exactement là que Git worktree devient très pratique quand une branche ne suffit plus, parce qu’on évite les allers-retours brouillons entre des états locaux différents.

Une routine simple pour ne plus subir

Une routine saine peut rester très légère. Sur une branche importante, commencez par un fetch. Regardez ce qui a changé. Si tout est propre et que vous voulez intégrer, choisissez ensuite votre geste, merge ou rebase selon vos habitudes. Cette séquence prend à peine plus de temps qu’un pull direct, mais elle vous rend beaucoup plus lucide.

Pour une branche personnelle courte, un pull peut suffire. Pour une branche exposée, surtout si d’autres personnes poussent régulièrement, fetch puis inspection reste souvent la voie la plus calme. Vous n’avez pas besoin d’un cérémonial compliqué. Vous avez juste besoin d’une pause de cinq secondes avant de demander à Git de combiner des histoires qui n’ont peut-être pas avancé au même rythme.

Au fond, git fetch répond à la question « qu’est-ce qui a changé là-bas ? ». git pull répond à « mets-moi à jour maintenant ». Quand on formule les choses comme ça, on choisit beaucoup mieux. Et dès qu’on choisit mieux, Git paraît soudain beaucoup moins capricieux.

Avec un repository publique, c’est facile de cloner, c’est accessible à tout le monde. Mais quand il s’agit de repository privé,et c’est souvent le cas pour les projet d’entreprise et vos saas, c’est devenu plus compliqué.

Avant il suffisait d’entre le nom etmot de passe, masi aujourd’hui cette méthode est dépréciée, pour plus de sécurité.

Il vous faudré générer un PAT (personal access token). Et pour rendre encore plus compliqué, il y a le PAT classique (qu’on va utiliser) et le PAT avec gestion fine des accès (Fine grained token).

git clone https://refschool:ghp_TON_PAT@github.com/refschool/team-of.git .

Saviez vosu que vous pouvez ne cloner qu’un répertoire ou plusieurs répertoire de votre repository Git? Ainsi vous économiserez de la place ! Ceci est particulièrement pertinent dans les monorepos, un monorepo est un repository unique mais avec plein de projets à l’intérieur. Google par exemple travaille en monorepo.

Vous savez alors qu’on ne peut pas cloner tous les projets de Google dsur son ordinateur, telle la volumétrie est grande. Il faut cloner ce dont on a besoin.

Comment fait on alors pour ne cloner ue partiellement un repository?

Vient la commande sparse checkout

Imaginez que vous êtes sur votre ordinateur et que vous vouliez cloner partiellement un repository, en ligne de commande voilà ce que l’on va faire

# Initialiser un nouveau dépôt Git
git clone --filter=blob:none --no-checkout https://github.com/vous/ledepot.git
cd ledepot

# Activer sparse-checkout
git sparse-checkout init --cone

# Spécifier le dossier à récupérer
git sparse-checkout set htdocs/todolist.com

# Récupérer les fichiers
git checkout main

Cette méthode vous permet néanmoins d’avoir l’historique des commits complet. Vous n’avez peut être pas besoin des commit précédents (on a rarement besoin), donc il est plus léger de n’avoir que le dernier commit.

Clonage encore plus light

git clone --depth 1 --filter=blob:none --sparse https://github.com/vous/ledepot.git
cd ledepot
git sparse-checkout set htdocs/todolist.com

• --depth 1 = télécharge uniquement le dernier commit (pas d’historique)
• Parfait si vous voulez juste travailler sur la version actuelle

Les blob sont des fichiers binaire, on a avec commande éviter des les télécharger.

Cette méthode télécharge uniquement les fichiers du dossier spécifié au lieu de tout le repository. L’option --cone optimise les performances pour les grandes arborescences, et --filter=blob:none évite de télécharger les blobs inutiles initialement.

Si vous voulez modifier le sparse-checkout plus tard pour ajouter d’autres dossiers :

git sparse-checkout add htdocs/autre-dossier

Un mot à propos du flag –cone

--cone fait référence au mode « cone » du sparse-checkout, qui est une approche optimisée pour gérer les patterns de fichiers.

Sans --cone (mode pattern traditionnel) :

• Vous pouvez spécifier des patterns complexes comme *.js, src/**/test
• Plus flexible mais plus lent sur les gros repositories
• Git doit vérifier chaque fichier individuellement

Avec --cone (mode cone) :

• Vous ne pouvez spécifier que des dossiers entiers (pas de wildcards)
• Beaucoup plus rapide et performant
• Git optimise en travaillant par « cônes » de répertoires
• C’est le mode recommandé par défaut depuis Git 2.26

Donc le flag –cone permet d’être plus rapide quand vous avez un vraiment gros repository

Récemment, pour un projet open source, j’ai voulu afficher un classement des contributeur en fonction du nombre de commits. J’ai tout de suite eu l’idée de passer par le webservice de Github (alors que je n’en ai jamais entendu parler).

Il est normal que Github ait un webservice, cela permet de faire des nitégration un peut partout (plugin git par exemple).

Comment mener sa réflexion du webservice à l’affichage des badges pour récompenser les contributeurs?

L’idée de base est de proposer un classement des contributeurs en fonction du nombre de pull requests. Pour avoir les pull request, il faut avoir les commits sur la branch principale (dans notre cas develop).

Il a fallut d’abord trouver un moyen via la documentation de lister les commits d’une branche. Deplus j’ai pris le parti d’utiliser un token pour avoir moins de restriction sur les appels.

Exemple d’appel sans avoir besoin de clé:

https://api.github.com/user/repos

Appel avec un clé

Il faut d’abord générer une clé, plus exactement un PAT (personal Access Token). Pour ce faire aller à Settings, puis dans la barre de gauche aller dans Developper…

Générer le PAT, sélectionner les droits de ce PAT, je n’ai besoin qu’en lecture, donc cocher comme dans l’image. Je vous propose dans un premier temps d’expérimenter avec Postman, pour ceux qui ne le connaissent pas encore, Postman permet de faire des requêtes HTTP sans navigateur, pratique pour tester des webservices.

Vous aurez les repository du propriétaqire de votre token. Maintenant listons les commits d’une branches, il a fallu explorer la documentation, ne la baclez pas, la documentation est riche.

// lister les branches
https://api.github.com/repos/refschool/Clone-Weetransfert/branches

// lister les commits de la branche main
https://api.github.com/repos/refschool/Clone-Weetransfert/branches/main

//  lister les commits de la branche par défaut qui est main
https://api.github.com/repos/refschool/Clone-Weetransfert/commits

//  lister les commits de la branche develop avec 100 résultats par page.
https://api.github.com/repos/refschool/Clone-Weetransfert/commits?per_page=100&sha=develop

Il faut essayer de se familiariser avec la pagination le jour où l’on a vraiment beaucoup de commit.

Lien vers la documentation:

https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28

Mais ne peut on pas lister les pull request?

A l’évidence si ! voici la documentation :

https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#list-pull-requests

vous devez être le propriétaire du repo pour avoir les pull requests du projet (normal)

Parfois on peut se tromper dans Git ! Il est donc utile de savoir comment annuler une action (en ligne de commande c’est mieux)

Défaire une modification de fichier non ajouté dans le staging area

git checkout -- nomfichier

Défaire un add

git reset fichier

Défaire un commit

# défaire le dernier commit
git reset --soft HEAD~1
# on revient à l'état où les fichiers sont ajoutés au staging area

$git reser --hard HEAD~1
#on revient à l'état où les fichiers sont non ajoutés au staging area

Défaire un commit qui été poussé

Ne plus trackere un fichier et l’ignorer du versioning

git rm --cached fichier

Vous aimeriez aussi savoir comment pusher sans mot de passe

Je vous présente une commande assez peu utilisée, considérée par certain comme une pas bonne pratique. J’ai u l’utiliser dans une situation bien particulière, en effet j’étais sur develop et j’ai fait une modif dans une autre branche on va dire une feature, que j’aurais dû faire sur develop. Ok on n’est pas sensé bosser sur develop en direct !

Mais c’est un projet où j’étais tout seul, donc je me permettais quelques arrangements.

Branch bleu (develop), branche rouge (feature), je prend le commit ‘taux valeur admin OK’

Je me place dans la branche de destination, develop donc en faisant un git checkout develop

Ensuite je repère le hash du commit de la branche feature, et je fait :

$ git cherry-pick hashDuCommit

Le résultat est le suivant :

On voit que develop a maintenant le commit avec le message ‘taux valeur admin ok’

N’utilisez le cherry-pick qu’avec parcimonie, je pense que si c’est mal fait, vous risquer de mettre votre git dans un sale état.

Vous aimeriez aussi savori comment mettre des commentaires multilignes dans vos commit