diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown index 109d3da24..6af897f8a 100644 --- a/it/01-introduction/01-chapter1.markdown +++ b/it/01-introduction/01-chapter1.markdown @@ -10,33 +10,33 @@ Se sei un grafico o un webdesigner e vuoi tenere tutte le versioni di un'immagin ### Sistema di Controllo di Versione locale ### -Alcuni metodi di controllo di versione scelti da alcune persone è di copiare i file in un'altra directory (magari una directory nominata con la data, se sono intelligenti). Questo approccio è molto comune perché è molto semplice, ma è anche incredibilmente soggetto ad errori. E' facile dimenticare in quale directory ci si trova e accidentalmente scrivere sul file sbagliato o copiare i file che non si intendevano copiare. +Un metodo di controllo di versione scelto da molte persone è di copiare i file in un'altra directory (magari una directory nominata con la data, se sono intelligenti). Questo approccio è molto comune perché è semplice, ma è anche incredibilmente soggetto ad errori. E' facile dimenticare in quale directory ci si trova e accidentalmente scrivere sul file sbagliato o copiare i file che non si intendevano copiare. -Per far fronte a questo problema, i programmatori molto tempo fa svilupparono VCS locali che avevano un semplice database che manteneva tutti i cambiamenti dei file sotto controllo di revisione (vedi Figura 1-1). +Per far fronte a questo problema, i programmatori svilupparono VCS locali che avevano un semplice database che manteneva tutti i cambiamenti dei file sotto controllo di revisione (vedi Figura 1-1). Insert 18333fig0101.png Figure 1-1. Diagramma di controllo di versione locale. -Uno dei più popolari strumenti VCS era un sistema chiamato rcs, che è ancora oggi distribuito con alcuni computer. Anche il popolare sistema operativo Mac OS X include il comando rcs quando si installano i Strumenti di Sviluppo. Semplicemente questo strumento funziona mantenendo una serie di patch (che sono le differenze fra i file) da un cambiamento ad un altro in un formato specifico sul disco; esso può poi ricreate qualsiasi file come se fosse quel file in un determinato momento aggiungendo tutte le patch. +Uno dei più popolari strumenti VCS era un sistema chiamato rcs, che è ancora oggi distribuito con alcuni computer. Anche il popolare sistema operativo Mac OS X include il comando rcs quando si installano gli Strumenti di Sviluppo. Semplicemente questo strumento funziona mantenendo una serie di patch (che sono le differenze fra i file) da un cambiamento ad un altro in un formato specifico sul disco; esso può poi ricreare qualsiasi file come se fosse quel file in un determinato momento aggiungendo tutte le patch. ### Sistemi di Controllo di Versione Centralizzati ### -Il successivo maggior problema in cui incorrono le persone è che queste hanno bisogno di collaborare con gli sviluppatori su altri sistemi. Per far pronte a questo problema,sistemi di controllo di versione centralizzati (Centralized Version Control Systems, CVCS) furono sviluppati. Questi sistemi, come CVS, Subversion e Perforce, hanno un singolo server che contiene tutte le versioni dei file e un numero di clienti che controllano i file dalla centrale. Per alcuni anni, questo fu lo standard per il controllo di versione (vedi Figura 1-2). +Il problema successivo in cui incorsero le persone è che queste hanno bisogno di collaborare con altri sviluppatori su altri sistemi. Per far fronte a questo problema, vennero sviluppati sistemi di controllo di versione centralizzati (Centralized Version Control Systems, CVCS). Questi sistemi, come CVS, Subversion e Perforce, hanno un singolo server che contiene tutte le versioni dei file e un numero di utenti che controllano i file dalla centrale. Per alcuni anni, questo fu lo standard per il controllo di versione (vedi Figura 1-2). Insert 18333fig0102.png Figure 1-2. Diagramma controllo di versione centralizzato. -Questo sistema offre alcuni vantaggi, specialmente sopra al VCS locale. Per esempio, chiunque sa ad un certo livello cosa fa qualsiasi altra persona nel progetto. Gli amministratori hanno un fine o grossolano controllo su cosa chi può fare cosa; ed è molto più facile amministrare un tale CVCS che un database locale su ogni client. +Questo sistema offre alcuni vantaggi, specialmente rispetto al VCS locale. Per esempio, chiunque può sapere, fino ad un certo punto, cosa fa qualsiasi altra persona nel progetto. Gli amministratori possono controllare, attraverso una configurazione, chi può fare cosa; ed è molto più facile amministrare un CVCS che un database locale per ogni client. -Tuttavia, questa configurazione ha alcuni lati negativi gravi. La più ovvia è il singolo punto di errore che il server centralizzato rappresenta. Se questo server va giù per un'ora, durante questo periodo nessuno può collaborare o salvare le modifiche di versione di qualsiasi cosa su cui sta lavorando. Se il disco rigido del database centrale è danneggiato, e copie di backup non sono state mantenute, si perde proprio tutta la storia del progetto, ad eccezione di singoli snapshot (istantanee) fatte dalle persone sulla propria macchina locale. Sistemi locali di VCS soffrono di questo stesso problema-ogni volta che si ha tutta la storia del progetto in un unico posto, si rischia di perdere. +Tuttavia, questa configurazione ha alcuni gravi lati negativi. La più ovvia è il singolo punto di cedimento che il server centralizzato rappresenta. Se questo va giù per un'ora, durante questo periodo nessuno può collaborare o salvare le modifiche di versione di qualsiasi cosa su cui sta lavorando. Se il disco rigido del database centrale si danneggia, e non sono state effettuate copie di backup, si perde tutta la storia del progetto, ad eccezione di singoli snapshot (istantanee) fatte dalle persone sulla loro macchina locale. Anche i sistemi locali di VCS soffrono di questo problema-ogni volta che si ha tutta la storia del progetto in un unico posto, si rischia di perdere tutto. ### Sistemi di Controllo di Versione Distribuiti ### -Qui è dove parlo dei Sistemi di Controllo di Versione Distribuiti (Distributed Version Control Systems, DVCS). In un DVCS (come Git, Mercurial, Bazaar o Darcs), i client non solo possono avere tutti gli ultimi snapshot dei file: essi possono fare la copia completa del repository. Così, se un qualsiasi server muore, e questi sistemi collaborando tramite esso, qualsiasi repository di un client può essere copiato sul server per ripristinarlo. Ogni archivio è in realtà un backup completo di tutti i dati (vedi Figura 1-3). +Qui è dove entrano in gioco Sistemi di Controllo di Versione Distribuiti (Distributed Version Control Systems, DVCS). In un DVCS (come Git, Mercurial, Bazaar o Darcs), i client non solo possono avere tutti gli ultimi snapshot dei file: essi sono la copia completa del repository. Così, se un qualsiasi server muore, e questi sistemi collaborando tramite esso, qualsiasi repository di un client può essere copiato sul server per ripristinarlo. Ogni archivio è in realtà un backup completo di tutti i dati (vedi Figura 1-3). Insert 18333fig0103.png Figure 1-3. Diagramma controllo di versione distribuito. -Inoltre, molti di questi sistemi trattano abbastanza bene molti repository remoti su cui si può lavorare, così si può collaborare con gruppi differenti di persone in modi differenti simultaneamente sullo stesso progetto. Questo ti permette di impostare diversi tipi di flussi di lavoro che non sono possibili in sistemi centralizzati, come i modelli gerarchici. +Inoltre, molti di questi sistemi trattano abbastanza bene l'avere più repository remoti su cui poter lavorare, così si può collaborare con gruppi differenti di persone in modi differenti simultaneamente sullo stesso progetto. Questo ti permette di impostare diversi tipi di flussi di lavoro che non sono possibili in sistemi centralizzati, come i modelli gerarchici. ## Una breve storia di Git ## @@ -51,20 +51,20 @@ Nel 2005, il rapporto tra la comunità che ha sviluppato il kernel Linux e la so * Completamente distribuito * Capace di gestire progetti grandi come il kernel Linux in modo efficiente (velocità e dimensione dei dati) -Fin dalla sua nascita nel 2005, Git si è evoluto e maturo per essere facile da usare e ancora mantiene queste qualità. E' incredibilmente veloce, è molto efficiente con grandi progetti, ed ha un incredibile sistema di branching (rami) per lo sviluppo non lineare (Vedi Capitolo 3). +Fin dalla sua nascita nel 2005, Git si è evoluto ed è maturato per essere facile da usare mantenendo queste qualità iniziali. E' incredibilmente veloce, è molto efficiente con grandi progetti, ed ha un incredibile sistema di branching (rami) per lo sviluppo non lineare (Vedi Capitolo 3). ## Basi di Git ## -Quindi, cos'è Git in poche parole? Questa è una sezione importante da assorbire, perché se si capisce che cosa è Git e gli elementi fondamentali di come funziona, quindi usare Git efficacemente sarà probabilmente molto più facile per te. Come si impara Git, cercare di liberare la mente delle cose che si possono conoscere altri VCS, come Subversion e Perforce; così facendo ti aiuterai ad evitare confusione quando si utilizza lo strumento. Git immagazzina e pensa alle informazioni in modo diverso da altri sistemi, anche se l'interfaccia utente è abbastanza simile; capire queste differenze aiuterà a prevenire confusione mentre lo si userà. +Quindi, cos'è Git in poche parole? Questa è una sezione importante da assorbire, perché se si capisce che cos'è Git e gli elementi fondamentali di come funziona, usare Git efficacemente sarà probabilmente molto più facile per te. Mentre si impara Git, cercare di liberare la mente delle cose che si possono conoscere altri VCS, come Subversion e Perforce; così facendo ti aiuterai ad evitare confusione quando si utilizza lo strumento. Git immagazzina e pensa alle informazioni in modo diverso da altri sistemi, anche se l'interfaccia utente è abbastanza simile; capire queste differenze aiuterà a prevenire confusione mentre lo si userà. ### Snapshot, No Differenze ### -La maggiore differenza tra Git e gli altri VCS (Subversion e amici inclusi) è il modo in cui Git pensa ai dati. Concettualmente, la maggior parte degli altri sistemi salvano le informazioni come una lista di file basati sui cambiamenti. Questi sistemi (CVS,Subversion, Perforce, Bazaar e così via) pensano alle informazioni da mantenere come una serie di file e modifiche fatte ad ogni file nel tempo, come illustrato in Figura 1-4. +La maggiore differenza tra Git e gli altri VCS (Subversion e amici inclusi) è il modo in cui Git pensa ai dati. Concettualmente, la maggior parte degli altri sistemi salvano le informazioni come una lista di file basati sui cambiamenti. Questi sistemi (CVS, Subversion, Perforce, Bazaar e così via) pensano alle informazioni da mantenere come una serie di file e modifiche fatte ad ogni file nel tempo, come illustrato in Figura 1-4. Insert 18333fig0104.png Figure 1-4. Altri sistemi tendono ad immagazzinare i dati come cambiamenti alla versione base di ogni file. -Git non pensa ad immagazzinare i dati in questo modo. Invece, Git pensa ai dati più come una serie di istantanee (snapshot) di un mini filesystem. Ogni volta che si fa un commit, o si salva lo stato del proprio progetto in Git, esso fondamentalmente fa un'immagine di tutti i tuoi file di quel momento e salva una referenza nello snapshot. Per essere efficiente, se i file non sono cambiati, Git non immagazzina i file nuovamente-semplicemente li collega alla versione precedente dell'identico file che è stata già salvata. Git pensa ai dati più come in Figura 1-5. +Git non pensa ad immagazzinare i dati in questo modo. Invece, Git pensa ai dati più come una serie di istantanee (snapshot) di un mini filesystem. Ogni volta che si fa un commit, o si salva lo stato del proprio progetto in Git, fondamentalmente fa un'immagine di tutti i tuoi file di quel momento e salva una referenza nello snapshot. Per essere efficiente, se i file non sono cambiati, Git non immagazzina i file nuovamente-semplicemente li collega alla versione precedente dell'identico file che è stata già salvata. Git pensa ai dati più come in Figura 1-5. Insert 18333fig0105.png Figure 1-5. Git immagazzina i dati come snapshot del progetto nel tempo. @@ -75,10 +75,9 @@ Questa è una distinzione importante tra Git e gli altri VCS. Git riconsidera tu La maggior parte delle operazioni in Git necessitano solo di file e risorse locali per operare — generalmente nessuna informazione è necessaria da un altro computer sulla propria rete. Se sei abituato ad un CVCS in cui la maggior parte delle operazioni sono soggette al tempo di latenza della rete, questo aspetto di Git vi farà pensare che gli dei della velocità hanno benedetto Git con poteri soprannaturali. Perché hai l'intera storia del progetto li, sul disco locale, la maggior parte delle operazioni sembrano quasi istantanee. -Per esempio, per vedere la storia di un progetto, Git non ha bisogno di connettersi ad un server per avere la storia e poi visualizzarla—semplicemente legge direttamente dal database locale. Questo significa che puoi vedere la storia del progetto quasi istantaneamente. Se vuoi vedere i cambiamenti introdotti tra la versione corrente di un file e la versione di un mese fa, Git può consultare il file di un mese fa e fare il calcolo delle differenze, invece di dover domandare ad un server remoto di fare questo o tirare fuori una versione vecchia del file dal server remoto per farlo in locale. +Per esempio, per vedere la storia di un progetto, Git non ha bisogno di connettersi ad un server per averla e poi visualizzarla—semplicemente legge direttamente dal database locale. Questo significa che puoi vedere la storia del progetto quasi istantaneamente. Se vuoi vedere i cambiamenti introdotti tra la versione corrente di un file e la versione di un mese fa, Git può consultare il file di un mese fa e fare il calcolo delle differenze, invece di dover domandare ad un server remoto di fare questo o tirare fuori una versione vecchia del file dal server remoto per farlo in locale. -Questo significa anche che ci sono poche cose che non puoi fare se sei -offline o non connesso alla VPN. Se sei su un aereo plano o sul treno e vuoi fare un po' di lavoro, puoi eseguire il commit felicemente fin quando non sei connesso ad una rete per fare l'upload. Se sei a casa e il tuo client VPN non funziona correttamente, puoi comunque lavorare. In qualsiasi altro sistema, fare questo è impossibile o penoso. Nelle performance, per esempio, non puoi fare molto quando non c'è una connessione al server; e in Subversion e CVS, puoi modificare i file, ma non puoi inviare i cambiamenti al database (perché il tuo database è offline). Questo può non sembrare un grande vantaggio, ma sarai sorpreso di che grande differenza possa fare. +Questo significa anche che ci sono poche cose che non puoi fare se sei offline o non connesso alla VPN. Se sei su un aereoplano o sul treno e vuoi lavorare un po', puoi eseguire il commit felicemente fin quando non sei connesso ad una rete per fare l'upload. Se sei a casa e il tuo client VPN non funziona correttamente, puoi comunque lavorare. In qualsiasi altro sistema, fare questo è impossibile o penoso. Nelle performance, per esempio, non puoi fare molto quando non c'è una connessione al server; e in Subversion e CVS, puoi modificare i file, ma non puoi inviare i cambiamenti al database (perché il tuo database è offline). Questo può non sembrare un grande vantaggio, ma sarai sorpreso di che grande differenza possa fare. ### Git Mantiene l'Integrità ### @@ -107,15 +106,15 @@ Figure 1-6. Directory di lavoro, area di staging e directory git. La directory Git è dove Git salva i metadati ed il database degli oggetti del tuo progetto. Questa è la parte più importante di Git ed è quella che viene copiata quando cloni un repository da un altro computer. -La directory di lavoro è un semplice posto di una versione del progetto. Questi file sono tirati fuori dal database compresso nella directory Git e messi sul disco per te per essere usati o modificati. +La directory di lavoro è un semplice checkout di una versione del progetto. Questi file sono tirati fuori dal database compresso nella directory Git e messi sul disco per te per essere usati o modificati. L'area di staging è un semplice file, generalmente contenuta nella tua directory Git, che salva le informazioni su cosa andrà nel prossimo commit. Può essere consultata come un indice, ma sta diventando uno standard riferirsi ad essa come l'area di sosta. Il flusso base di lavoro di Git sarà qualcosa di simile a: 1. Modifichi i file nella directory di lavoro. -2. Fai lo staging dei file, aggiungi snapshot di questi nella tua area di sosta. -3. Esegui un commit, che prenderà i file come son nell'area di sosta e salverà questi snapshot permanentemente nella tua directory Git. +2. Fai lo staging dei file, aggiungi gli snapshot di questi nella tua area di sosta. +3. Esegui un commit, che prenderà i file come sono nell'area di sosta e salverà questi snapshot permanentemente nella tua directory Git. Se una versione particolare di un file è nella directory git, sarà considerata committed (già affidata/inviata). Se il file è stato modificato ma è stato aggiunta all'area di staging, è in sosta. E se è stato modificato da quando è stata controllato ma non è stato messo in sosta, sarà modificato. Nel Capitolo 2, imparerai di più su questi stati e come trarne vantaggio da essi o saltare interamente la parte di staging. @@ -125,9 +124,9 @@ Ora entriamo nell'uso di Git. Per prima cosa—lo devi installare. Lo puoi otten ### Installazione da Sorgenti ### -Se puoi, è generalmente utile installare Git dai sorgenti, perchè puoi avere la versione più recente. Ogni versione di Git tende ad includere miglioramenti utili all'UI, così questo è il modo migliore per ottenere l'ultima versione se si ha famigliarità con la comlilazione. E' anche vero che molte distribuzioni Linux contengono pacchetti molto vecchi, così se sei su una distro molto datata e stai usando dei backports, l'installazione da sorgente può essere la scommessa migliore. +Se puoi, è generalmente utile installare Git dai sorgenti, perchè puoi avere la versione più recente. Ogni versione di Git tende ad includere miglioramenti utili all'UI, così questo è il modo migliore per ottenere l'ultima versione se si ha familiarità con la compilazione. E' anche vero che molte distribuzioni Linux contengono pacchetti molto vecchi, così se sei su una distro molto datata e stai usando dei backports, l'installazione da sorgente può essere la cosa migliore da fare. -Per installare Git, hai bisogno delle seguenti librerie a cui Git dipende: curl, lib, openssl, expat e libiconv. Per esempio, se sei su un sistema che usa yum (come Fedora) o apt-get (come un sistema basato su Debian), puoi usare uno dei seguenti comandi per installare tutti i pacchetti di dipendenza: +Per installare Git, hai bisogno delle seguenti librerie da cui Git dipende: curl, lib, openssl, expat e libiconv. Per esempio, se sei su un sistema che usa yum (come Fedora) o apt-get (come un sistema basato su Debian), puoi usare uno dei seguenti comandi per installare tutti i pacchetti di dipendenza: $ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel @@ -177,17 +176,17 @@ Non hai bisogno di aggiungere altri pacchetti aggiuntivi, ma probabilmente vorra ### Installazione su Windows ### -Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle procedure di installazione più facili. Semplicemente scarica l'installatore exe dalla pagina di Google Code, e lancialo: +Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle procedure di installazione tra le più facili. Semplicemente scarica l'installatore exe dalla pagina di Google Code, e lancialo: http://code.google.com/p/msysgit -Dopo che è stato installato, hai a disposizione sia la versione da riga di comando (incluso un client SSH che sarà utile in seguito) ed una GUI standard. +Dopo che è stato installato, hai a disposizione sia la versione da riga di comando (incluso un client SSH che sarà utile in seguito) sia una GUI standard. ## Prima configurazione di Git ## -Ora che hai Git sul tuo sistema, vorrai un po' di cose per configura Git. Le dovrai fare solo una volta; rimarranno tali anche dopo gli aggiornamenti. Puoi comunque cambiarli in ogni momento avviando gli stessi comandi nuovamente. +Ora che hai Git sul tuo sistema, vorrai fare un po' di cose per configurare il tuo ambiente Git. Le dovrai fare solo una volta; rimarranno tali anche dopo gli aggiornamenti. Puoi comunque cambiarle in ogni momento avviando gli stessi comandi nuovamente. -Git è rilasciato con uno strumenti che si chiama git config che ti permetterà di ottenere ed impostare le variabili di configurazione che controllano ogni aspetto delle operazioni e del look di Git. Queste variabili possono essere salvate in tre posti differenti: +Git è rilasciato con uno strumento che si chiama git config che ti permetterà di ottenere ed impostare le variabili di configurazione che controllano ogni aspetto delle operazioni e del look di Git. Queste variabili possono essere salvate in tre posti differenti: * file `/etc/gitconfig`: Contiene i valori per ogni utente sul sistema e per tutti i loro repository. Se si passa l'opzione` --system` a `git config`, lui legge e scrive da questo specifico file. * file `~/.gitconfig`: Specifico per il tuo utente. Puoi far leggere e scrivere a Git questo file passando l'opzione `--global`. @@ -197,7 +196,7 @@ Sui sistemi Windows, Git cerca il file `.gitconfig` nella directory `$HOME` (`C: ### La tua identità ### -La prima cosa che dovresti fare quando installi Git è di impostare il tuo nome utente e l'indirizzo e-mail. Questo è importante perché ogni commit con Git usa queste informazioni, ed è immutabilmente infornato nei commit che si fanno girare: +La prima cosa che dovresti fare quando installi Git è di impostare il tuo nome utente e l'indirizzo e-mail. Questo è importante perché ad ogni commit Git usa queste informazioni, ed è immutabilmente impresso nei commit che si fanno girare: $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com @@ -240,7 +239,7 @@ Puoi inoltre controllare cosa Git pensa a proposito del valore di una singola ch ## Ottenere Aiuto ## -Se dovessi avere aiuto durante l'uso di Git, ci sono tre modi per vedere le pagine del manuale (manpage) di aiuto per ogni comando di Git: +Se dovessi avere bisogno di aiuto durante l'uso di Git, ci sono tre modi per vedere le pagine del manuale (manpage) di aiuto per ogni comando di Git: $ git help $ git --help @@ -255,4 +254,4 @@ Se il manpage e questo libro non sono sufficienti e hai bisogno di un aiuto più ## Riassumento ## -Dovresti avere le basi per capire cosa è Git e come è differente dai CVCS che puoi aver usato. Dovresti anche avere una versione funzionante di Git sul tuo sistema che è configurata con la tua personale identità. E' ora tempo di imparare qualcosa di base di Git. +Dovresti avere le basi per capire cos'è Git e come è differente dai CVCS che puoi aver usato. Dovresti anche avere una versione funzionante di Git sul tuo sistema che è configurata con la tua personale identità. E' ora tempo di imparare qualcosa di base di Git.