Rilascio del sistema di controllo del codice sorgente distribuito Git 2.22

Introdotto rilascio di un sistema di controllo del codice sorgente distribuito Git 2.22.0. Git è uno dei sistemi di controllo delle versioni più popolari, affidabili e ad alte prestazioni, che fornisce strumenti di sviluppo flessibili e non lineari basati su branching e merging. Per garantire l'integrità della cronologia e la resistenza a modifiche retroattive, viene utilizzato l'hashing implicito dell'intera cronologia precedente in ogni commit, ed è anche possibile certificare singoli tag e commit con firme digitali degli sviluppatori.

Rispetto alla versione precedente, la nuova versione comprende 745 modifiche, preparate con la partecipazione di 74 sviluppatori, di cui 18 hanno preso parte allo sviluppo per la prima volta. Il principale innovazioni:

  • Disponibile dalla versione 1.18, la nuova modalità commit rebase "git rebase --rebase-merges" sostituisce la vecchia opzione "--preserve-merges", che ora è deprecata. L'operazione "git rebase" viene utilizzata per sostituire una serie di commit con un nuovo commit di base, ad esempio, per spostare un ramo separato che sta sviluppando alcune nuove funzionalità allo stato corrente del ramo principale, che include le correzioni aggiunte dopo il ramo :

    o - o - o (mia-funzione)

    /

    o - o - o - o - o (maestro)

    o - o - o (mia-funzione)

    /

    o - o - o - o - o (maestro)

    Per preservare la struttura del ramo in un ramo migrato, si poteva precedentemente utilizzare l'opzione “--preserve-merges” che, se eseguita in modalità interattiva (git rebase -i --preserve-merges), consentiva di modificare la cronologia dei commit, ma non ha garantito la completa conservazione della struttura del repository. La nuova modalità “--rebase-merges” consente di preservare la struttura delle modifiche nel ramo sottoposto a migrazione, fornendo al contempo una gamma completa di operazioni interattive, tra cui l'eliminazione, il raggruppamento e la ridenominazione dei commit.

    Ad esempio, "--rebase-merges" permette ricaricare i commit da un ramo separato a un ramo master più recente, mantenendo la struttura del ramo nel ramo migrato, e apportare al volo alcune modifiche alle note di commit.

  • Aggiunto supporto per la creazione di un nuovo ramo in base al risultato della determinazione della base di unione di altri due rami (base di unione, collegamento a un antenato comune) utilizzando le costruzioni “git branch new A...B” e “git checkout -b new A...B", in cui "A...B" implica la definizione di una base di unione tra due commit specificati, in modo simile a come "git checkout A...B" sposta l'HEAD al commit di base e "diff A. ..B" mostra le modifiche tra il commit "B" e lo stesso del commit "A" "Ancestor.

    Ad esempio, quando si lavora su un ramo my-feature separato, questa funzionalità può essere utilizzata quando si desidera iniziare da un ramo diverso, ad esempio, dalla stessa posizione nel ramo master da cui è stato estratto il ramo my-feature. In precedenza, ciò richiedeva l'esame manuale del registro delle modifiche, il che era scomodo se si disponeva di una lunga cronologia di modifiche, quindi l'esecuzione di "git merge-base master my-feature" per calcolare l'hash della base di unione tra i rami master e my-feature e creando un nuovo ramo relativo all'antenato comune " git branch my-other-feature hash." In Git 2.22, puoi utilizzare la sintassi "git branch my-other-feature A...B" per creare un ramo relativo alla base di unione di altri due rami;

  • Aggiunta l'opzione "git branch --show-current" per visualizzare il nome del branch ottenuto durante l'operazione di checkout;
  • Aggiunta l'opzione “git checkout —no-overlay — dir”, che consente, durante l'esecuzione di un'operazione di checkout, di portare il contenuto della directory dir in un modulo che corrisponde pienamente allo stato del ramo master. Ad esempio, se nella copia locale della directory dir è presente un file che non si trova nel ramo master, per impostazione predefinita quando si esegue "git checkout master - dir" verrà lasciato e se "--no-overlay " viene specificata l'opzione, verrà eliminata;
  • Il comando "git diff" utilizza un'API universale per l'analisi delle opzioni, che rende possibile unificare la gestione delle opzioni con altre utilità git. Ad esempio, in “git diff”, tutte le opzioni ora hanno i loro antagonisti (“--function-context” e “--no-function-context”);
  • Aggiunta la possibilità di filtrare i tag estesi allegati ai commit nell'output del "log git" ("trailer" - flag di informazioni aggiuntive, come Firmato da e Co-autore). È possibile filtrare le etichette sia per chiave che per valore, ad esempio:
    "git log --pretty="%(trailers:key=Reviewed-by,valueonly)";

  • È stato aggiunto un nuovo motore di tracciamento, Trace2, che offre un formato di output più flessibile e strutturato. Trace2 consente di raccogliere dati di telemetria sulle operazioni eseguite e dati sulle prestazioni per analisi e debug più dettagliati (il gestore viene assegnato dall'utente, nessun dato viene inviato all'esterno);
  • È stato reso più leggibile il report “git bisect”, in cui vengono ora evidenziati più chiaramente i commit problematici e vengono visualizzate le statistiche riassuntive sulle modifiche per ogni file (a livello del numero di righe modificate);
  • L'euristica per determinare la ridenominazione delle directory è stata rielaborata per eliminare la falsa installazione delle etichette di ridenominazione. In caso di dubbio, tali directory sono ora contrassegnate come in conflitto;
  • Viene visualizzato un avviso quando si tenta di installare un tag su un altro tag, cosa che di solito viene eseguita per errore e può portare a impostare il tag sul commit sbagliato (ad esempio, una costruzione come "git tag -f -m "messaggio aggiornato" my-tag1 my- tag2″ comporterà la creazione di un tag sul vecchio tag, mentre lo sviluppatore si aspettava che il nuovo tag fosse installato sul commit a cui puntava il vecchio tag);
  • La generazione è abilitata per i repository bitmap (struttura "bitmap di raggiungibilità" basata su disco), che memorizzano dati su insiemi di oggetti disponibili per ciascun commit e consentono di determinare rapidamente la presenza di un oggetto di base. Questa struttura riduce notevolmente i tempi di esecuzione delle operazioni di recupero dei dati (git fetch).

Fonte: opennet.ru

Aggiungi un commento