Come è stato progettato Git?

Di recente il mio posto di lavoro è passato a Git e lo adoro (e odio!). Lo adoro davvero ed è estremamente potente. L'unica parte che odio è che a volte è troppo potente (e forse un po 'conciso / confuso).

La mia domanda è ... Come è stato progettato Git? Usandolo per un breve periodo di tempo, si ha la sensazione che sia in grado di gestire molti flussi di lavoro oscuri che altri sistemi di controllo della versione non potrebbero. Ma è anche elegante sotto. E veloce!

Questo è senza dubbio in parte il talento di Linus. Ma mi chiedo, il design generale di git era basato su qualcosa? Ho letto di BitKeeper ma i conti sono scarsi sui dettagli tecnici. La compressione, i grafici, l'eliminazione dei numeri di revisione, l'enfasi sulla ramificazione, lo stashing, i telecomandi ... Da dove proviene tutto?

Linus ha davvero buttato questo fuori dal parco e praticamente al primo tentativo! È abbastanza buono da usare una volta superata la curva di apprendimento.

Git non è stato progettato tanto quanto evoluto .

Dai un'occhiata da solo. Clona il repository git ufficiale , aprilo gitk(o il tuo visualizzatore di log git grafico preferito) e guarda le sue prime revisioni.

Vedrai che originariamente aveva solo le funzionalità fondamentali (il database degli oggetti e l'indice). Tutto il resto è stato fatto a mano . Tuttavia, questo piccolo core è stato progettato per essere facilmente automatizzato tramite script di shell. I primi utenti di git hanno scritto i propri script di shell per automatizzare attività comuni; a poco a poco, questi script sono stati incorporati nella distribuzione git (vedi per un primo esempio 839a7a0 ). Ogni volta che c'era un nuovo bisogno, gli script venivano adattati per consentirlo. Molto più tardi, molti di questi script sarebbero stati riscritti in C.

Questa combinazione di un nucleo pulito, ortogonale (che puoi ancora usare direttamente se ne hai bisogno), con uno strato superiore che è cresciuto organicamente su di esso, è ciò che dà a git il suo potere. Naturalmente, è anche ciò che gli dà la grande quantità di comandi e opzioni dai nomi strani.

La compressione, i grafici, l'eliminazione dei numeri di revisione, l'enfasi sulla ramificazione, lo stashing, i telecomandi ... Da dove proviene tutto?

Molto di ciò non era presente all'inizio.

Mentre ogni oggetto è stato compresso individualmente e i duplicati sono stati evitati dalla loro denominazione, i file "pack" che sono responsabili dell'alta compressione che siamo abituati a vedere in Git non esistevano. La filosofia all'inizio era "lo spazio su disco costa poco".

Se per "i grafici" intendi i visualizzatori grafici come gitk, sono apparsi più tardi (AFAIK, il primo era gitk). AFAIK, BitKeeper aveva anche un visualizzatore cronologico grafico.

Sbarazzarsi dei numeri di versione, in effetti il ​​concetto chiave di git di usare un filesystem indirizzato al contenuto per archiviare gli oggetti, proveniva principalmente dal monotono . A quel tempo, il monotono era lento; se così non fosse, è possibile che Linus lo avrebbe usato invece di creare git.

L'enfatizzazione della ramificazione è alquanto inevitabile su un sistema di controllo di versione distribuito, poiché ciascun clone agisce come una diramazione separata.

Stashing ( git stash) è, IIRC, abbastanza recente. I reflog, che utilizza, non erano presenti all'inizio.

Anche i telecomandi non c'erano inizialmente. Inizialmente, gli oggetti venivano copiati a mano utilizzando rsync.

Uno per uno, ognuna di queste funzioni è stata aggiunta da qualcuno. Non tutti, forse nemmeno la maggior parte, sono stati scritti da Linus. Ogni volta che qualcuno sente un bisogno che git non soddisfa, si può creare una nuova funzionalità sul livello "idraulico" di base di git e proporlo per l'inclusione. Se è buono, probabilmente verrà accettato, migliorando ulteriormente l'utilità di git (e la sua complessità da riga di comando).

Penso che il punto principale sia semplicemente che git sia stato progettato dalla persona più qualificata del pianeta per farlo. E non sto parlando di talento, sto parlando di esperienza: dubito che ci sia qualcun altro che è stato responsabile di una base di codice con una combinazione comparabile di dimensioni e numero di contributori come il kernel Linux e che attualmente si occupa ancora della maggior parte dell'integrazione lavorare da solo.

Quindi Linus conosceva i requisiti e i casi d'uso di un sistema di controllo di versione distribuito meglio di chiunque altro. E naturalmente ha aiutato il fatto che la maggior parte di quel codice che stava trattando fosse in C, e gran parte della sua performance era critica.

Fondamentalmente è il massimo esempio di grattarsi il prurito.

È stato progettato praticamente esattamente come descritto in The Git Parable .

Immagina di avere un computer che non ha nient'altro che un editor di testo e alcuni comandi del file system. Ora immagina di aver deciso di scrivere un grande programma software su questo sistema. Poiché sei uno sviluppatore di software responsabile, decidi che devi inventare una sorta di metodo per tenere traccia delle versioni del tuo software in modo da poter recuperare il codice che hai precedentemente modificato o eliminato. Quella che segue è una storia su come è possibile progettare uno di questi sistemi di controllo della versione (VCS) e il ragionamento alla base di tali scelte di progettazione.