Come è stato progettato Git?

Git non è stato progettato tanto quanto evoluto .

Dai un'occhiata da solo. Clona il repository git ufficiale , aprilo in gitk (o nella tua grafica preferita git log viewer), e guarda le sue prime revisioni.

Vedrai che in origine aveva solo la funzionalità di base (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 le attività comuni; a poco a poco, questi script sono stati incorporati nella distribuzione git (si veda per un primo esempio 839a7a0 ). Ogni volta che c'era un nuovo bisogno, gli script sono stati 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 si sviluppa organicamente su di esso, è ciò che dà potere al git. Naturalmente, è anche ciò che gli dà la grande quantità di comandi e opzioni con nomi diversi.

The compression, the graphs, getting rid of revision numbers, emphasizing branching, stashing, remotes... Where did it all come from?

Molto non era lì all'inizio.

Mentre ogni oggetto è stato singolarmente compresso e i duplicati sono stati evitati con la loro denominazione, i file "pack" responsabili della compressione elevata che siamo abituati a vedere in git non esistevano. La filosofia all'inizio era "lo spazio su disco è economico".

Se con "i grafici" intendi visualizzatori grafici come gitk , sono apparsi in seguito (AFAIK, il primo era gitk ). AFAIK, BitKeeper ha anche un visualizzatore di cronologia grafica.

Eliminando i numeri di versione, infatti, il concetto base di git di utilizzare un filesystem indirizzato al contenuto per archiviare gli oggetti, proveniva principalmente da monotone . A quel tempo, la monotonia era lenta; se così non fosse, è possibile che Linus l'abbia usato invece di creare git.

Enfatizzare la ramificazione è in qualche modo inevitabile su un sistema di controllo della versione distribuito, poiché ciascun clone agisce come un ramo separato.

La conservazione ( git stash ) è, IIRC, abbastanza recente. I reflog, che usa, non erano lì all'inizio.

Inizialmente i telecomandi non erano presenti. In origine, hai copiato gli oggetti manualmente usando rsync .

Uno per uno, ciascuna di queste funzionalità è 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 principale "idraulico" di git e proporlo per l'inclusione. Se è buono, probabilmente verrà accettato, migliorando ulteriormente l'utilità di git (e la sua complessità della riga di comando).

Penso che il punto principale sia semplicemente che git è 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 un codebase con una combinazione comparabile di dimensioni e numero di contributori come il kernel di Linux e che ancora si occupa della maggior parte dell'integrazione lavora da solo.

Quindi Linus conosceva i requisiti e i casi d'uso per un sistema di controllo delle versioni distribuito meglio di chiunque altro. E naturalmente è stato utile che la maggior parte di quella codifica di cui si occupava fosse in C, e in gran parte critica dal punto di vista delle prestazioni.

Fondamentalmente è l'ultimo esempio di graffiare il proprio prurito.

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

Imagine that you have a computer that has nothing on it but a text editor and a few file system commands. Now imagine that you have decided to write a large software program on this system. Because you’re a responsible software developer, you decide that you need to invent some sort of method for keeping track of versions of your software so that you can retrieve code that you previously changed or deleted. What follows is a story about how you might design one such version control system (VCS) and the reasoning behind those design choices.