Le syst�me de gestion de versions distribu� Git 2.55 est disponible

Jade Emy — Fri, 03 Jul 2026 08:59:12 GMT

Le syst�me de gestion de versions distribu� Git 2.55 est disponible, ajoutant l'�criture MIDX incr�mentielle, la correction de l'historique et la prise en charge de fsmonitor sous Linux

Git 2.55 a �t� publi� avec une mise � jour majeure de la gestion des d�p�ts gr�ce � l��criture incr�mentielle d�index multi-packs. Activ�e avec la commande git repack --write-midx=incremental, cette fonctionnalit� permet � Git d�ajouter de nouvelles couches d�index pour les packs nouvellement cr��s au lieu de r��crire l�int�gralit� du fichier MIDX. La commande exp�rimentale git history b�n�ficie �galement d�une nouvelle sous-commande fixup, permettant aux utilisateurs d�int�grer les modifications mises en attente dans un commit ant�rieur et de r�appliquer les commits ult�rieurs par-dessus. Git 2.55 am�liore �galement le flux de travail et les performances dans plusieurs domaines.

Git est un syst�me logiciel de contr�le de version distribu� capable de g�rer les versions de code source ou de donn�es. Il est souvent utilis� pour contr�ler le code source par des programmeurs qui d�veloppent des logiciels en collaboration. Il a �t� cr�� l�origine par Linus Torvalds pour le contr�le de version dans le cadre du d�veloppement du noyau Linux. Les objectifs de conception de Git incluent la vitesse, l�int�grit� des donn�es et la prise en charge de flux de travail distribu�s et non lin�aires � des milliers de branches parall�les s�ex�cutant sur diff�rents ordinateurs.

Git est le syst�me de contr�le de version le plus couramment utilis� par les d�veloppeurs de logiciels. Il s�agit du syst�me de contr�le de version distribu� le plus populaire, pr�s de 95 % des d�veloppeurs le d�signant 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. Plusieurs plateformes de d�veloppement proposent des services de d�p�ts Git, notamment GitHub, SourceForge, Bitbucket et GitLab.

R�cemment, Git 2.55 a �t� publi� avec une mise � jour majeure de la gestion des d�p�ts gr�ce � l��criture incr�mentielle d�index multi-packs. Activ�e avec la commande git repack --write-midx=incremental, cette fonctionnalit� permet � Git d�ajouter de nouvelles couches d�index pour les packs nouvellement cr��s au lieu de r��crire l�int�gralit� du fichier MIDX. Lorsqu�elle est combin�e au reconditionnement g�om�trique, Git peut utiliser une compaction bas�e uniquement sur les m�tadonn�es pour maintenir l�efficacit� des cha�nes MIDX, en compactant les couches en fonction de repack.midxSplitFactor et en conservant une croissance logarithmique par rapport � la taille du d�p�t.

La commande exp�rimentale git history b�n�ficie �galement d�une nouvelle sous-commande fixup, permettant aux utilisateurs d�int�grer les modifications mises en attente dans un commit ant�rieur et de r�appliquer les commits ult�rieurs par-dessus. Cela facilite la modification d�anciens commits sans avoir � cr�er manuellement des commits de correction ni � ex�cuter un rebase `autosquash`. La commande reste prudente : elle n�cessite un arbre de travail et s�interrompt en cas de conflits.

Git 2.55 am�liore �galement le flux de travail et les performances dans plusieurs domaines. Les hooks bas�s sur la configuration peuvent d�sormais s�ex�cuter en parall�le lorsqu�ils sont activ�s, tandis que les hooks qui d�pendent d�un �tat partag� continuent de s�ex�cuter en s�rie. La g�n�ration du bitmap d�accessibilit� est plus rapide : un benchmark sur un grand d�p�t est pass� d�environ 612 secondes � 294 secondes. De plus, Linux prend d�sormais en charge le moniteur de syst�me de fichiers int�gr� � Git via inotify, ce qui contribue � acc�l�rer des commandes telles que git status lorsque les limites de surveillance du syst�me sont suffisantes.

Voici un extrait de l'annonce de Git 2.55 :

Les points forts de Git 2.55

Le projet open source Git vient de publier la version 2.55 de Git, qui int�gre des fonctionnalit�s et des corrections de bogues apport�es par plus de 100 contributeurs, dont 33 nouveaux. Notre dernier point sur les nouveaut�s de Git remonte � la sortie de la version 2.54.

Pour c�l�brer cette toute derni�re version, voici un tour d�horizon propos� par GitHub des fonctionnalit�s et modifications les plus int�ressantes introduites depuis la derni�re mise � jour.

Recompression avec des index multi-pack incr�mentiels

Les lecteurs fid�les de cette s�rie se souviendront peut-�tre de nos articles consacr�s aux index multi-pack incr�mentiels et aux bitmaps d�accessibilit� multi-pack incr�mentiels. Au cas o� vous auriez besoin d�un petit rappel, en voici un r�sum�.

Git stocke le contenu de votre d�p�t sous forme d�objets individuels : commits, arborescences et blobs. Ces objets se trouvent g�n�ralement dans des fichiers pack, qui sont des collections compress�es d�objets. � chaque fichier pack correspond un index de pack qui permet � Git de localiser rapidement n�importe quel objet � l�int�rieur du pack. Mais les d�p�ts volumineux ne comportent g�n�ralement pas un seul fichier pack : au fil du temps, les op�rations de r�cup�ration, de push, les t�ches de maintenance et les reconditionnements peuvent laisser derri�re eux de nombreux packs.

Un index multi-pack (ou MIDX) fournit � Git un index unique couvrant plusieurs packs. Au lieu d�ouvrir et de rechercher l�index individuel de chaque pack, Git peut interroger le MIDX pour savoir quel pack contient un objet donn� et � quel offset. Cela s�av�re particuli�rement utile pour les d�p�ts volumineux, et c�est l�un des piliers de la strat�gie de maintenance des d�p�ts de GitHub.

Comme nous l�avons vu lors de l�introduction du format MIDX incr�mental dans Git 2.47, un d�p�t peut stocker son MIDX sous la forme d�une cha�ne de couches plut�t que sous la forme d�un MIDX unique couvrant tous les packs. Un MIDX � fichier unique est simple et efficace � lire, mais il pr�sente un co�t de maintenance important ; comme ce fichier inclut tous les packs qu�il couvre, m�me une petite mise � jour peut n�cessiter une �criture volumineuse dans un d�p�t d�j� volumineux.

Les MIDX incr�mentiels r�solvent ce probl�me en stockant une cha�ne de couches MIDX. Chaque couche couvre un ensemble de packs, et le fichier de la cha�ne enregistre l�ordre de ces couches. L�ajout d�une nouvelle couche � l�extr�mit� de la cha�ne n�invalide pas les couches plus anciennes ; Git peut ainsi indexer les packs nouvellement cr��s sans r��crire un fichier MIDX unique couvrant l�int�gralit� du d�p�t.

Git 2.55 apprend � la commande git repack � �crire directement ces cha�nes MIDX incr�mentielles :

Code:

$ git repack --write-midx=incremental

Sans aucune autre option, ce mode est en �criture seule : Git �crit une nouvelle couche pour les paquets cr��s par le repack et laisse les couches existantes telles quelles. Cela s�av�re d�j� utile lorsque vous souhaitez minimiser la quantit� de m�tadonn�es r��crites lors d�une op�ration de maintenance.

Mais une cha�ne en ajout seul ne peut pas s�allonger ind�finiment. Si chaque op�ration de maintenance ajoute une nouvelle couche, la cha�ne elle-m�me finit par devenir ce que vous devez maintenir. Git 2.55 prend �galement en charge la combinaison de l�option --write-midx=incremental avec le reconditionnement g�om�trique :

Code:

$ git repack --write-midx=incremental --geometric=2 -d

Lorsque ces modes sont utilis�s conjointement, chaque repack cr�e une nouvelle couche d�extr�mit�, puis d�termine si les couches adjacentes doivent �tre compact�es ensemble. La r�gle par d�faut est contr�l�e par repack.midxSplitFactor : si le nombre cumul� d�objets dans les couches les plus r�centes devient suffisamment important par rapport � la couche imm�diatement ant�rieure, Git fusionne ces couches en une seule couche de remplacement. Sinon, les couches plus anciennes restent inchang�es.

� un niveau g�n�ral, l�algorithme fonctionne comme suit. Ci-dessous, N d�signe la valeur de repack.midxNewLayerThreshold, et f d�signe la valeur de repack.midxSplitFactor :

1. S�lectionnez les paquets non MIDX comme candidats au reconditionnement g�om�trique. Si la couche MIDX de pointe comporte au moins N paquets, incluez-les �galement parmi les candidats.

2. Appliquez la r�gle habituelle de regroupement g�om�trique � cet ensemble de candidats, puis �crivez une nouvelle couche MIDX de pointe couvrant les paquets obtenus.

3. Compactez les couches MIDX adjacentes lorsque le nombre cumul� d�objets de la ou des couches les plus r�centes d�passe 1/f du nombre d�objets de la couche imm�diatement plus profonde.

Pour comprendre comment les �l�ments s�articulent, prenons l�exemple d�un r�f�rentiel disposant d�j� d�une cha�ne MIDX incr�mentielle. Les couches les plus anciennes se trouvent � gauche, et la couche d�extr�mit� � droite. Parall�lement, l�activit� normale du r�f�rentiel continue de produire de nouveaux paquets. Ces paquets ne sont encore couverts par aucune couche MIDX, ce qui signifie que la prochaine op�ration de maintenance comporte deux t�ches : d�terminer ce qu�il faut r�organiser, et d�cider quelle partie de la cha�ne MIDX doit �tre r��crite.

En r�gle g�n�rale, ces packs non couverts par MIDX sont les seuls candidats au reconditionnement g�om�trique : Git peut �crire un nouveau pack et une nouvelle couche MIDX d�extr�mit� sans perturber aucune couche existante. La figure ci-dessous illustre le cas le plus int�ressant, o� la couche d�extr�mit� actuelle a accumul� suffisamment de packs pour atteindre le seuil configur� repack.midxNewLayerThreshold. Une fois ce seuil atteint, les packs de la couche d�extr�mit� peuvent rejoindre les packs nouvellement �crits en tant que candidats au reconditionnement g�om�trique.

Le � repacking g�om�trique � pose alors une question locale concernant les nouveaux paquets candidats. Le � repacking g�om�trique � pose alors une question locale concernant les nouveaux paquets candidats : le paquet situ� imm�diatement � gauche d�un suffixe de paquets (P) est-il suffisamment grand pour pr�server la progression g�om�trique si Git regroupe 𝒫 ? Dans la premi�re tentative ci-dessous, 𝒫 contient le plus petit pack de la couche de pointe actuelle ainsi que les nouveaux packs non trait�s par MIDX. Mais le pack situ� � gauche de la scission ne contient que 30 000 objets, ce qui est inf�rieur au double de la taille de
𝒫 ; cette scission est donc trop d�cal�e vers la droite.

Git d�place donc la division d�un pack en amont et repose la m�me question. D�sormais, 𝒫 inclut un pack suppl�mentaire provenant de la couche de pointe. Le pack situ� imm�diatement � gauche contient 100 000 objets, soit au moins deux fois la taille du suffixe s�lectionn�. C�est � ce moment-l� que l�invariant g�om�trique s�applique, ce qui permet � Git de regrouper pr�cis�ment ces packs dans un nouveau pack.

Apr�s avoir �crit ce nouveau pack, Git �crit une nouvelle couche MIDX de pointe par-dessus le pack survivant de la couche de pointe pr�c�dente et le pack regroup� nouvellement �crit. � ce stade, les fichiers de pack sont en bon �tat, mais la cha�ne MIDX peut encore avoir accumul� trop de petites couches adjacentes. Git applique le m�me principe � le plus r�cent par rapport � l�ancien � aux couches MIDX elles-m�mes : si la couche la plus r�cente est suffisamment grande par rapport � sa voisine, il compacte leurs m�tadonn�es en une couche de remplacement.

Cette �tape de compactage concerne d�lib�r�ment uniquement les m�tadonn�es. Git ne reconditionne pas les objets de ces couches ; il �crit une nouvelle couche MIDX qui couvre les m�mes fichiers pack. Il examine ensuite la couche imm�diatement ant�rieure. Ici, la couche compact�e est encore plus petite que la moiti� de la couche plus profonde, donc Git s�arr�te. La couche plus ancienne reste intacte, ce qui est la propri�t� cl� qui permet � cette maintenance de rester incr�mentielle.

Le r�sultat est un compromis entre deux extr�mes. Un fichier MIDX unique minimise la complexit� des recherches, mais peut n�cessiter d�importantes r��critures lors de la maintenance. Un MIDX incr�mental purement � en ajout seul � minimise chaque �criture mais permet � la cha�ne de s�allonger sans limite. Le reconditionnement incr�mental g�om�trique maintient le nombre de couches � un niveau logarithmique par rapport au nombre total d�objets, tout en garantissant que les couches les plus r�centes et les plus petites soient r��crites plus souvent que les plus anciennes et les plus volumineuses.

Ce m�canisme s�int�gre �galement au syst�me de reconditionnement existant de Git. Les paquets nouvellement �crits qui ne sont pas encore couverts par la cha�ne MIDX sont toujours candidats au reconditionnement g�om�trique ; les paquets situ�s dans les couches MIDX plus profondes ne sont pas modifi�s. Les paquets de la couche MIDX de pointe ne rejoignent l�ensemble des candidats qu�une fois que cette couche contient au moins repack.midxNewLayerThreshold paquets. Si la couche de pointe est encore inf�rieure � ce seuil, Git �vite compl�tement de la modifier et se contente d�ajouter une nouvelle couche pour les paquets nouvellement �crits.

Pour les d�p�ts qui re�oivent un flux constant de nouveaux objets, cela signifie que la maintenance de routine peut mettre � jour les m�tadonn�es des paquets du d�p�t de mani�re incr�mentielle, sans obliger chaque op�ration de maintenance � r��crire un seul MIDX couvrant l�ensemble du magasin d�objets.

Corriger des commits ant�rieurs avec git history:

Quiconque a d�j� peaufin� une s�rie de commits avant de la soumettre � r�vision a probablement d�j� v�cu cette situation : vous remarquez qu�une modification dans votre arborescence de travail appartient en r�alit� � un commit ant�rieur, et non � l�extr�mit� de la branche.

Aujourd�hui, une m�thode courante pour g�rer cela consiste � cr�er un commit de correction (fixup), puis � l�autosquasher :

Code:

1
2
$ git commit --fixup= 
$ git rebase --autosquash ^

Cela fonctionne, mais cela vous oblige � d�tailler le m�canisme plut�t que l�intention. Git 2.55 s�appuie sur la commande exp�rimentale git history, introduite dans Git 2.54, en ajoutant une nouvelle sous-commande fixup. Elle applique les modifications actuellement mises en attente dans l�index � un commit ant�rieur :

Code:

$ git history fixup

Voici un petit exemple. Le premier commit a introduit une recette de cr�pes, suivie de quelques autres commits par-dessus. Plus tard, on se rend compte qu�il manquait du sirop d��rable dans la recette. Apr�s avoir mis en attente cette modification d�une ligne, la commande git history fixup l�int�gre au commit de la recette d�origine et r�applique les commits descendants par-dessus. Ici, la modification mise en attente fait partie int�grante du commit cible lui-m�me. Par d�faut, le commit cible conserve son message et son auteur, sauf si vous passez l�option --reedit-message, et Git r��crit les commits suivants afin que la branche aboutisse � un historique �quivalent avec la correction � la bonne place.

Comme le reste de git history, cette commande est encore exp�rimentale. Elle est �galement volontairement prudente. Comme fixup lit � partir de l�index, elle n�cessite un arbre de travail et ne peut pas fonctionner dans un d�p�t nu ; si l�application de la modification mise en attente devait produire un conflit, la commande s�interrompt plut�t que de vous laisser au milieu d�une r��criture avec �tat.

Source : Annonce de Git 2.55

Et vous ?

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

Voir aussi :

:fleche: 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

:fleche: 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

:fleche: Linus Torvalds c�l�bre le 20e anniversaire de Git. Est-il plus c�l�bre que Linux ?

Images attach�es

Les messages d'erreur de Git

Toulousaing — Wed, 10 Jun 2026 05:18:59 GMT

Yo,
Je suis en train de bosser sur un syst�me expert (pas une appli boost�e � l'IA) et je voudrais savoir o� je peux trouver les messages d'erreur de Git ? Dans les sources, d'accord, mais plus simplement ? J'ai lu ProGIt, ils n'y sont pas.
Merci les Copains.

Git sur ancien Synology

JNZero — Sat, 25 Apr 2026 07:09:48 GMT

Bonjour

J'ai un souci de connexion client-serveur.

J'ai un d�p�t Git sur un Synology DS110J (~2010) pour les sauvegardes de mes petits d�veloppements.
Je l'utilisais depuis un Raspberry PI2 sous Raspbian (Buster il me semble) et �a fonctionnait.
J'ai chang� le Raspberry par un Pi3 avec le dernier OS, et �a ne fonctionne plus.
Le SSH fonctionne.

Je peux cloner (j'ai pu r�cuperer le d�pot sur le nouveau RPI3)
Je peux faire "git commit" mais lorsque je fait "git push" l'erreur suivante apparait :

"kex_exchange_identification: read: Connection reset by peer
Connection reset by 192.168.1.88 port 22
fatal : Impossible de lire le d�p�t distant. Veuillez v�rifier que vous avez les droits d'acc�s et que le d�p�t existe."

Apr�s recherche, il semble que les "nouveaux" git ouvrent plusieurs flux, alors que les anciens n'en ouvraient qu'un.
Si quelqu'un a une solution, je suis preneur.

merci

Droit git ww-data

Reggio — Tue, 24 Feb 2026 18:59:26 GMT

Bonjour,

J'ai un site prestashop h�berg� sur un VPS Debian (avec Docker).
J'ai un environnement de d�veloppement Docker, et je modifie des fichiers en local (theme, modules...) et push sur github.
Quand je pull depuis mon VPS, les fichiers ont comme propri�taire graphandco (mon user git), et prestashop ne peut pas �crire dessus car il est en www-data, et bim erreur 500.

Je cherche la bonne mani�re de proc�der. J'ai lu des solutions en utilisant ACL ou des scripts post-merge. Mais dans les 2 cas, je dois pr�ciser des dossiers.
Actuellement je ne travaille que sur le th�me, mais si je cr�� un nouveau module par exemple, ou que je modifie des fichiers dans le dossier mails ou autre, si je n'ai pas anticip� et que je push/pull, je peux me retrouver avec une erreur 500 en prod.

Quelle est la bonne mani�re de faire pour �viter �a, en restant bien �videmment en totale s�curit� sur les droits ?

Merci d'avance

Utiliser GIT uniquement en local pour du dev php sous linux

foxbille — Mon, 08 Sep 2025 12:44:36 GMT

Bonjour,
Est-ce qu'il est possible d'utiliser GIT uniquement en local.
Le d�pot serait par exemple sur /home/$USER/git/projet1
Travaillant dans /var/www/public/projet1, le clone marche
par contre la commande git add . suivie de git commit -m "bla bla bla" n'op�re que sur ce qui est dans /var/ et rien n'est remont� dans le "d�pot".
Est-ce qu'il y a moyen de faire �a ?
cordialement,
Eric

Forum du club des d�veloppeurs et IT Pro - GIT

Le syst�me de gestion de versions distribu� Git 2.55 est disponible

Les messages d'erreur de Git

Git sur ancien Synology

Droit git ww-data

Utiliser GIT uniquement en local pour du dev php sous linux