Discussion :

[Jade Emy]

Le système de gestion de versions distribué Git 2.54 est disponible et introduit la commande « git history » et des hooks améliorés pour une meilleure gestion des dépôts

Le projet open source Git vient de publier la version 2.54 de Git, qui intègre des fonctionnalités et des corrections de bogues provenant de plus de 137 contributeurs, dont 66 nouveaux. Voici un aperçu par GitHub de certaines des fonctionnalités et modifications les plus intéressantes introduites depuis la dernière version : Réécrire l'historique avec l'historique Git, Hooks basés sur la configuration et recompression géométrique par défaut lors de la maintenance.

Git est un système de gestion de versions distribué capable de gérer les versions de code source ou de données. Il est souvent utilisé pour gérer le code source par les programmeurs qui développent des logiciels en collaboration. Les objectifs de conception de Git incluent la vitesse, l'intégrité des données et la prise en charge de workflows distribués et non linéaires — des milliers de branches parallèles s'exécutant sur différents ordinateurs.

Comme la plupart des autres systèmes de contrôle de version distribués, et contrairement à la plupart des systèmes client-serveur, Git conserve une copie locale de l'intégralité du dépôt, également appelé « repo », avec des capacités d'historique et de suivi des versions, indépendamment de l'accès au réseau ou d'un serveur central. Un dépôt est stocké sur chaque ordinateur dans un répertoire standard contenant des fichiers supplémentaires cachés afin de fournir des capacités de contrôle de version.

Aujourd'hui, Git est le système de contrôle de version le plus couramment utilisé par les développeurs de logiciels. C'est le système de contrôle de version distribué le plus populaire, près de 95 % des développeurs le citant comme leur principal système de contrôle de version en 2022. C'est l'outil de gestion de code source le plus largement utilisé parmi les développeurs professionnels. Il existe plusieurs services de dépôt Git, notamment GitHub, SourceForge, Bitbucket et GitLab.

Récemment, le projet open source Git vient de publier la version 2.54 de Git, qui intègre des fonctionnalités et des corrections de bogues provenant de plus de 137 contributeurs, dont 66 nouveaux. Voici un aperçu par GitHub de certaines des fonctionnalités et modifications les plus intéressantes introduites depuis la dernière version : Réécrire l'historique avec l'historique Git, Hooks basés sur la configuration et recompression géométrique par défaut lors de la maintenance.

Réécrire l'historique avec git history.

Le projet Git propose depuis longtemps des outils permettant de réécrire l’historique de votre dépôt. git rebase –i est le plus connu, et il est remarquablement flexible : vous pouvez réorganiser, fusionner, modifier et supprimer des commits. Mais cette flexibilité s’accompagne d’une certaine complexité : un rebase interactif opère sur une série de commits, met à jour votre arborescence de travail et votre index au fur et à mesure, et peut vous laisser dans un état de conflit que vous devez résoudre avant de continuer.

Pour les cas plus simples, tout ce mécanisme peut sembler excessif. Si vous souhaitez simplement corriger une faute de frappe dans le message d'un commit datant de trois commits, ou diviser un commit en deux, un rebase interactif fonctionne, mais vous oblige à établir une liste de tâches, à marquer le bon commit pour modification, puis à mener le rebase à son terme.

Git 2.54 introduit une nouvelle commande expérimentale conçue précisément pour ces cas plus simples : git history. La commande history prend actuellement en charge deux opérations : reword et split.

git history reword <commit> ouvre votre éditeur avec le message du commit spécifié et le réécrit sur place, en mettant à jour toutes les branches issues de ce commit. Contrairement à git rebase, elle ne touche pas à votre arborescence de travail ni à votre index, et peut même fonctionner dans un dépôt nu.

git history split <commit> vous permet de diviser de manière interactive un commit en deux en sélectionnant les segments à extraire pour former un nouveau commit parent. L'interface vous semblera familière si vous avez déjà utilisé add en mode interactif via git add –p :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
$ git history split HEAD
diff --git a/bar b/bar
new file mode 100644
index 0000000..50810a5
--- /dev/null
+++ b/bar
@@ -0,0 +1 @@
+bar
(1/1) Stage addition [y,n,q,a,d,p,?]? y

Après avoir sélectionné les segments, Git crée un nouveau commit avec ces modifications en tant que parent du commit d’origine (qui conserve les segments que vous n’avez pas sélectionnés) et réécrit toutes les branches descendantes pour qu’elles pointent vers l’historique mis à jour.

Il existe quelques limitations intentionnelles qui méritent d'être notées. La commande history ne prend pas en charge les historiques contenant des commits de fusion, et elle refusera d'effectuer toute opération qui entraînerait un conflit de fusion. De par sa conception, git history est destiné à des réécritures ciblées et non interactives, et non au type de réécriture d'historique ouverte généralement reléguée à git rebase –i.

La commande history s’appuie sur le mécanisme central de git replay, qui a lui-même été extrait dans une bibliothèque dans le cadre de ce travail. Grâce à cette base, git history bénéficie de la capacité de replay à fonctionner sans toucher à l’arborescence de travail, ce qui en fait un outil naturellement adapté aux scripts et à l’automatisation, en plus d’une utilisation interactive.

Cette commande est encore considérée comme expérimentale, son interface est donc susceptible d’évoluer. Essayez-la avec git history reword et git history split, disponibles dans Git 2.54.

Hooks basés sur la configuration

Si vous avez déjà souhaité partager un hook Git entre plusieurs dépôts, vous avez probablement dû recourir à un gestionnaire de hooks tiers, ou créer manuellement des liens symboliques vers les scripts dans le répertoire $GIT_DIR/hooks de chaque dépôt. En effet, historiquement, les hooks Git ne pouvaient être définis que comme des scripts exécutables résidant à un seul endroit : le sous-répertoire hooks de votre répertoire .git (ou tout autre emplacement indiqué par core.hooksPath).

Cela signifiait que si vous souhaitiez exécuter un linter avant chaque commit sur l’ensemble de vos dépôts, vous deviez copier le script dans chaque dépôt, ce qui peut s’avérer fastidieux et source d’erreurs. Vous pouviez également configurer core.hooksPath pour qu’il pointe vers un répertoire partagé, mais cela obligeait tous vos dépôts à partager exactement le même ensemble de hooks, sans possibilité de les combiner à votre guise.

Git 2.54 introduit une nouvelle façon de définir les hooks : dans vos fichiers de configuration. Au lieu de placer un script dans .git/hooks/pre-commit, vous pouvez désormais écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
[hook "linter"]
   event = pre-commit
   command = ~/bin/linter --cpp20

La clé hook.<name>.command spécifie la commande à exécuter, tandis que hook.<name>.event indique quel événement de hook doit la déclencher. Comme il s'agit simplement d'une configuration, elle peut être placée dans votre fichier ~/.gitconfig personnel, dans le fichier système /etc/gitconfig ou dans la configuration locale d'un dépôt. Cela permet de définir facilement un ensemble de hooks de manière centralisée et de les appliquer partout.

Mieux encore, vous pouvez désormais exécuter plusieurs hooks pour un même événement. Si vous souhaitez qu’un linter et un scanner de secrets s’exécutent avant chaque commit, vous pouvez les configurer indépendamment :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
[hook "linter"]
   event = pre-commit
   command = ~/bin/linter --cpp20

[hook "no-leaks"]
   event = pre-commit
   command = ~/bin/leak-detector

Git les exécutera dans l'ordre où il rencontre leur configuration. Le script de hook traditionnel dans $GIT_DIR/hooks fonctionne toujours et s'exécute en dernier, de sorte que les hooks existants ne sont pas affectés. Vous pouvez voir quels hooks sont configurés (et d'où ils proviennent) avec git hook list :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ git hook list pre-commit
global    linter  ~/bin/linter --cpp20
local    no-leaks    ~/bin/leak-detector

Les hooks individuels peuvent être désactivés sans supprimer leur configuration en définissant hook.<name>.enabled = false, ce qui est particulièrement pratique lorsqu'un hook est défini dans une configuration au niveau du système mais que vous devez exclure un dépôt spécifique.

Parallèlement, la gestion interne des hooks par Git a été modernisée. De nombreux hooks intégrés qui étaient auparavant invoqués via des chemins de code ad hoc (comme pre-push, post-rewrite et les divers hooks receive-pack) ont été migrés vers la nouvelle API de hooks, ce qui signifie qu’ils bénéficient tous du nouveau mécanisme de hooks basé sur la configuration.

Recompression géométrique par défaut lors de la maintenance

Les lecteurs assidus de cette série se souviendront peut-être de notre article sur la nouvelle stratégie géométrique dans git maintenance, introduite dans Git 2.52. Cette stratégie consiste à inspecter le contenu de votre dépôt pour déterminer si un certain nombre de fichiers de paquets peuvent être combinés pour former une progression géométrique en fonction du nombre d’objets. Si c’est le cas, Git effectue une recompression géométrique, condensant le contenu de votre dépôt sans avoir besoin d’effectuer un nettoyage complet.

Dans la version 2.52, la stratégie géométrique était disponible en option via la configuration maintenance.strategy. Dans la version 2.54, elle devient la stratégie par défaut pour la maintenance manuelle. Cela signifie que lorsque vous exécutez git maintenance run sans spécifier de stratégie, Git utilisera désormais l'approche géométrique au lieu de la tâche gc traditionnelle.

Concrètement, cela signifie que vos dépôts seront gérés plus efficacement dès l'installation. La stratégie géométrique évite les recompressions « tout-en-un » coûteuses effectuées par gc, en combinant plutôt les paquets de manière incrémentielle lorsque cela est possible et en ne recourant à un gc complet que lorsque cela permettrait de consolider l'ensemble du dépôt en un seul paquet. Ce faisant, elle maintient à jour votre graphe de commits, vos reflogs et d'autres structures de données auxiliaires.

Si vous utilisiez déjà maintenance.strategy = geometric dans votre configuration, rien ne change. Si vous n’aviez pas défini de stratégie (ou si vous vous appuyiez sur l’ancienne valeur par défaut gc), vous commencerez à constater automatiquement les avantages du reconditionnement géométrique. La stratégie gc est toujours disponible si vous la préférez et peut être sélectionnée avec maintenance.strategy = gc.

Source : Annonce de Git 2.54

Et vous ?

Pensez-vous que cette annonce est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Git va changer le nom par défaut de sa branche « master » en « main » dans la version 3.0, prévue pour fin 2026, afin de promouvoir un langage inclusif dans le contexte des changements sociaux de 2020

La version 1.26 du logiciel de gestion de projets Git Gitea est disponible et ajoute le téléchargement d'archives par sous-chemin, le rendu OpenAPI, la prise en charge de Vite et des correctifs de sécurité

GitButler lève 17 millions de dollars pour réinventer le contrôle de versions : le cofondateur de GitHub veut construire l'infrastructure de l'ère des agents IA. La communauté open source répond par la méfiance

[Daïmanu]

git rebase est vraiment puissant mais aussi potentiellement dangereux, j'ai déjà détruit des repository locaux (réparé avec git pull heureusement), je suis pas serein quand je l'utilise. Les deux nouvelles commandes répondent à un vrai besoin, j'ai hâte de les tester.