Checkouts rapides avec tout l’historique

Par défaut, actions/checkout récupère un seul commit (fetch-depth: 1). C’est le checkout le plus rapide, et celui qui convient à la plupart des jobs.

Certains jobs ont besoin de l’historique : comparer une pull request à sa branche de base, trouver le dernier tag de version ou générer un changelog. Ils définissent fetch-depth: 0, qui télécharge chaque version de chaque fichier que le dépôt a jamais contenu. La plupart de ces jobs ne lisent pourtant que les commits et les noms de fichiers, jamais l’ancien contenu des fichiers.

Ajoutez une ligne

- uses: actions/checkout@v4
  with:
    fetch-depth: 0
    filter: blob:none

filter: blob:none produit un clone partiel : tous les commits et toutes les arborescences de répertoires, mais le contenu des fichiers uniquement pour le commit que vous extrayez. Si une étape ultérieure lit une version plus ancienne d’un fichier, git la télécharge à ce moment-là.

Ce que l’on gagne

Mesuré sur un dépôt d’environ 5 000 fichiers et 4 600 commits, sur les runners hébergés, en octobre 2026 :

Le gain augmente avec la taille de l’historique du dépôt. Un dépôt récent, avec peu de commits, y gagne peu.

Quand l’utiliser

Utilisez-le quand les commandes git du job lisent des commits, des branches, des tags ou les noms des fichiers modifiés, par exemple :

• git diff --name-only origin/main...HEAD
• git log --oneline, git describe --tags
• git merge-base

Ne l’activez pas quand le job lit l’ancien contenu des fichiers sur de nombreux commits, par exemple git log -p sur une longue plage, git blame sur de nombreux fichiers, ou un outil qui parcourt chaque version historique. Chaque fichier manquant est alors téléchargé à la demande, ce qui peut être plus lent que le clone complet.

Un git diff qui affiche le contenu (et pas seulement les noms) entre deux commits ne télécharge que les fichiers modifiés, en un seul lot. C’est généralement encore plus rapide qu’un clone complet.

Pourquoi ce n’est pas le comportement par défaut

fremforge ne l’active pas pour tous les jobs, pour deux raisons :

• Cela ralentit le checkout par défaut. Avec fetch-depth: 1, un clone partiel nécessite un second aller-retour pour les fichiers : il est donc plus lent, pas plus rapide.
• Le dépôt a besoin de ses propres réglages pour que cela fonctionne. Le paramètre filter inscrit les réglages du clone partiel dans le dépôt extrait, pour que toute étape ultérieure puisse récupérer ce dont elle a besoin. Un réglage appliqué au runner dans son ensemble ne suivrait pas le dépôt, et une étape exécutée avec un autre répertoire personnel, par exemple dans un conteneur de job, échouerait au premier fichier manquant.

Le choix vous revient donc, workflow par workflow.