rilascio del sistema di controllo distribuito delle versioni . Git è uno dei sistemi di controllo delle versioni più popolari, affidabili e ad alte prestazioni, che offre strumenti flessibili per lo sviluppo non lineare, basati su ramificazione e fusione. Per garantire l'integrità della storia e la resistenza alle modifiche retroattive, viene utilizzata la hash implicita dell'intera storia precedente in ogni commit, è inoltre possibile la verifica tramite firme digitali dei tag e dei commit da parte degli sviluppatori.
Rispetto all'ultima versione, nella nuova versione sono stati accettati 583 cambiamenti, preparati con la partecipazione di 84 sviluppatori, di cui 32 hanno partecipato per la prima volta allo sviluppo. :
- Si sta avvicinando alla stabilizzazione e alla piena funzionalità la possibilità di clonazione parziale (partial clones), che consente di trasferire solo parte dei dati e lavorare con una copia incompleta del repository. Nella clonazione normale, vengono copiati tutti i dati dal repository, inclusa ogni versione di ciascun file nella cronologia delle modifiche. Per i repository molto grandi, la copia dei dati porta a un notevole aumento del traffico e dello spazio su disco, anche se lo sviluppatore è interessato solo a un sottoinsieme dei file. Per semplificare l'ottenimento solo di una parte dell'albero di lavoro dei codici sorgente, nella nuova versione è stata proposta un comando sperimentale «sparse-checkout» e una nuova opzione «—sparse» per il comando «clone».
In precedenza, il processo di clonazione selettiva avveniva tramite la definizione per escludere contenuti superflui e l'opzione «—no-checkout» per disabilitare il completamento dei file mancanti. Dopo ciò, prima di eseguire l'operazione checkout, era necessario attivare l'impostazione core.sparseCheckout e definire nel file .git/info/sparse-checkout un elenco di modelli di percorsi da escludere. Ad esempio, per clonare senza blob e vietare l'estrazione di file da directory nidificate di profondità 2 o più, si poteva eseguire:
git clone —filter=blob:none —no-checkout /your/repository/here repo
$ cd repo
$ cat >.git/info/sparse-checkout <EOF
/*
!/*
EOF
$ git config core.sparseCheckout 1
$ git checkout .Il nuovo comando «git sparse-checkout» semplifica notevolmente il lavoro e riduce il processo di organizzazione del lavoro con un repository incompleto a questi comandi:
git clone —filter=blob:none —sparse /your/repository/here repo
git sparse-checkout set /path/to/check/outIl comando sparse-checkout consente di impostare un elenco di percorsi per il checkout (set) senza configurare manualmente .git/info/sparse-checkout, e anche di visualizzare l'elenco attuale dei percorsi (list) e abilitare o disabilitare il partial checkout (enable/disable).
Per ottimizzare il lavoro con repository molto grandi e elenchi di modelli, è stata proposta un'impostazione ««, che limita i modelli consentiti (invece di modelli .gitignore arbitrari, è possibile specificare se estrarre tutti i percorsi e tutti i file in una sotto-cartella specificata). Ad esempio, se in un grande repository esiste la cartella «A/B/C» e tutto il lavoro è concentrato nella sottocartella «C», abilitando la modalità sparseCheckoutCone, il comando «git sparse-checkout set A/B/C» estrarrà completamente il contenuto di «C», ma da «A» e «B» estrarrà solo le parti necessarie per lavorare su «C».
- Dalla documentazione («git rebase -h») sono state rimosse tutte le menzioni dell'opzione «—preserve-merges», che è stata dichiarata obsoleta e per spostare un insieme di commit si dovrebbe invece usare ««.
- Per migliorare la leggibilità dei messaggi con patch inviati alle mailing list, è stata aggiunta l'opzione «git format-patch —cover-from-description subject», specificando la quale, il primo paragrafo del testo della descrizione del ramo viene utilizzato come oggetto della lettera di accompagnamento per l'insieme di patch.
- È stata implementata la compatibilità tra il comando «git apply —3way» e l'impostazione «merge.conflictStyle» («git apply» ora considera lo stile di descrizione dei conflitti in merge.conflictStyle quando necessario risolvere un conflitto dopo un tentativo di applicare un file patch al repository).
- Il codice di definizione delle funzioni, utilizzato in operazioni come «git diff/grep —show-function/—function-context», è stato ampliato per supportare la definizione dei confini delle funzioni nei programmi in linguaggio .
- In «git add», «git commit», «git reset» e altri comandi è stata aggiunta una nuova opzione «—pathspec-from-file», che consente di caricare un elenco di percorsi da un file o da uno stream di input, invece di elencarli nella riga di comando.
- È stato risolto un problema con la definizione delle rinominazioni a livello di cartelle durante la registrazione dei commit. La definizione non funzionava nel caso in cui il contenuto di una sottocartella fosse stato spostato nella radice del repository.
- È stata proposta un'implementazione iniziale del comando ristrutturato «git add -i», che consente di aggiungere contenuti modificati in modalità interattiva, riscritta da Perl a C. È in corso una ristrutturazione simile del comando «git add -p».
- È stata effettuata una rifattorizzazione del comando «git log —graph», che genera un'immagine ASCII del grafo con la cronologia delle modifiche nel repository. La ristrutturazione ha permesso di migliorare e semplificare notevolmente l'output senza alterare la struttura della storia, il che ha risolto, ad esempio, il problema della fuoriuscita dell'immagine oltre i limiti della larghezza della riga del terminale.
- L'opzione «git log —format=..», che consente di modificare il formato di output,
è stata estesa con il supporto per i flag «l/L» per visualizzare solo la parte dell'indirizzo email indicata prima del simbolo «@» (ad esempio, utile quando tutti gli sviluppatori hanno email nello stesso dominio). - Nel comando «git submodule» è stata aggiunta la sottocomando «set-url».
- I set di test sono stati aggiornati in preparazione al passaggio a
un algoritmo di hash SHA-2 invece di SHA-1.
Fonte: opennet.ru
