Come posso raggruppare i commit in un sistema di controllo della versione come git

C'è una cronologia di commit flat lungo perché le modifiche sono sequenziali. Ognuno costruisce sullo stato "prima" e lascia uno stato "dopo". Sarebbe difficile che le modifiche non riflettano questo.

Un'opzione per il raggruppamento di modifiche correlate è l'uso dei tag - link sebbene siano usati di più per contrassegnare un punto nella cronologia anziché raggruppare i commit disparati.

Per raggruppare insieme esegue il commit in quelli più grandi, puoi anche fare il rebasing interattivo.

I rami sono un'opzione, puoi creare un ramo e fare un mucchio di commit logicamente correlati. Puoi unire nuovamente questi commit al master come desiderato, probabilmente usando l'opzione --no-ff .

La relazione tra i rami può anche essere vista in strumenti visuali come gitg / gitx

Ho avuto lo stesso problema a pensarci fino a quando ho scoperto che Git numeri i suoi rami parentali. Detto questo, i commit di solito fastidiosi che vengono generati possono essere considerati nodi di riepilogo. E tutti i dettagli aggiuntivi possono essere banditi dalla vista, lasciando una singola cronologia lineare riassunta.

Controlla questo post del blog per dettagli ed esempi.

Il tuo gruppo si impegna nelle filiali: ogni ramo è un insieme di commit. Quando unisci le commit, stai mettendo un set di commit all'interno di un altro ramo, creando efficacemente una gerarchia di commit: ramo principale, caratteristiche, bug, esperimenti, lo chiami.

Idealmente, il tuo ramo principale è una successione di commit di unione. Se si guardano solo i primi genitori (i comandi git accettano tale opzione), si avrà la vista di alto livello della cronologia (si spera che si scriva un commit di fusione significativo, non quello generato automaticamente). Ma quando guardi i 2 °, 3 °, ecc. Genitori di un'unione nella tua storia, stai aprendo la scatola per vedere cosa c'è in una fusione. Qui hai i dettagli di quello che è successo.