{"id":141016,"date":"2025-08-19T11:11:54","date_gmt":"2025-08-19T09:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51"},"modified":"2025-08-19T11:11:54","modified_gmt":"2025-08-19T09:11:54","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","title":{"rendered":"Rilascio del sistema di controllo delle versioni Git 2.51","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo due mesi di sviluppo, \u00e8 stata rilasciata la versione 2.51 del sistema di gestione distribuita del codice sorgente Git. Git si distingue per le sue alte prestazioni e offre strumenti per uno sviluppo non lineare, basati su ramificazioni e conflitti. Per garantire l'integrit\u00e0 della cronologia e la resistenza alle modifiche retroattive si utilizzano l'hashing implicito di tutta la cronologia precedente in ogni commit, nonch\u00e9 la verifica tramite firme digitali degli sviluppatori per singoli tag e commit. Il codice di Git \u00e8 distribuito sotto la licenza GPLv2+. <\/p>\n
Rispetto alla versione precedente, nella nuova release sono stati accolti 506 cambiamenti, realizzati con la partecipazione di 91 sviluppatori (21 dei quali hanno partecipato allo sviluppo di Git per la prima volta). Le principali novit\u00e0 (1, 2, 3): <\/p>\n
\n
Le prestazioni dei comandi «git push» e «git fetch» sono state migliorate nei repository con un numero elevato di riferimenti. L'accelerazione \u00e8 stata possibile grazie all'aggiornamento dei riferimenti in modalit\u00e0 batch, in cui pi\u00f9 riferimenti vengono elaborati in un'unica transazione, invece di creare una transazione separata per aggiornare ogni singolo riferimento. L'ottimizzazione ha aumentato significativamente la velocit\u00e0 del backend «reftable», che ora supera in prestazioni il backend «files». Ad esempio, in un repository di prova con 10.000 riferimenti, le prestazioni di «git fetch» utilizzando il backend «reftable» sono aumentate di 22 volte, mentre con il backend «files» sono aumentate di 1,25 volte. Per «git push», l'incremento \u00e8 stato rispettivamente di 18 e 1,21 volte.\n
\u00c8 stato proposto un nuovo metodo di imballaggio in pacchetti di parti del repository non collegate a oggetti inaccessibili, per cui non ci sono riferimenti nel repository (ad esempio, rami o tag non facenti riferimento). Le informazioni sugli oggetti inaccessibili vengono memorizzate in pacchetti separati (\"cruft packs\"), il che ha comportato la necessit\u00e0 della loro inclusione negli indici multi-pack MIDX (multi-pack index) per coprire gli oggetti che inizialmente erano inaccessibili e archiviati solo nel pacchetto cruft, ma successivamente sono diventati accessibili dopo un commit che vi fa riferimento.\n
Nella nuova versione, durante la ripacchettizzazione dei file pack, \u00e8 stato garantito il salvataggio di copie aggiuntive degli oggetti raggiungibili, conservati solo nei file cruft. Questa modifica assicura che nel set di file pack utilizzato per memorizzare gli oggetti raggiungibili non ci siano oggetti che fanno riferimento ad altri oggetti memorizzati al di fuori di questo set. Per escludere contenuti non raggiungibili dai multiplexed index (MIDX) dei file cruft, \u00e8 stata proposta l'impostazione «repack.MIDXMustContainCruft», che consente di ridurre notevolmente le dimensioni di tali indici. Abilitare questa impostazione nel repository GitHub ha permesso di ridurre le dimensioni degli indici MIDX del 38%, di accelerare la scrittura negli indici MIDX del 35% e di migliorare le prestazioni di lettura del 5%. <\/p>\n
Nel comando «git pack-objects» \u00e8 stata aggiunta l'opzione «—path-walk», che introduce un nuovo metodo per raccogliere informazioni sugli oggetti durante la riunione dei file pack. Invece di esaminare gli oggetti in base alle revisioni, utilizzando la modalit\u00e0 «—path-walk», gli oggetti vengono esaminati attraverso i percorsi dei file, consentendo di imballare tutti gli oggetti con lo stesso percorso di file in un'unica operazione. Questo approccio permette di eliminare l'euristica che utilizza l'hashing per determinare la relazione dell'oggetto con il suo percorso di file, cos\u00ec come di evitare la necessit\u00e0 di ordinare gli oggetti prima dell'imballaggio. Utilizzando la modalit\u00e0 «—path-walk», la dimensione dei file pack generati \u00e8 significativamente inferiore rispetto a quella ottenuta raggruppando gli oggetti tramite hash.\n
\u00c8 stato definito un formato per lo scambio degli stati salvati dell'albero di lavoro e degli indici nel repository, creati con il comando «git stash». Il nuovo formato consente di codificare le modifiche salvate (stash) come una sequenza di commit. Per l'importazione e l'esportazione sono state introdotte le sottocomandi «git stash import» e «git stash export», che possono essere utilizzate per trasferire stati salvati da un sistema a un altro ed eseguire operazioni di push o pull su questi stati come su normali rami o tag. git stash export —to-ref refs\/stashes\/my-stash git push origin refs\/stashes\/my-stash … git fetch origin ‘+refs\/stashes\/*:refs\/stashes\/*’ git stash import refs\/stashes\/my-stash\n
Nel comando «git cat-file», che visualizza il contenuto degli oggetti specificati, \u00e8 stata implementata la possibilit\u00e0 di mostrare informazioni sugli oggetti mancanti (ad esempio, a causa di un danneggiamento del repository) e sui sottomoduli, utilizzando le opzioni «—batch» e «—batch-check». In precedenza, specificando il percorso a un sottmodulo, il comando «git cat-file —batch-check» riportava «missing», mentre ora mostrer\u00e0 l'identificatore dell'oggetto.\n
Nel comando «git log» sono state implementate ottimizzazioni basate su filtri di Bloom per velocizzare la ricerca nella cronologia delle modifiche quando si specificano filtri con pi\u00f9 percorsi di file, ad esempio «git log — path\/to\/a path\/to\/b».\n
I comandi «git switch» e «git restore» sono stati stabilizzati e dal 2019 sono considerati sperimentali. Questi comandi vengono presentati come equivalenti moderni di «git checkout», separando funzionalit\u00e0 poco correlate come la gestione dei rami (commutazione e creazione) e il ripristino dei file nella directory di lavoro.\n
Il comando «git whatchanged», equivalente a «git log —raw», \u00e8 stato dichiarato obsoleto e programmato per la rimozione nella versione Git 3.0.\n
Nel comando «git for-each-ref» \u00e8 stata aggiunta l'opzione «—start-after», che pu\u00f2 essere utilizzata insieme all'opzione «—count» per organizzare l'output pagina per pagina.\n
Nei comandi «git merge» e «git pull» \u00e8 stata aggiunta l'opzione «—compact-summary» per utilizzare un formato compatto di riepilogo delle modifiche invece del formato diffstat.\n
Nella base di codice Git \u00e8 consentito l'uso della parola chiave \u00abbool\u00bb, introdotta nello standard C99. Sono documentate anche alcune funzionalit\u00e0 di C99, utilizzate sperimentalmente in Git (ad esempio, si prevede di consentire l'uso delle costruzioni \u00ab(struct foo){ .member = value };\u00bb a met\u00e0 del 2026). Un compilatore con supporto per C99 \u00e8 obbligatorio per Git dal 2021, ma le funzionalit\u00e0 della specifica C99 vengono introdotte con molta cautela per garantire la compatibilit\u00e0 con i compilatori che supportano solo parzialmente questo standard.\n
Sono state apportate modifiche alle regole di accettazione dei patch che consentono l'invio di patch con uno pseudonimo, e non solo con il nome reale dello sviluppatore. La modifica \u00e8 conforme alle regole di accettazione dei patch nel kernel Linux.\n
\u00c8 stata aggiornata la lista delle modifiche che compromettono la compatibilit\u00e0, che verranno applicate nella branca Git 3.0. Tra le modifiche significative nel prossimo rilascio di Git 3.0, si segnala il passaggio predefinito agli identificatori degli oggetti basati sull'algoritmo di hashing SHA-256 durante l'inizializzazione di nuovi repository, e l'adozione del formato \u00abreftable\u00bb per memorizzare nel repository i riferimenti a rami e tag (\u00e8 stato implementato uno storage a blocchi dal progetto JGit, ottimizzato per conservare un numero molto elevato di riferimenti). <\/ul>\n