{"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\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","title":{"rendered":"Versione del sistema di controllo del codice sorgente Git 2.51","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo due mesi di sviluppo, \u00e8 stato rilasciato Git 2.51, un sistema di gestione distribuita dei codici sorgente. Git si distingue per le elevate prestazioni e offre strumenti per lo sviluppo non lineare, basati su ramificazioni e fusioni di rami. Per garantire l'integrit\u00e0 della cronologia e la resistenza ai cambiamenti retroattivi, viene utilizzato un hashing implicito dell'intera cronologia precedente in ogni commit, oltre a certificare i tag e i commit degli sviluppatori tramite firme digitali. Il codice di Git \u00e8 distribuito con licenza GPLv2+. <\/p>\n
Rispetto alla versione precedente, nella nuova versione sono stati apportati 506 cambiamenti, frutto del lavoro di 91 sviluppatori (21 dei quali hanno partecipato per la prima volta allo sviluppo di Git). Le principali novit\u00e0 (1, 2, 3): <\/p>\n
\n
Migliorate le prestazioni dei comandi 'git push' e 'git fetch' in repository con un gran numero di riferimenti. L'accelerazione \u00e8 stata resa possibile grazie all'aggiornamento dei riferimenti in modalit\u00e0 batch, elaborando pi\u00f9 riferimenti in un'unica transazione, anzich\u00e9 creare una transazione separata per aggiornare ogni riferimento. Questa ottimizzazione ha aumentato significativamente la velocit\u00e0 del backend 'reftable', il quale ora supera in prestazioni il backend 'files'. Ad esempio, in un repository di test con 10.000 riferimenti, le prestazioni di 'git fetch' utilizzando il backend 'reftable' sono aumentate di 22 volte, mentre con il backend 'files' solo di 1,25 volte. Per 'git push', l'incremento \u00e8 stato di 18 e 1,21 volte, rispettivamente.\n
\u00c8 stato proposto un nuovo metodo di impacchettamento nei file pack delle parti del repository, non collegate al tracciamento di oggetti irraggiungibili, ai quali nel repository non vi sono riferimenti (nessun ramo o tag fa riferimento). Le informazioni sugli oggetti irraggiungibili sono conservate in file pack separati ('cruft packs'), il che ha reso necessario il loro riflesso negli indici multi-pack MIDX (multi-pack index) per includere oggetti che inizialmente erano irraggiungibili e conservati solo nel pacchetto di cruft, ma che sono diventati raggiungibili dopo un commit che fa riferimento a questi.\n
Nella nuova versione, durante la riimpacchettatura dei file pack, \u00e8 stato garantito il mantenimento di copie aggiuntive degli oggetti raggiungibili, conservati solo nei file cruft. Questa modifica garantisce che nel set di file pack, utilizzati per memorizzare oggetti raggiungibili, non ci siano oggetti che si riferiscano ad altri oggetti memorizzati al di fuori di questo set. Per escludere il contenuto non raggiungibile dai pacchetti di indici multipli (MIDX) dei file cruft, \u00e8 stata proposta l'impostazione \u00abrepack.MIDXMustContainCruft\u00bb, che permette di ridurre significativamente la dimensione di tali indici. L'attivazione dell'impostazione nel repository GitHub ha consentito di ridurre la dimensione 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
\u00c8 stata aggiunta al comando \u00abgit pack-objects\u00bb l'opzione \u00ab--path-walk\u00bb, che introduce un nuovo metodo per raccogliere informazioni sugli oggetti durante la riimpacchettatura dei file pack. Invece di percorrere gli oggetti in ordine di revisione, utilizzando la modalit\u00e0 \u00ab--path-walk\u00bb, gli oggetti vengono elaborati attraverso il passaggio dei percorsi dei file, permettendo di impacchettare simultaneamente tutti gli oggetti con lo stesso percorso di file. Questo approccio consente di escludere l'euristica che utilizza l'hashing per stabilire il legame tra un oggetto e il suo percorso di file, eliminando anche la necessit\u00e0 di ordinare gli oggetti prima dell'imballaggio. Utilizzando la modalit\u00e0 \u00ab--path-walk\u00bb, la dimensione dei file pack generati risulta significativamente inferiore rispetto al raggruppamento degli 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 tramite il comando \u00abgit stash\u00bb. Il nuovo formato consente di codificare le modifiche salvate (registrazioni stash) come una sequenza di commit. Sono stati proposti i sottocomandi \u00abgit stash import\u00bb e \u00abgit stash export\u00bb per l'importazione e l'esportazione, che possono essere utilizzati per trasferire stati salvati da un sistema all'altro ed eseguire operazioni di push o pull su questi stati come su normali rami o tag. git stash export \u2014to-ref refs\/stashes\/my-stash git push origin refs\/stashes\/my-stash \u2026 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, utilizzando le opzioni «—batch» e «—batch-check» \u00e8 stata implementata la possibilit\u00e0 di visualizzare informazioni sugli oggetti mancanti (ad esempio, a causa di corruzione del repository) e sui sottomoduli. In precedenza, specificando il percorso di un sottomodulo, il comando «git cat-file —batch-check» restituiva «missing», mentre ora mostra l'identificatore dell'oggetto.\n
Nel comando «git log» sono state implementate ottimizzazioni basate sui filtri di Bloom per accelerare 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, dopo essere stati considerati sperimentali dal 2019. I comandi vengono presentati come equivalenti moderni di «git checkout», separando funzionalit\u00e0 poco correlate come la manipolazione dei rami (cambio e creazione) e il ripristino dei file nella directory di lavoro.\n
\u00c8 stata dichiarata obsoleta e programmata per la rimozione nel ramo Git 3.0 la comando «git whatchanged», equivalente a «git log —raw».\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 paginato.\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 di Git \u00e8 stata autorizzata l'uso della parola chiave «bool», introdotta nel standard C99. Sono state documentate anche alcune funzionalit\u00e0 del C99, utilizzate sperimentalmente in Git (ad esempio, a met\u00e0 del 2026 si prevede di autorizzare l'uso di costruzioni come «(struct foo){ .member = value };»). Il compilatore con supporto C99 \u00e8 obbligatorio per Git dal 2021, ma le funzionalit\u00e0 della specifica C99 vengono implementate con estrema cautela per mantenere la compatibilit\u00e0 con i compilatori che supportano solo parzialmente questo standard.\n
Sono state apportate modifiche alle regole per l'accettazione delle patch, consentendo l'invio di patch sotto pseudonimo e non solo con il nome reale dello sviluppatore. La modifica \u00e8 conforme alle regole di accettazione delle patch nel kernel Linux.\n
\u00c8 stata aggiornata la lista delle modifiche che compromettono la compatibilit\u00e0 e che verranno apportate nel ramo Git 3.0. Tra i cambiamenti significativi 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'implementazione del formato «reftable» per la memorizzazione nel repository dei riferimenti a rami e tag (\u00e8 stato utilizzato lo storage a blocchi del progetto JGit, ottimizzato per archiviare un numero molto elevato di riferimenti). <\/ul>\n