Git (software): differenze tra le versioni

Versione delle 18:33, 13 lug 2019

Versione attuale delle 15:55, 5 ago 2025

(34 versioni intermedie di 25 utenti non mostrate)

Riga 4:

|Nome = Git

|Screenshot =

|Didascalia =

|Sviluppatore = inizialmente [[Linus Torvalds]], attualmente [[Junio Hamano]]

|UltimaVersioneBeta =

|DataUltimaVersioneBeta =

|SistemaOperativo = gnu/linux

|SistemaOperativo2 = osx

Riga 13:

|SistemaOperativoAltri = [[Solaris (sistema operativo)|Solaris]]

|Genere = Sistema di controllo versione

|SoftwareLibero = sì

|Lingua =

}}

'''Git''' è un'applicazione [[software]] diper il [[controllo di versione distribuito]] utilizzabile da [[interfaccia a riga di comando]], creato da [[Linus Torvalds]] nel [[2005]].

Git (che nello [[Slang|slang americanobritannico]] significa ''idiota''<ref>{{Cita web |https://www.wordreference.com/enit/git |Significato di git |9 giugno 2016}}</ref>) nacque per essere un semplice strumento per facilitare lo sviluppo del [[kernel]] [[Linux (kernel)|kernel Linux]] ed è diventato uno degli strumenti di [[controllo versione]] più diffusi. La sua progettazione si ispirò aad analoghi strumenti, (allora [[Software proprietario|proprietari]]), analoghi come [[BitKeeper]] e [[Monotone (software)|Monotone]].

== Storia ==

Riga 26 ⟶ 25:

Torvalds voleva un sistema distribuito che potesse usare come BitKeeper, ma nessuno dei sistemi disponibili gratuitamente soddisfaceva i suoi bisogni, particolarmente il suo bisogno di velocità.

{{cn|Ecco un messaggio e-mail (tradotto in italiano) che scrisse il 7 aprile [[2005]]}} mentre stava scrivendo il primo prototipo:

{{citazione|Tutti i sistemi di controllo versione che ho preso in considerazione rendono [il lavoro] difficile. Una delle cose (in realtà, la cosa principale) a cui ho lavorato è rendere quel procedimento realmente ''efficiente''.

Se ci vuole mezzo minuto per applicare una patch, e ci si deve ricordare i confini delle modifiche applicate, ecc. (e francamente, si potrebbe considerare mezzo minuto ''poco'' per la maggior parte dei sistemi di controllo versione che ci sono in giro, e per un progetto della dimensione di Linux), allora una serie di 250 e-mail (che non è affatto inaudito quando mi sincronizzo con Andrew, per esempio) richiede due ore. Neanche BitKeeper si dimostrò rapido (in effetti, confrontato a qualunque altra cosa, BitKeeper ''è'' velocissimo, spesso uno o due ordini di grandezza migliore), e richiedeva circa 10–15 secondi per ogni e-mail quando facevo il merge con Andrew. Tuttavia, con BitKeeper quello non era un problema tanto grosso, dato che i merge BitKeeper<->BitKeeperBitKeeper↔BitKeeper sono più semplici, e non ho mai dovuto fare un più lento merge manuale con gli altri sviluppatori principali.

Perciò il merge, in un sistema di controllo versione basato sull'applicazione di patch dovrebbe essere più ''veloce'' di BitKeeper. Il che è veramente difficile. E per questo sto scrivendo alcuni script per tentare di tener traccia delle cose in modo nettamente più veloce.

Riga 42 ⟶ 41:

# Prendi [[Concurrent Versions System|CVS]] come esempio di che cosa ''non'' fare; se hai un dubbio, fai l'esatto contrario. Per citare Linus, che parlava un po' ironicamente:

#: “Per i primi 10 anni di manutenzione del kernel, usavamo letteralmente tarball (archivi compressi) e patch, che è un sistema di gestione del codice sorgente molto migliore di CVS. Poi ho finito per usare CVS per 7 anni in un'azienda ''[presumibilmente [[Transmeta]]]'' e lo odio appassionatamente. Quando dico che odio CVS appassionatamente, devo anche dire che se ci sono utenti SVN ([[Subversion]]) tra il pubblico, potreste volervene andare. Perché a causa del mio odio di CVS ritengo Subversion il progetto meno sensato che sia mai cominciato. Per un po' lo slogan di Subversion era ‘CVS fatto bene'bene’, o qualcosa di simile, e se incominci con quel tipo di slogan, non puoi andare da nessuna parte. Non c'è modo di fare CVS bene.”

# Supporto di un flusso di lavoro distribuito, simile a BitKeeper. Come BitKeeper, Git non usa un server centralizzato.

#: “BitKeeper non è solamente il primo sistema di controllo dei sorgenti che abbia mai pensato che valesse la pena usare; è stato anche il sistema che mi ha fatto capire perché ce ne sia effettivamente bisogno, e come si possa operare in modo efficace. Perciò, sebbene da un punto di vista tecnico Git sia molto diverso da BitKeeper (il che era un altro obiettivo di progettazione, perché volevo rendere chiaro che non era un clone di BitKeeper), molti dei procedimenti che usiamo con Git vengono direttamente dai procedimenti che abbiamo imparato da BitKeeper.”

Riga 55 ⟶ 54:

Il 16 giugno [[2005]] è stata pubblicata la versione 2.6.12 del kernel di Linux, la prima gestita con Git.

Sebbene fortemente influenzato da BitKeeper, Torvalds ha deliberatamente tentato di evitare approcci convenzionali, il che ha prodotto un sistema molto innovativo<ref>{{Cita web|url=https://www.ictea.com/cs/index.php?rp=%2Fknowledgebase%2F3484%2FiQue-es-el-software-de-control-de-versiones-GIT.html&language=italian|titolo=Che cosa è un software di controllo versione Git?|accesso=20 marzo 2025}}</ref>.

Torvalds ha sviluppato il sistema fino a quando è diventato usabile da utenti tecnici,; poi, il 26 luglio [[2005]], ha ceduto la manutenzione a Junio Hamano, un importante contributore al progetto. Hamano è stato il responsabile della versione 1.0, pubblicata il 21 dicembre [[2005]], e rimane oggi il manutentore.

Hamano è stato il responsabile della versione 1.0, pubblicata il 21 dicembre [[2005]], e rimane oggi il manutentore.

== Descrizione ==

=== Caratteristiche ===

Il progetto di Git è la sintesi dell'esperienza di Torvalds nel mantenere un grande progetto di sviluppo distribuito, della sua intima conoscenza delle prestazioni del [[file system]], e di un bisogno urgente di produrre un sistema soddisfacente in poco tempo.

Queste influenze hanno condotto alle seguenti scelte implementative:

* Forte supporto allo sviluppo non lineare. Git supporta diramazione e fusione (branching and merging) rapide e comode, e comprende strumenti specifici per visualizzare e navigare una cronologia di sviluppo non lineare. Un'assunzione centrale in Git è che una modifica verrà fusa più spesso di quanto sia scritta, dato che viene passata per le mani di vari revisori. Torvalds stesso fa la maggior parte delle fusioni e una piccola parte delle correzioni dirette al codice, perciò egli stesso ha dimostrato che questo aspetto funziona bene.

Riga 69 ⟶ 67:

* Gestione efficiente di grandi progetti. Git è molto veloce e scalabile. È tipicamente un [[ordine di grandezza]] più veloce degli altri sistemi di controllo versione, e due ordini di grandezza più veloce per alcune operazioni<ref>{{Cita web|cognome=Dreier |nome=Roland |url=http://digitalvampire.org/blog/index.php/2006/11/16/oh-what-a-relief-it-is/ |titolo=Oh what a relief it is |data=13 novembre 2006}}, observing that "git log" is 100x faster than "svn log" because the latter has to contact a remote server.</ref>.

* Autenticazione crittografica della cronologia. La cronologia di Git viene memorizzata in modo tale che il nome di una revisione particolare (secondo la terminologia Git, una "commit") dipende dalla completa cronologia di sviluppo che conduce a tale commit. Una volta che è stata pubblicata, non è più possibile cambiare le vecchie versioni senza che ciò venga notato. (Anche [[Monotone (software)|Monotone]] ha questa proprietà.)

* Progettazione del [[toolkit]]. Git è un insieme di programmi di base scritti in [[C (linguaggio)|linguaggio C]], e molti script di shell che forniscono comodi incapsulamenti. È facile concatenare i componenti per fare altre cose utili.

* Strategie di fusione intercambiabili. Come parte della progettazione del suo toolkit, Git ha un modello ben definito di una fusione incompleta, e ha più algoritmi per tentare di completarla. Se tutti gli algoritmi falliscono, tale fallimento viene comunicato all'utente e viene sollecitata una fusione manuale. Pertanto è facile sperimentare con nuovi algoritmi di fusione.

* La spazzatura si accumula fino a quando viene raccolta. Quando si abortisce un comando o si scartano delle modifiche si lasciano degli oggetti inutilizzabili nel database. Tipicamente, questi sono solo una piccola parte della cronologia continuamente crescente degli oggetti utili, ma il comando di recupero dello spazio, <code>git gc --prune</code>, può richiedere parecchio tempo.

Riga 90 ⟶ 88:

=== Implementazione ===

Le primitive di Git non costituiscono inerentemente a un sistema di controllo della versione. Per esempio, git non fornisce una numerazione progressiva delle revisioni del software.

Torvalds spiega che, {{citazione|in molti modi si può considerare git come un filesystem — è indirizzabile in base al contenuto, e include il concetto di ''versione'', ma io in realtà l'ho progettato guardando il problema dal punto di vista di una persona esperta di ''filesystem'' (beh, i kernel sono quello che faccio), e effettivamente ho assolutamente ''zero'' interesse nel creare un sistema tradizionale di gestione della configurazione software.

Riga 100 ⟶ 98:

* Un oggetto ''albero'' è l'equivalente di una directory: contiene una lista di nomi di file, ognuno con alcuni bit di tipo e il nome di un oggetto blob o albero che è il file, il link simbolico, o il contenuto di directory. Questo oggetto descrive un'istantanea dell'albero dei sorgenti.

* Un oggetto ''commit'' (revisione) collega gli oggetti albero in una cronologia. Contiene il nome di un oggetto albero (della directory dei sorgenti di livello più alto), data e ora, un messaggio di archiviazione (log message), e i nomi di zero o più oggetti di commit genitori. Le relazioni tra i blob si possono trovare esaminando gli oggetti albero e gli oggetti commit.

* Un oggetto ''tag'' (etichetta) è un contenitore che contiene riferimenti a un altro oggetto, può tenere meta-datimetadati aggiuntivi riferiti a un altro oggetto. Il suo uso più comune è memorizzare una firma digitale di un oggetto commit corrispondente a un particolare rilascio dei dati gestiti da Git.

I blob sono file binari "non parlanti" che conservano informazioni eterogenee, quali: file testuali o binari, immagini, [[codice sorgente]], [[File archivio|archivi]]. Qualsiasi tipo di file è compresso in un file binario prima di essere salvato in repository Git. Git ne calcola l'hash con l'algoritmo [[SHA-1]].<br />

L'[[Funzione di hash#Algoritmo di hash|hash]] è una sequenza di 40 caratteri alfanumerici, che rappresentano un numero [[esadecimale]], ed è utilizzato da Git per identificare in modo univoco qualsiasi commit nel repository, tracciando il file al suo interno e le eventuali modifiche effettuate. L'hash SHA-1 di un oggetto è unico, risultando lo stesso a prescindere dal repository e dal computer utilizzato.

Git calcola tale codice hash, e usa questo codice come nome dell'oggetto e come identificatore del suo contenuto: file con nomi e/o percorsi diversi, ma con identico contenuto (blob), condividono lo stesso hash.<ref>{{cita libro | autore = Ferdinando Santacroce | url = https://books.google.it/books?id=pf2RDwAAQBAJ&pg=PT52&lpg=PT52#v=onepage&q&f=false | titolo = Git: Guida per imparare a gestire, distribuire e versionare codice | pagine = pp. 47, 52-53 | editore = Apogeo | città = Milano | anno = 2017 | isbn = 9788850334759 | oclc = 1065376849 | accesso = 10 luglio 2019 | urlarchivio = https://archive.todayis/20190710172448/https://books.google.it/books?id=pf2RDwAAQBAJ&pg=PT47&lpg=PT47&dq=%22ferdinando+santacroce%22&source=bl&ots=P5BQMwWjg9&sig=ACfU3U3gs2n-DPiPOw-xrDZC5IDou7HORg&hl=it&sa=X&ved=2ahUKEwiOop-i6qrjAhXE2aQKHa7lAYM4FBDoATALegQICRAB%23v=onepage&q=hash&f=false#v=onepage&q&f=false | dataarchivio = 10 luglio 2019 | urlmorto = no }}</ref>

L{{'}}''indice'' è uno strato intermedio che serve da punto di collegamento fra il database di oggetti e l'albero di lavoro.

Il database ha una struttura semplice. L'oggetto viene messo in una directory che corrisponde ai primi due caratteri del suo codice hash; Il resto del codice costituisce il nome del file che contiene tale oggetto. Quando si aggiunge un nuovo oggetto, questo viene memorizzato per intero dopo averlo compresso con [[zlib]].

Riga 147 ⟶ 145:

== Progetti correlati ==

=== Progetti che si basano su Git ===

* [http://repo.or.cz/w/''git-gui.git git-gui]'' è una GUI basata su Tk per le operazioni più comuni di Git. Questo progetto è incorporato in Git versione 1.5.0 e successive. (Si lancia con il comando "git gui").

* ''[[Cogito (software)|Cogito]] ([https://www.kernel.org/pub/software/scm/cogito/ homepage])'' - Petr Baudiš ha mantenuto un insieme di script chiamato Cogito (precedentemente git-pasky), che formano un sistema di controllo versione che usa Git come backend<ref>[https://www.kernel.org/pub/software/scm/cogito/ homepage]</ref>. Lo sviluppo di Cogito è stato interrotto nell'aprile 2007 quando la sua funzionalità è stata ritenuta ridondante con gli strumenti di frontend di Git, comunemente chiamati "porcellana" ("porcelain").

* ''[[StGIT]] ([http://www.procode.org/stgit/ homepage])'' - Stacked GIT è un'applicazione [[Python]] che fornisce funzionalità simili a Quilt (<ref>[https://savannah.nongnu.org/projects/quilt/ homepage])</ref> (cioè aggiungere/togliere patch a/da uno stack) appoggiandosi a Git, per gestire le patch fino a quando vengono fuse<ref>[https://web.archive.org/web/20070929101333/http://www.procode.org/stgit/ homepage]</ref>.

* [https://web.archive.org/web/20070928034916/http://www.spearce.org/category/projects/scm/pg/ pg (''Patchy GIT)]'' è un'interfaccia a Git costituita da script di shell per aiutare l'utente a gestire un insieme di patch ai file. pg è in un certo senso simile a Quilt o a StGIT, ma ha un insieme di caratteristiche leggermente diverso. pg non viene più mantenuto dal 29 aprile, 2007

* ''DarcsGit'' - un'estensione di [[Darcs]] che gli consente di interagire con i repositori Git<ref>{{Cita web |url=http://wiki.darcs.net/DarcsWiki/DarcsGit DarcsGit]|titolo=Copia archiviata {{Webarchive|urlaccesso=29 settembre 2007 |dataarchivio=29 settembre 2007 |urlarchivio=https://web.archive.org/web/20070929093501/http://wiki.darcs.net/DarcsWiki/DarcsGit |dateurlmorto=29 settembre 2007sì }} è un'estensione di [[Darcs]] che gli consente di interagire con i repositori Git</ref>.

* [https://launchpad.net/products/''bzr-git'' bzr-git] è un plugin per [[Bazaar (software)|Bazaar]] per leggere gli alberi di Git<ref>[https://launchpad.net/products/bzr-git bzr-git]</ref>. Sebbene sia ancora in fase alpha, fornisce abbastanza supporto per [https://www.webcitation.org/66UOgZ4UX?url=http://wiki.bazaar.canonical.com/ForeignBranches/Git?action=show la visualizazione bzrk].

=== Interfacce Web ===

* [https://gogs.io/ ''Gogs]'': Un frontend git con gestione degli utenti, delle segnalazioni, dei fork e molte altre funzionalità, scritto in [[Go_(linguaggio_di_programmazione)|go]]<ref>[https://gogs.io/ Gogs]</ref>.

* [https://gitea.io ''Gitea]'': Un fork comunitario di Gogs<ref>[https://gitea.io Gitea]</ref>.

* ''gitweb'' – un'implementazione in [[Perl]] mantenuta da Kay Sievers<ref>{{collegamento interrotto|1=[https://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=log gitweb] |datedata=marzo 2018 |bot=InternetArchiveBot }} – un'implementazione in [[Perl]] mantenuta da Kay Sievers</ref>. Usata dal sito kernel.org

* ''wit'' – un'implementazione [[Python]] mantenuta da Christian Meder<ref>[http://www.grmso.net:8090/ wit] {{Webarchive|url=https://web.archive.org/web/20080119122646/http://grmso.net:8090/ |datedata=19 gennaio 2008 }} – un'implementazione [[Python]] mantenuta da Christian Meder</ref>.

* [https://www.flameeyes.eu/projects/#''gitarella gitarella]'' – un'implementazione [[Ruby (linguaggio di programmazione)|Ruby]] mantenuta da Diego Elio Pettenò<ref>[https://www.flameeyes.eu/projects/#gitarella gitarella]</ref>

* ''git-php'' – un'implementazione [[PHP]] di Zack Bartel<ref>[https://code.google.com/p/git-php/ git-php] – un'implementazione [[PHP]] di Zack Bartel</ref>

* [https://web.archive.org/web/20071218144652/http://hjemli.net/git/ ''cgit]'' - un'implementazione [[C (linguaggio di programmazione)|C]] di Lars Hjemli<ref>[https://web.archive.org/web/20071218144652/http://hjemli.net/git/ cgit]</ref>

* ''[[Bitbucket]]'' usa i sistemi di controllo versione Git dall'ottobre 2011.

=== Visualizzazione della cronologia ===

* [https://web.archive.org/web/20070927232025/http://ozlabs.org/~paulus/gitk/ ''Gitk]'' è una semplice GUI [[Tcl/Tk]] per consultare facilmente la cronologia dei repository Git, distribuita con Git<ref>[https://web.archive.org/web/20070927232025/http://ozlabs.org/~paulus/gitk/ Gitk]</ref>.

* [http://digilander.libero.it/mcostalba/ ''QGit] (SourceForge [https://sourceforge.net/projects/qgit project page])'' è una GUI [[Qt (toolkit)|Qt]] per consultare la cronologia dei repository, simile a Gitk<ref>[https://web.archive.org/web/20071118015253/http://digilander.libero.it/mcostalba/ QGit]</ref>.

* ''Giggle'' è una GUI [[GTK+]] ispirata da Gitk<ref>[https://web.archive.org/web/20071209104517/http://developer.imendio.com/projects/giggle Giggle] è una GUI [[GTK+]] ispirata da Gitk</ref>.

* {{collegamento interrotto|1=[https://git.kernel.org/?p=git/git.git;a=tree;f=contrib/''gitview gitview] |date=marzo 2018 |bot=InternetArchiveBot }}'' è una GUI [[Python]] e Gtk+, distribuita con Git.

* [http://jonas.nitro.dk/''tig/ tig]'' è un'interfaccia testuale a pieno schermo basata su [[ncurses]] per Git".

* ''git-browser'' è un programma di consultazione della cronologia scritto in [[JavaScript]] che è utilizzabile in un browser web. (Pare che non consenta di esaminare le modifiche al codice, ma solo le descrizioni.)

== Note ==