Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

[it] Chapters 1-4: Apply uniform style of translation. Minor corrections. Update the translation. #406

Merged
merged 1 commit into from

2 participants

Jean-Noël Avila Zorgatone
Deleted user

I have corrected every title that did not follow the style of the original text and updated the translation in some sections that were behind the original text. Also, I have corrected some errors and made uniform the translation.

Gabriele Tomassetti [it] Chapters 1-4: Apply uniform style of translation. Minor correcti…
…ons. Update the translation.
32af1ec
Jean-Noël Avila jnavila commented on the diff
it/01-introduction/01-chapter1.markdown
@@ -1,16 +1,16 @@
-# Per iniziare #
+# Per Iniziare #
Jean-Noël Avila Collaborator
jnavila added a note

The words are capitalized in the original text because this is standard typography in american english. Is it standard practice in Italian to capitalize every words in a title?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Deleted user

Surprisingly the answer it's not so simple. Traditionally it isn't, for example you don't see it in novels, but you can see it in computer science books. As for the paragraph breaks, in Italian usually they would be indentented, but many people are simply starting to use paragraph blocks for uniformity's sake.
In short: if this was a book to be printed I would probably use the traditional way, since the italian translation it's only used online I would use it this way for uniformity's sake.

Jean-Noël Avila jnavila merged commit 406fa01 into from
Zorgatone

Bravo, i titoli con le iniziali in maiuscolo su ogni sostantivo sono fondamentali! :+1:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Apr 10, 2013
  1. [it] Chapters 1-4: Apply uniform style of translation. Minor correcti…

    Gabriele Tomassetti authored
    …ons. Update the translation.
This page is out of date. Refresh to see the latest.
92 it/01-introduction/01-chapter1.markdown
View
@@ -1,16 +1,16 @@
-# Per iniziare #
+# Per Iniziare #
Jean-Noël Avila Collaborator
jnavila added a note

The words are capitalized in the original text because this is standard typography in american english. Is it standard practice in Italian to capitalize every words in a title?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
-Questo capitolo spiegherà come iniziare ad usare Git. Inizieremo con una introduzione sugli strumenti di controllo della versione, per poi passare a come far funzionare Git sul proprio sistema ed infine come configurarlo per lavorarci. Alla fine di questo capitolo, si dovrebbe capire a cosa serve Git, perché lo si dovrebbe usare ed essere pronti per usarlo.
+Questo capitolo spiegherà come iniziare ad usare Git. Inizieremo con una introduzione sugli strumenti di controllo della versione, per poi passare a come far funzionare Git sul proprio sistema ed infine come configurarlo per lavorarci. Alla fine di questo capitolo, dovresti capire a cosa serve Git, perché lo dovresti usare ed essere pronto ad usarlo.
## Il Controllo di Versione ##
-Cos'è il controllo di versione, e perché si dovrebbe usare? Il controllo di versione è un sistema che registra i cambiamenti ad un file o ad una serie di file nel tempo, così da poter richiamare una versione specifica successivamente. Per gli esempi in questo libro, useremo i file del codice sorgente di un software per controllarne la versione, anche se in realtà si può fare con quasi ogni tipo di file sul computer.
+Cos'è il controllo di versione, e perché dovresti usarlo? Il controllo di versione è un sistema che registra i cambiamenti ad un file o ad una serie di file nel tempo, così da poter richiamare una versione specifica successivamente. Per gli esempi in questo libro, useremo i file del codice sorgente di un software per controllarne la versione, anche se in realtà si può fare con quasi ogni tipo di file sul computer.
Se sei un grafico o un webdesigner e vuoi tenere tutte le versioni di un'immagine o di un layout (e sicuramente lo vorrai fare), un Version Control System (VCS) è una cosa saggia da usare. Ti permette di ripristinare i file ad uno stato precedente, ripristinare l'intero progetto ad uno stato precedente, comparare i cambiamenti nel tempo, vedere chi ha modificato cosa che può aver causato un problema, chi ha introdotto un problema e quando, e altro ancora. Usare un VCS, in generale, significa che se si fanno dei pasticci o si perdono dei file, si possono facilmente ripristinare. In aggiunta, si ottiene tutto questo con un piccolo dispendio di risorse.
-### Sistema di Controllo di Versione locale ###
+### Sistema di Controllo di Versione Locale ###
-Il metodo di controllo di versione scelto da molte persone è di copiare i file in un'altra directory (magari una directory denominata con la data, se sono furbi). Questo approccio è molto comune perché è molto semplice, ma è anche incredibilmente soggetto ad errori. E' facile dimenticarsi la directory in cui ci si trova e accidentalmente scrivere sul file sbagliato o copiare i file che non si intendevano copiare.
+Il metodo di controllo di versione scelto da molte persone è di copiare i file in un'altra directory (magari una directory denominata con la data, se sono furbi). Questo approccio è molto comune perché è molto semplice, ma è anche incredibilmente soggetto ad errori. É facile dimenticarsi la directory in cui 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 svilupparono VCS locali che avevano un semplice database che manteneva tutti i cambiamenti dei file sotto controllo di revisione (vedi Figura 1-1).
@@ -28,7 +28,7 @@ Figura 1-2. Diagramma controllo di versione centralizzato.
Questa impostazione offre molti vantaggi, specialmente rispetto ai VCS locali. Per esempio, chiunque sa, ad un certo livello, cosa stia facendo un'altra persona nel progetto. Gli amministratori hanno un controllo preciso su chi può fare cosa; ed è molto più facile amministrare un tale CVCS che un database locale su ogni client.
-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.
+Tuttavia, questa configurazione ha alcuni gravi lati negativi. La più ovvia è il singolo punto di fallimento 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, perdi assolutamente tutto - 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 ###
@@ -37,9 +37,9 @@ E qui entrano in gioco i Sistemi di Controllo di Versione Distribuiti (Distribut
Insert 18333fig0103.png
Figura 1-3. Diagramma controllo di versione distribuito.
-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.
+Inoltre, molti di questi sistemi trattano bene l'avere più repository remoti su cui poter lavorare, così puoi 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 ##
+## Una Breve Storia di Git ##
Come per molte grandi cose nella vita, Git è iniziato con un po' di distruzione creativa e polemiche di fuoco. Il kernel di Linux è un progetto software open source di portata abbastanza ampia. Per la manutenzione del kernel Linux, per diverso tempo (1991-2002), le modifiche al software venivano passate sotto forma di patch e file d'archivio. Nel 2002, il progetto del kernel di Linux iniziò ad utilizzare un sistema proprietario chiamato DVCS BitKeeper.
@@ -51,13 +51,13 @@ Nel 2005, il rapporto tra la comunità che ha sviluppato il kernel Linux e la so
* Completamente distribuito
* Capacità di gestire, in modo efficiente (velocità e dimensione dei dati), grandi progetti come il kernel Linux
-Fin dalla sua nascita nel 2005, Git si è evoluto e maturato per essere facile da usare e tuttora mantiene le sue 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).
+Fin dalla sua nascita nel 2005, Git si è evoluto e maturato per essere facile da usare e tuttora mantiene le sue qualità iniziali. E' incredibilmente veloce, è molto efficiente con grandi progetti, ed ha un incredibile sistema di ramificazioni, 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 comprende che cosa è Git e gli elementi fondamentali di come funziona, allora probabilmente, sarà molto più facile per te usare Git efficacemente. Mentre impari Git, cerca di liberare la mente dalle cose che eventualmente conosci su altri VCS, come Subversion e Perforce; ciò ti aiuterà ad evitare di far confusione utilizzando lo strumento. Git immagazzina e tratta le informazioni in modo diverso dagli altri sistemi, anche se l'interfaccia utente è abbastanza simile; comprendere queste differenze aiuta a prevenire di sentirsi confusi, mentre lo si usa.
+Quindi, cos'è Git in poche parole? Questa è una sezione importante da assorbire, perché se comprendi che cosa è Git e gli elementi fondamentali di come funziona, allora probabilmente, sarà molto più facile per te usare Git efficacemente. Mentre impari Git, cerca di liberare la mente dalle cose che eventualmente conosci su altri VCS, come Subversion e Perforce; ciò ti aiuterà ad evitare di far confusione utilizzando lo strumento. Git immagazzina e tratta le informazioni in modo diverso dagli altri sistemi, anche se l'interfaccia utente è abbastanza simile; comprendere queste differenze aiuta a prevenire di sentirsi confusi, mentre lo si usa.
-### Snapshot, non Differenze ###
+### Istantanee, non Differenze ###
La principale differenza tra Git e gli altri VCS (Subversion e compagnia), è il modo in cui Git considera i suoi dati. Concettualmente, la maggior parte degli altri sistemi salvano l'informazione come una lista di cambiamenti apportati ai file. Questi sistemi (CVS, Subversion, Perforce, Bazaar e così via), considerano le informazioni che essi mantengono come un insieme di file, con le relative modifiche fatte ai file, nel tempo, come illustrato in Figura 1-4.
@@ -69,35 +69,35 @@ Git non considera i dati in questo modo né li immagazzina in questo modo. Invec
Insert 18333fig0105.png
Figura 1-5. Git immagazzina i dati come snapshot del progetto nel tempo.
-Questa è una distinzione importante tra Git e gli altri VCS. Git riconsidera tutti gli aspetti del controllo di versione mentre la maggior parte degli altri sistemi copiano dalle precedenti generazioni. Questo fa di Git più un qualche cosa di simile ad un mini filesystem con alcuni incredibili e potenti strumenti costruiti su di esso, invece che un semplice VCS. Esploreremo alcuni benefici che potrai avere immaginando i tuoi dati in questo modo quando vedremo il branching (le ramificazioni) con Git nel Capitolo 3.
+Questa è una distinzione importante tra Git e gli altri VCS. Git riconsidera tutti gli aspetti del controllo di versione mentre la maggior parte degli altri sistemi copiano dalle precedenti generazioni. Questo fa di Git più un qualche cosa di simile ad un mini filesystem con alcuni incredibili e potenti strumenti costruiti su di esso, invece che un semplice VCS. Esploreremo alcuni benefici che potrai avere immaginando i tuoi dati in questo modo quando vedremo le ramificazioni con Git nel Capitolo 3.
-### Quasi tutte le operazioni sono locali ###
+### Quasi Tutte le Operazioni Sono Locali ###
-La maggior parte delle operazioni in Git, necessitano solo di file e risorse locali per operare — generalmente non occorrono informazioni da altri computer nella rete. Se si era abituati ad un CVCS, in cui la maggior parte delle operazioni erano soggette alle latenze di rete, questo aspetto di Git vi farà pensare che gli dei della velocità abbiano benedetto Git con poteri soprannaturali. Giacché l'intera storia del progetto sta qui, sul proprio disco locale, le operazioni sembrano quasi istantanee.
+La maggior parte delle operazioni in Git, necessitano solo di file e risorse locali per operare — generalmente non occorrono informazioni da altri computer nella rete. Se eri abituato ad un CVCS, in cui la maggior parte delle operazioni erano soggette alle latenze di rete, questo aspetto di Git ti farà pensare che gli dei della velocità abbiano benedetto Git con poteri soprannaturali. Giacché l'intera storia del progetto sta qui, sul proprio disco locale, le operazioni sembrano quasi istantanee.
Per esempio, per scorrere la storia di un progetto, Git non ha bisogno di connettersi al server per scaricarla e per poi visualizzarla — la 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 calcolare localmente le differenze, invece di richiedere di farlo ad un server remoto o di estrarre una precedente versione del file dal server remoto, per poi farlo in locale.
Questo significa anche che sono minime le cose che non si possono fare se si è offline o non connesso alla VPN. Se sei in aereo o sul treno e vuoi fare un po' di lavoro, puoi eseguire tranquillamente il commit, anche se non sei connesso alla rete per fare l'upload. Se tornando a casa, trovi che il tuo client VPN non funziona correttamente, puoi comunque lavorare. In molti altri sistemi, fare questo è quasi impossibile o penoso. Con Perforce, per esempio, puoi fare ben poco se non sei connesso al server; e con Subversion e CVS, puoi modificare i file, ma non puoi inviare i cambiamenti al tuo database (perché il database è offline). Tutto ciò non ti può sembrare una gran cosa, tuttavia potresti rimanere di stucco dalla differenza che Git può fare.
-### Git ha Integrità ###
+### Git Ha Integrità ###
Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di Git al più basso livello ed è intrinseco nella sua filosofia. Non puoi perdere informazioni nel transito o avere corruzioni di file senza che Git non sia in grado di accorgersene.
-Il meccanismo che Git usa per fare questo checksum, è un hash, denominato SHA-1. Si tratta di una stringa di 40-caratteri, composta da caratteri esadecimali (0–9 ed a–f) e calcolata in base al contenuto di file o della struttura di directory in Git. Un hash SHA-1 assomiglia a qualcosa come:
+Il meccanismo che Git usa per fare questo checksum, è un hash, denominato SHA-1. Si tratta di una stringa di 40-caratteri, composta da caratteri esadecimali (0–9 ed a–f) e calcolata in base al contenuto di file o della struttura della directory in Git. Un hash SHA-1 assomiglia a qualcosa come:
24b9da6552252987aa493b52f8696cd6d3b00373
in Git, questi valori di hash si vedono dappertutto, perché Git li usa tantissimo. Infatti, Git immagazzina ogni cosa, nel proprio database indirizzabile, non per nome di file, ma per il valore di hash del suo contenuto.
-### Git generalmente aggiunge solo dati ###
+### Git Generalmente Aggiunge Solo Dati ###
-Quando si fanno delle azioni in Git, quasi tutte aggiungono solo dati al database di Git. E' piuttosto difficile che si porti il sistema a fare qualcosa che non sia annullabile o a cancellare i dati in una qualche maniera. Come in altri VCS, si possono perdere o confondere le modifiche, di cui non si è ancora fatto il commit; ma dopo aver fatto il commit di uno snapshot in Git, è veramente difficile perderle, specialmente se si esegue regolarmente, il push del proprio database sull'altro repository.
+Quando si fanno delle azioni in Git, quasi tutte aggiungono solo dati al database di Git. E' piuttosto difficile che si porti il sistema a fare qualcosa che non sia annullabile o a cancellare i dati in una qualche maniera. Come in altri VCS, si possono perdere o confondere le modifiche, di cui non si è ancora fatto il commit; ma dopo aver fatto il commit di uno snapshot in Git, è veramente difficile perderle, specialmente se si esegue regolarmente, il push del proprio database su di un altro repository.
Questo rende l'uso di Git un piacere perché sappiamo che possiamo sperimentare senza il pericolo di perdere seriamente le cose. Per un maggior approfondimento su come Git salva i dati e come puoi recuperare i dati che sembrano persi, vedi "Sotto il Cofano" nel Capitolo 9.
-### I tre stati ###
+### I Tre Stati ###
-Ora, prestare attenzione. Questa è la prima cosa da ricordare su Git se si vuole affrontare al meglio il processo di apprendimento. Git ha tre stati principali, in cui possono risiedere i file: committed, modified e staged. Committed significa che il file è immagazzinato al sicuro, nel database locale. Modified significa che il file è stato modificato, ma non è stato ancora eseguito il commit nel proprio database. Staged significa che un file modificato nella versione corrente, è stato contrassegnato per essere inserito nello snapshot, al commit successivo.
+Ora, presta attenzione. Questa è la prima cosa da ricordare su Git se si vuole affrontare al meglio il processo di apprendimento. Git ha tre stati principali, in cui possono risiedere i file: committed, modified e staged. Committed significa che il file è immagazzinato al sicuro, nel database locale. Modified significa che il file è stato modificato, ma non è stato ancora eseguito il commit nel proprio database. Staged significa che un file modificato nella versione corrente, è stato contrassegnato per essere inserito nello snapshot, al commit successivo.
Questo ci conduce alle tre sezioni principali di un progetto Git: la directory di Git, la directory di lavoro e l'area di stage.
@@ -108,23 +108,23 @@ La directory di Git è il luogo dove Git salva i metadati ed il database degli o
La directory di lavoro è un singolo checkout di una versione del progetto. Questi file sono estratti dal database compresso, nella directory di Git, e posizionati nel disco per essere usati o modificati.
-L'area di stage è un semplice file, generalmente contenuto nella directory di Git, contenente le informazioni riguardanti il commit successivo. Qualche volta viene indicato come l'indice, ma sta diventando d'uso comune riferirsi ad essa, come all'area di stage (sosta).
+L'area di stage è un semplice file, generalmente contenuto nella directory di Git, contenente le informazioni riguardanti il commit successivo. Qualche volta viene indicato come l'indice, ma sta diventando d'uso comune riferirsi ad essa, come all'area di stage (sosta, ndt).
-Il flusso base di lavoro in Git, scorre come segue:
+Il flusso base di lavoro in Git, funziona come segue:
-1. Modificare i file nella directory di lavoro
-2. Eseguire l'operazione di stage dei file, per aggiungere i relativi snapshot all'area di stage
-3. Eseguire il commit, per immagazzinare permanentemente nella directory di Git, lo snapshot relativo, una volta presi i file nell'area di stage
+1. Modifici i file nella directory di lavoro
+2. Esegui l'operazione di stage dei file, per aggiungere i relativi snapshot all'area di stage
+3. Esegui il commit, per immagazzinare permanentemente nella directory di Git, lo snapshot relativo, una volta presi i file nell'area di stage
-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.
+Se una versione particolare di un file è nella directory git, sarà considerata già affidata. 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.
## Installare Git ##
-Incominciamo ad usare un po' di Git! Per prima cosa — occorre installarlo. Puoi ottenere Git in diversi modi; i due principali sono, installarlo dai sorgenti o installarlo da un pacchetto pre-esistente per la tua piattaforma.
+Incominciamo ad usare un po' di Git! Per prima cosa — occorre installarlo. Puoi ottenere Git in diversi modi; i due principali sono: installarlo dai sorgenti o installarlo da un pacchetto pre-esistente per la tua piattaforma.
-### Installazione da sorgenti ###
+### Installare da Sorgenti ###
-Se puoi, è generalmente vantaggioso installare Git dai sorgenti, perché così puoi usare la versione più recente. Ogni versione di Git, tende ad includere utili miglioramenti all'interfaccia utente, quindi, avere l'ultima versione disponibile è spesso la scelta migliore, se si ha familiarità con la compilazione dei sorgenti. Inoltre capita anche, che molte distribuzioni Linux contengano pacchetti molto vecchi; perciò, se non stai usando una distro aggiornata o dei backport, l'installazione da sorgente può essere la cosa migliore da fare.
+Se puoi, è generalmente vantaggioso installare Git dai sorgenti, perché così puoi usare la versione più recente. Ogni versione di Git, tende ad includere utili miglioramenti all'interfaccia utente, quindi, avere l'ultima versione disponibile è spesso la scelta migliore, se hai familiarità con la compilazione dei sorgenti. Inoltre capita anche, che molte distribuzioni Linux contengano pacchetti molto vecchi; perciò, se non stai usando una distro aggiornata o dei backport, l'installazione da sorgente può essere la cosa migliore da fare.
Per installare Git, hai bisogno delle seguenti librerie, da cui dipende Git: curl, zlib, openssl, expat e libiconv. Per esempio, se sei su un sistema che usa yum (come in Fedora), o apt-get (come nei sistemi Debian), puoi usare uno dei seguenti comandi per installare tutte le dipendenze:
@@ -149,7 +149,7 @@ Dopo aver fatto questo, puoi ottenere Git da Git stesso per gli aggiornamenti:
$ git clone git://git.kernel.org/pub/scm/git/git.git
-### Installazione su Linux ###
+### Installare su Linux ###
Se vuoi installare Git su Linux, tramite una installazione da binario, generalmente, puoi farlo con lo strumento base di amministrazione-dei-pacchetti della tua distribuzione. Se sei su Fedora, puoi usare yum:
@@ -174,15 +174,17 @@ L'altro metodo è installare Git via MacPorts (`http://www.macports.org`). Se ha
Non ti occorre aggiungere tutti i pacchetti, ma evidentemente vorrai includere +svn, nel caso tu debba usare Git con i repository di Subversion (vedi Capitolo 8).
-### Installazione su Windows ###
+### Installare su Windows ###
-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 GitHub, 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 eseguibile dalla pagina di GitHub, e lancialo:
http://msysgit.github.com/
Una volta installato, hai a disposizione sia la versione da riga di comando (incluso un client SSH che sarà utile, in seguito) sia l'interfaccia grafica (GUI) standard.
-## Prima configurazione di Git ##
+Nota sull'uso su Windows: dovresti usare Git con la shell msysGit fornita (stile Unix), permette di usare complesse linee di comando date in questo libro. Se hai bisogno, per qualche ragione, di usare la shell nativa di Windows / la console a linea di comando, devi usare le doppie virgolette invece delle virgolette semplici (per i parametri con che contengono spazi) e devi virgolettare i parametri che terminano con l'accento circonflesso (^) se questi sono al termine della linea, poiché esso è un simbolo di proseguimento in Windows.
+
+## Prima Configurazione di Git ##
Ora che hai Git sul tuo sistema, vorrai fare un paio di cose per personalizzare l'ambiente di Git. Ti occorre farle solo una volta; esse rimangono invariate anche dopo un aggiornamento. Comunque, puoi cambiarle, in ogni momento, eseguendo di nuovo questi comandi.
@@ -192,9 +194,9 @@ Git è rilasciato con uno strumento che si chiama git config che ti permetterà
* file `~/.gitconfig`: Specifico per il tuo utente. Puoi far leggere e scrivere a Git questo file passando l'opzione `--global`.
* file di configurazione nella directory git (che è `.git/config`) di ogni repository che si sta usando. Specifico per ogni singolo repository. Ogni livello sovrascrive i valori del livello precedente, così i valori in `.git/config` vincono su quelli in `/etc/gitconfig`.
-Sui sistemi Windows, Git cerca il file `.gitconfig` nella directory `$HOME` (`C:\Documents and Settings\$USER` per la maggior parte delle persone). Inoltre per quanto riguarda /etc/gitconfig, sarà relativo alla radice di MSys, che è in dipendenza a dove si vorrà installare Git sul sistema Windows quando si lancia l'installazione.
+Sui sistemi Windows, Git cerca il file `.gitconfig` nella directory `$HOME` (`C:\Documents and Settings\$USER` per la maggior parte delle persone). Inoltre per quanto riguarda /etc/gitconfig, sarà relativo alla radice di MSys, che dipende da dove si vorrà installare Git sul sistema Windows quando si lancia l'installazione.
-### La propria identità ###
+### La Propria Identità ###
La prima cosa che occorrerebbe fare, quando si installa Git, è impostare il proprio nome utente e indirizzo e-mail. Ciò è importante, perché ogni commit di Git usa queste informazioni, che vengono incapsulate nei commit che si fanno:
@@ -203,21 +205,21 @@ La prima cosa che occorrerebbe fare, quando si installa Git, è impostare il pro
Di nuovo, passando l'opzione `--global`, occorre fare ciò solo una volta, dopo di che Git userà sempre queste informazioni, per qualsiasi operazione fatta sul sistema. Se si vuole sovrascriverle con un nome o una e-mail per progetti specifici, basta eseguire il comando senza l'opzione `--global`, quando si è in uno di quei progetti.
-### Il proprio editor ###
+### Il Proprio Editor ###
Ora che è configurata la propria identità, si può configurare l'editor di testo predefinito, da usare quando Git avrà bisogno di inserire un messaggio. Per impostazione predefinita, Git usa l'editor di testo predefinito del sistema, che generalmente è Vi o Vim. Se vuoi usare un editor di testo differente, come Emacs, puoi fare come segue:
$ git config --global core.editor emacs
-### Il proprio Diff ###
+### Il Proprio Diff ###
-Un'altra utile opzione, che si potrebbe voler configurare, è lo strumento diff, predefinito, da usare per risolvere i conflitti di merge (fusione). Per usare vimdiff:
+Un'altra utile opzione, che si potrebbe voler configurare, è lo strumento diff, predefinito, da usare per risolvere i conflitti di merge (fusione, ndt). Per usare vimdiff:
$ git config --global merge.tool vimdiff
Git accetta kdeff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge e opendiff, come strumenti validi di merge. E' anche possibile impostare uno strumento personalizzato; vedere il Capitolo 7, per maggiori informazioni su come farlo.
-### Controllare le impostazioni ###
+### Controllare le Impostazioni ###
Per controllare le proprie impostazioni, si può usare il comando `git config --list`, che elenca tutte le impostazioni di Git, fatte fino a questo punto:
@@ -237,21 +239,21 @@ Per controllare quale sia il valore di una chiave, ritenuto da Git usare, `git c
$ git config user.name
Scott Chacon
-## Ottenere aiuto ##
+## Ottenere Aiuto ##
-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:
+Se dovessi avere bisogno di aiuto durante l'uso di Git, ci sono tre modi per vedere le pagine del manuale di aiuto per ogni comando di Git:
$ git help <verb>
$ git <verb> --help
$ man git-<verb>
-Per esempio, puoi avere la manpage di aiuto, per il comando config, lanciando
+Per esempio, puoi avere la pagina del manuale di aiuto, per il comando config, lanciando
$ git help config
Questi comandi sono utili, perché puoi accedere ad essi da ogni dove, anche se sei offline.
-Se il manpage e questo libro non sono sufficienti e hai bisogno di un aiuto più diretto da una persona, puoi provare i canali `#git` o `#github`, sul server IRC di Freenode (irc.freenode.com). Questi canali sono regolarmente frequentati da centinaia di persone che conoscono molto bene Git e saranno davvero felici di aiutarti.
+Se il manuale e questo libro non sono sufficienti e hai bisogno di un aiuto più diretto da una persona, puoi provare i canali `#git` o `#github`, sul server IRC di Freenode (irc.freenode.com). Questi canali sono regolarmente frequentati da centinaia di persone che conoscono molto bene Git e saranno davvero felici di aiutarti.
-## Riassumendo ##
+## Riassunto ##
-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.
+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à. É ora tempo di imparare qualcosa delle basi di Git.
265 it/02-git-basics/01-chapter2.markdown
View
@@ -2,17 +2,17 @@
Se puoi leggere solo un capitolo per capire l'uso di Git, questo fa per te. Questo capitolo illustra tutti i comandi base per fare la stragrande maggioranza delle cose impiegando al meglio il tuo tempo con Git. Alla fine del capitolo, dovresti essere in grado di configurare ed inizializzare un repository, avviare e fermare il tracciamento dei file e mettere in stage o eseguire il commit dei cambiamenti. Vedremo come impostare Git per ignorare certi file o pattern di file, come correggere gli errori velocemente e facilmente, come navigare nella storia del tuo progetto e vedere i cambiamenti tra i vari commit e come fare il push ed il pull da repository remoti.
-## Ottenere un repository Git ##
+## Ottenere un Repository Git ##
Puoi creare un progetto Git usando due approcci principali. Il primo prende un progetto esistente o una directory e la importa in Git. Il secondo clona un repository Git esistente da un altro server.
-### Inizializzare un repository in una directory esistente ###
+### Inizializzare un Repository in una Directory Esistente ###
Se stai iniziando a tracciare un progetto esistente con Git, devi posizionarti nella directory del progetto e digitare:
$ git init
-Questo creerà una nuova sottodirectory chiamata .git che conterrà tutti i file necessari per il repository — uno scheletro del repository Git. A questo punto, niente del tuo progetto è tracciato ancora. (Vedi il Capitolo 9 per avere maggiori informazioni esatte sui file che sono contenuti nella directory `.git` che hai appena creato.)
+Questo creerà una nuova sottodirectory chiamata .git che conterrà tutti i file necessari per il repository — uno scheletro del repository Git. A questo punto, niente del tuo progetto è già tracciato. (Vedi il Capitolo 9 per avere maggiori informazioni esatte sui file che sono contenuti nella directory `.git` che hai appena creato.)
Se vuoi iniziare a tracciare i file esistenti (al contrario di una directory vuota), dovresti iniziare a monitorare questi file eseguendo un commit iniziale. Lo puoi fare con pochi comandi che specificano quali file vuoi controllare, seguiti da un commit:
@@ -22,15 +22,15 @@ Se vuoi iniziare a tracciare i file esistenti (al contrario di una directory vuo
Vedremo in seguito velocemente cosa fanno questi comandi. A questo punto hai un repository Git con dei file tracciati ed un commit iniziale.
-### Clonare un repository esistente ###
+### Clonare un Repository Esistente ###
-Se vuoi avere la copia di un repository Git esistente — per esempio, un progetto a cui vuoi contribuire — il comando di cui hai bisogno è git clone. Se hai familiarità con altri sistemi VCS come Subversion, noterai che il comando è clone e non checkout. Questa è una distinzione importante — Git riceve una copia di circa tutti i dati che un server possiede. Ogni versione di ogni file della storia del progetto sono scaricate quando lanci `git clone`. Infatti, se il disco del tuo server è corrotto, puoi usare qualsiasi clonazione di qualsiasi client per ripristinare il server allo stato in cui era quando è stato clonato (puoi perdere alcuni agganci server, ma tutte le versioni dei dati saranno presenti — vedi il Capitolo 4 per maggiori dettagli).
+Se vuoi avere la copia di un repository Git esistente — per esempio, un progetto a cui vuoi contribuire — il comando di cui hai bisogno è git clone. Se hai familiarità con altri sistemi VCS come Subversion, noterai che il comando è clone e non checkout. Questa è una distinzione importante — Git riceve una copia di circa tutti i dati che un server possiede. Ogni versione di ogni file della storia del progetto sono scaricate quando lanci `git clone`. Infatti, se il disco del tuo server è corrotto, puoi usare qualsiasi copia di qualsiasi client per ripristinare il server allo stato in cui era quando è stato clonato (puoi perdere alcuni agganci server, ma tutte le versioni dei dati saranno presenti — vedi il Capitolo 4 per maggiori dettagli).
Clona un repository con `git clone [url]`. Per esempio, se vuoi clonare la libreria Ruby Git chiamata Grit, puoi farlo così:
$ git clone git://github.com/schacon/grit.git
-Questo comando crea un directory "grit", inizializza una directory `.git` dentro di essa, scarica tutti i dati per questo repository ed imposta la copia di lavoro dell'ultima versione. Se entri nella nuova directory `grit`, vedrai i file del progetto, pronti per essere modificati o usati. Se vuoi clonare il repository in una directory con un nome diverso da grit, puoi specificarlo come opzione successiva al comando da terminale:
+Questo comando crea un directory "grit", inizializza una directory `.git` dentro di essa, scarica tutti i dati per questo repository ed imposta la copia di lavoro dell'ultima versione. Se entri nella nuova directory `grit`, vedrai i file del progetto, pronti per essere modificati o usati. Se vuoi clonare il repository in una directory con un nome diverso da grit, puoi specificarlo come opzione successiva al comando da terminale:
$ git clone git://github.com/schacon/grit.git mygrit
@@ -38,18 +38,18 @@ Questo comando fa la stessa cosa del precedente, ma la directory di destinazione
Git può usare differenti protocolli di trasferimento. L'esempio precedente usa il protocollo `git://`, ma puoi anche vedere `http(s)://` o `user@server:/path.git`, che usa il protocollo di trasferimento SSH. Il Capitolo 4 introdurrà tutte le opzioni disponibili che il server può impostare per farti accedere al repository Git ed i pro e i contro di ognuna.
-## Registrare i cambiamenti al repository ##
+## Registrare i Cambiamenti nel Repository ##
In buona fede hai copiato un repository Git e hai la copia di lavoro dei file di questo progetto. Ora puoi apportare alcune modifiche ed inviare gli snapshots di questi cambiamenti nel tuo repository ogni volta che il progetto raggiunge uno stato che vuoi registrare.
-Ricorda che ogni file nella tua directory di lavoro è in una dei due stati seguenti: tracciato o non tracciato. I file tracciati sono i file presenti nell'ultimo snapshot; possono essere non modificati, modificati o parcheggiati (stage). I file non tracciati sono tutti gli altri - qualsiasi file nella tua directory di lavoro che non è presente nel tuo ultimo snapshot o nella tua area di staging. Quando cloni per la prima volta un repository, tutti i tuoi file sono tracciati e non modificati perché li hai appena prelevati e non hai modificato ancora niente.
+Ricorda che ogni file nella tua directory di lavoro è in una dei due stati seguenti: *tracciato* o *non tracciato*. I file *tracciati* sono i file presenti nell'ultimo snapshot; possono essere *non modificati*, *modificati* o *staged* (parcheggiati, ndt). I file *non tracciati* sono tutti gli altri - qualsiasi file nella tua directory di lavoro che non è presente nel tuo ultimo snapshot o nella tua area di stage. Quando cloni per la prima volta un repository, tutti i tuoi file sono tracciati e non modificati perché li hai appena prelevati e non hai modificato ancora niente.
Quando modifichi i file, Git li vede come cambiati, perché li hai modificati rispetto all'ultimo commit. Parcheggi questi file e poi esegui il commit di tutti i cambiamenti presenti nell'area di stage, ed il ciclo si ripete. Questo ciclo di vita è illustrato nella Figura 2-1.
Insert 18333fig0201.png
Figura 2-1. Il ciclo di vita dello stato dei tuoi file.
-### Controlla lo stato dei tuoi file ###
+### Controlla lo Stato dei Tuoi File ###
Lo strumento principale che userai per determinare quali file sono in un certo stato è il comando git status. Se lanci questo comando direttamente dopo aver fatto una clonazione, dovresti vedere qualcosa di simile a:
@@ -57,7 +57,7 @@ Lo strumento principale che userai per determinare quali file sono in un certo s
# On branch master
nothing to commit (working directory clean)
-Questo significa che hai una directory di lavoro pulita — in altre parole, non c'è traccia di file modificati. Git inoltre non vede altri file non tracciati, altrimenti sarebbero elencati qui. Infine, il comando ci dice in quale ramo (branch) si è. Per ora, è sempre il master, che è il predefinito; non preoccuparti ora di questo. Il prossimo capitolo tratterà delle ramificazioni e dei riferimenti nel dettagli.
+Questo significa che hai una directory di lavoro pulita — in altre parole, non c'è traccia di file modificati. Git inoltre non vede altri file non tracciati, altrimenti sarebbero elencati qui. Infine, il comando ci dice in quale ramo si è. Per ora, è sempre il master, che è il predefinito; non preoccuparti di questo per ora. Il prossimo capitolo tratterà delle ramificazioni e dei riferimenti nei dettagli.
Ora diciamo che hai aggiunto un nuovo file al tuo progetto, un semplice file README. Se il file non esisteva prima, e lanci `git status`, vedrai il tuo file non tracciato come segue:
@@ -72,13 +72,13 @@ Ora diciamo che hai aggiunto un nuovo file al tuo progetto, un semplice file REA
Puoi vedere che il tuo nuovo file README non è tracciato, perché è sotto al titolo "Untracked files" nell'output degli stati. Untracked fondamentalmente significa che Git vede un file che non avevi nel precedente snapshot (commit); Git non inizierà ad includerlo negli snapshot dei tuoi commit fino a quando tu non glielo dirai esplicitamente. Si comporta così per evitare che tu accidentalmente includa file binari generati o qualsiasi altro tipo di file che non vuoi sia incluso. Se vuoi includere il file README, continua con il tracciamento dei file.
-### Tracciare nuovi file ###
+### Tracciare Nuovi File ###
-Per iniziare a tracciare un nuovo file, usa il comando `git add`. Per tracciare il file README, lancia questo comando:
+Per iniziare a tracciare un nuovo file, usa il comando `git add`. Per tracciare il file `README`, lancia questo comando:
$ git add README
-Se lanci nuovamente il comando di stato, puoi vedere il tuo file README tracciato e parcheggiato:
+Se lanci nuovamente il comando di stato, puoi vedere il tuo file `README` tracciato e parcheggiato:
$ git status
# On branch master
@@ -88,9 +88,9 @@ Se lanci nuovamente il comando di stato, puoi vedere il tuo file README tracciat
# new file: README
#
-Ti dice che è parcheggiato (in stage) perché è sotto al titolo "Changes to be committed". Se fai ora il commit, la versione del file al momento in cui hai lanciato git add sarà quella che troverai nella storia dello snapshot. Ti ricordo che precedentemente è stato lanciato git init, poi hai dovuto lanciare git add (files) — che era l'inizio per tracciare i file nella tua directory. Il comando git add prende il nome del path di ogni file o directory; se è una directory, il comando aggiunge tutti i file in quella directory ricorsivamente.
+Ti dice che è in stage (parcheggiato, ndt) perché è sotto al titolo "Changes to be committed". Se fai ora il commit, la versione del file al momento in cui hai lanciato `git add` sarà quella che troverai nella storia dello snapshot. Potresti ricordare che quando hai eseguito `git init` precedentemente, poi hai dovuto lanciare `git add (file)` — che era necessario per l'inizio del tracciamento dei file nella tua directory. Il comando git add prende il nome del percorso di ogni file o directory; se è una directory, il comando aggiunge tutti i file in quella directory ricorsivamente.
-### Parcheggiare file modificati ###
+### Parcheggiare File Modificati ###
Ora modifichiamo un file che è già stato tracciato. Se modifichi un file precedentemente tracciato chiamato `benchmarks.rb` e poi avvii nuovamente il comando `status`, otterrai qualcosa di simile a:
@@ -107,7 +107,7 @@ Ora modifichiamo un file che è già stato tracciato. Se modifichi un file prece
# modified: benchmarks.rb
#
-Il file benchmarks.rb appare sotto la sezione chiamata "Changes not staged for commit" — che significa che un file che è tracciato è stato modificato nella directory di lavoro ma non ancora messo in stage (parcheggiato). Per parcheggiarlo, avvia il comando `git add` (è un comando multifunzione — è usato per iniziare a tracciare nuovi file, per parcheggiare i file e per fare altre cose come eseguire la fusione dei file che entrano in conflitto dopo che sono stati risolti). Avvia dunque `git add` per parcheggiare ora il file benchmarks.rb, e avvia nuovamente `git status`:
+Il file benchmarks.rb appare sotto la sezione chiamata "Changes not staged for commit" — che significa che un file che è tracciato è stato modificato nella directory di lavoro ma non ancora messo in stage. Per parcheggiarlo, avvia il comando `git add` (è un comando multifunzione — è usato per iniziare a tracciare nuovi file, per parcheggiare i file e per fare altre cose come eseguire la fusione dei file che entrano in conflitto dopo che sono stati risolti). Avvia dunque `git add` per parcheggiare ora il file benchmarks.rb, e avvia nuovamente `git status`:
$ git add benchmarks.rb
$ git status
@@ -136,7 +136,7 @@ Entrambi i file sono parcheggiati ed entreranno nel prossimo commit. A questo pu
# modified: benchmarks.rb
#
-Che succede? Ora benchmarks.rb è elencato sia in stage che non. Come è possibile? E' saltato fuori che Git ha parcheggiato il file esattamente come se tu avessi avviato il comando git add. Se esegui ora il commit, la versione di benchmarks.rb che verrà inviata nel commit sarà come quella di quando tu hai lanciato il comando git add, non la versione del file che appare nella tua directory di lavoro quando lanci git commit. Se modifichi un file dopo che hai lanciato `git add`, devi nuovamente avviare `git add` per parcheggiare l'ultima versione del file:
+Che succede? Ora benchmarks.rb è elencato sia in stage che non. Come è possibile? É saltato fuori che Git ha parcheggiato il file esattamente come se tu avessi avviato il comando git add. Se esegui ora il commit, la versione di benchmarks.rb che verrà inviata nel commit sarà quella di quando tu hai lanciato il comando git add, non la versione del file che appare nella tua directory di lavoro quando lanci git commit. Se modifichi un file dopo che hai lanciato `git add`, devi nuovamente avviare `git add` per parcheggiare l'ultima versione del file:
$ git add benchmarks.rb
$ git status
@@ -148,7 +148,7 @@ Che succede? Ora benchmarks.rb è elencato sia in stage che non. Come è possibi
# modified: benchmarks.rb
#
-### Ignorare file ###
+### Ignorare File ###
Spesso, si ha una classe di file che non si vuole automaticamente aggiungere o far vedere come file non tracciati a Git. Ci sono generalmente alcuni file generati automaticamente come i file di log o i file prodotti dalla creazione di un sistema. In questi casi, puoi creare un file chiamato .gitignore con una lista di pattern corrispondente ad essi. Questo è un esempio di file .gitignore:
@@ -160,12 +160,12 @@ La prima linea dice a Git di ignorare qualsiasi file che finisce con .o o .a —
Le regole per i pattern che puoi mettere nel file .gitignore sono le seguenti:
-* Linee nere o linee che iniziano con # sono ignorate.
-* Standard glob pattern funziona.
+* Linee vuote o linee che iniziano con # sono ignorate.
+* I glob pattern standard (formati usati per indicare classi di caratteri nelle shell, ndt) funzionano.
* Puoi terminare i pattern con un diviso (`/`) per specificare una directory.
* Puoi negare un pattern aggiungendo all'inizio il punto di esclamazione (`!`).
-I glob pattern sono semplicemente espressioni regolari usate dalla shell. Un asterisco (`*`) corrisponde a zero o più caratteri; `[abc]` corrispondente ad ogni carattere all'interno delle parentesi (in questo caso a, b, o c); il punto di domanda (`?`) corrispondente ad un singolo carattere; ed i caratteri all'interno delle parentesi quadre separati dal segno meno (`[0-9]`) corrispondono ad ogni carattere all'interno del range impostato (in questo caso da 0 a 9).
+I glob pattern sono come espressioni regolari semplificate usate dalla shell. Un asterisco (`*`) corrisponde a zero o più caratteri; `[abc]` corrispondente ad ogni carattere all'interno delle parentesi (in questo caso a, b, o c); il punto di domanda (`?`) corrispondente ad un singolo carattere; ed i caratteri all'interno delle parentesi quadre separati dal segno meno (`[0-9]`) corrispondono ad ogni carattere all'interno del range impostato (in questo caso da 0 a 9).
Questo è un altro esempio di file .gitignore:
@@ -180,10 +180,14 @@ Questo è un altro esempio di file .gitignore:
build/
# ignora doc/note.txt, ma non doc/server/arch.txt
doc/*.txt
+ # ignora tutti i file .txt nella directory doc/
+ doc/**/*.txt
-### Visualizza le tue modifiche parcheggiate e non ###
+Un pattern `**/` è disponibile in Git dalla version 1.8.2.
-Se il comando `git status` è troppo vago per te — vorrai conoscere esattamente cosa hai modificato, non solamente i file che hai cambiato — puoi usare il comando `git diff`. Scopriremo in maggior dettaglio `git diff` più avanti; ma probabilmente lo userai più spesso per rispondere a queste due domande: Cosa hai modificato ma non ancora parcheggiato? E cosa hai parcheggiato e che sta per mettere nel commit? Certamente, `git status` risponde a queste domande in generale, `git diff` ti mostra le linee esatte aggiunte e rimosse — la patch, per così dire.
+### Visualizzare le Tue Modifiche Parcheggiate e Non ###
+
+Se il comando `git status` è troppo vago per te — vorrai conoscere esattamente cosa hai modificato, non solamente i file che hai cambiato — puoi usare il comando `git diff`. Scopriremo in maggior dettaglio `git diff` più avanti; ma probabilmente lo userai più spesso per rispondere a queste due domande: Cosa hai modificato, ma non ancora parcheggiato? E cosa hai parcheggiato e che sta per mettere nel commit? Certamente, `git status` risponde a queste domande in generale, `git diff` ti mostra le linee esatte aggiunte e rimosse — la patch, per così dire.
Nuovamente ti chiedo di modificare e parcheggiare il file README e poi modificare il file benchmarks.rb senza parcheggiarlo. Se lanci il comando `status`, vedrai nuovamente questo:
@@ -200,7 +204,7 @@ Nuovamente ti chiedo di modificare e parcheggiare il file README e poi modificar
# modified: benchmarks.rb
#
-Per vedere cosa hai modificato ma non ancora parcheggiato, digita `git diff` senza altri argomenti:
+Per vedere cosa hai modificato, ma non ancora parcheggiato, digita `git diff` senza altri argomenti:
$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
@@ -221,7 +225,7 @@ Per vedere cosa hai modificato ma non ancora parcheggiato, digita `git diff` sen
Questo comando compara cosa c'è nella tua directory di lavoro con quello che è nella tua area di stage. Il risultato ti dice i cambiamenti che hai fatto che non sono ancora stati parcheggiati.
-Se vuoi vedere cosa hai parcheggiato e che sarà inviato con il tuo prossimo commit, puoi usare `git diff --cached`. (Nella versione 1.6.1 e successive di Git, puoi usare anche `git diff --staged`, che dovrebbe essere più facile da ricordare.) Questo comando compara i tuoi cambiamenti nell'area di stage ed il tuo ultimo commit:
+Se vuoi vedere cosa hai parcheggiato e cosa sarà inviato con il tuo prossimo commit, puoi usare `git diff --cached`. (Nella versione 1.6.1 e successive di Git, puoi usare anche `git diff --staged`, che dovrebbe essere più facile da ricordare). Questo comando compara i tuoi cambiamenti nell'area di stage ed il tuo ultimo commit:
$ git diff --cached
diff --git a/README b/README
@@ -236,7 +240,7 @@ Se vuoi vedere cosa hai parcheggiato e che sarà inviato con il tuo prossimo com
+
+Grit is a Ruby library for extracting information from a Git repository
-E' importante notare che `git diff` di per se non visualizza tutti i cambiamenti fatti dal tuo ultimo commit — solo i cambiamenti che ancora non sono parcheggiati. Questo può confondere, perché se hai messo in stage tutte le tue modifiche, `git diff` non darà nessun output.
+É importante notare che `git diff` di per se non visualizza tutti i cambiamenti fatti dal tuo ultimo commit — solo i cambiamenti che ancora non sono parcheggiati. Questo può confondere, perché se hai messo in stage tutte le tue modifiche, `git diff` non darà nessun output.
Per un altro esempio, se parcheggi il file benchmarks.rb e lo modifichi, puoi usare `git diff` per vedere i cambiamenti nel file che sono in stage e i cambiamenti che non sono parcheggiati:
@@ -286,10 +290,10 @@ e `git diff --cached` per vedere cosa hai parcheggiato precedentemente:
log = git.commits('master', 15)
log.size
-### Eseguire il commit delle tue modifiche ###
+### Eseguire il Commit delle Tue Modifiche ###
Ora la tua area di stage è impostata come volevi, puoi eseguire il commit delle tue modifiche. Ricorda che qualsiasi cosa che non è parcheggiata — qualsiasi file che hai creato o modificato e a cui non hai fatto `git add` — non andrà nel commit. Rimarranno come file modificati sul tuo disco.
-In questo caso, l'ultima volta che hai lanciato `git status`, hai visto che tutto era parcheggiato, così sei pronto ad inviare le tue modifiche con un commit. Il modo più semplice per eseguire il commit è di digitare `git commit`:
+In questo caso, l'ultima volta che hai lanciato `git status`, hai visto che tutto era parcheggiato, così sei pronto ad inviare le tue modifiche con un commit. Il modo più semplice per eseguire il commit è digitare `git commit`:
$ git commit
@@ -310,7 +314,7 @@ L'editor visualizzerà il seguente testo (questo è un esempio della schermata d
~
".git/COMMIT_EDITMSG" 10L, 283C
-Puoi vedere che il messaggio predefinito del commit contiene l'ultimo output del comando `git status`, commentato, e la prima riga in alto è vuota. Puoi rimuovere questi commenti ed inserire il tuo messaggio, o puoi lasciarli così per aiutarti a ricordare cosa hai inviato. (Per avere una nota di ricordo più esplicita puoi passare l'opzione `-v` a `git commit`. Facendo questo metterai la differenza del tuo ultimo cambiamento nell'editor così potrai vedere esattamente cosa hai fatto.) Quando esci dall'editor, Git crea il tuo commit con un messaggio (con il commento ed il diff spogliato).
+Puoi vedere che il messaggio predefinito del commit contiene l'ultimo output del comando `git status`, commentato, e la prima riga in alto è vuota. Puoi rimuovere questi commenti ed inserire il tuo messaggio, o puoi lasciarli così per aiutarti a ricordare cosa hai inviato. (Per avere una nota di ricordo più esplicita puoi passare l'opzione `-v` a `git commit`. Così facendo inserirai i cambiamenti effettuati nell'editor in modo che tu possa vedere esattamente cosa hai fatto). Quando esci dall'editor, Git crea il tuo commit con un messaggio (con i commenti ed i cambiamenti eliminati).
In alternativa, puoi inserire il messaggio del tuo commit in linea con il comando `commit` specificando dopo di esso l'opzione -m, come segue:
@@ -319,13 +323,13 @@ In alternativa, puoi inserire il messaggio del tuo commit in linea con il comand
2 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 README
-Ora hai creato il tuo primo commit! Puoi vedere che il commit ha riportato alcune informazioni sull'operazione: che ramo hai inviato (al master), che checksum SHA-1 ha il commit (`463dc4f`), quanti file sono stati modificati e le statistiche sulle linee aggiunte e rimosse nel commit.
+Ora hai creato il tuo primo commit! Puoi vedere che il commit ha riportato alcune informazioni sull'operazione: a quale ramo hai affidato il commit (`master`), quale checksum SHA-1 ha il commit (`463dc4f`), quanti file sono stati modificati e le statistiche sulle linee aggiunte e rimosse nel commit.
-Ricorda che il commit registra lo snapshot che hai impostato nella tua area di staging. Qualsiasi cosa che non hai parcheggiato rimarrà come modificata; puoi fare un altro commit per aggiungere questi alla storia del progetto. Ogni volta che farai un commit, stai registrando una istantanea del tuo progetto che puoi ripristinare o comparare successivamente.
+Ricorda che il commit registra lo snapshot che hai impostato nella tua area di stage. Qualsiasi cosa che non hai parcheggiato rimarrà come modificata; puoi fare un altro commit per aggiungere questi alla storia del progetto. Ogni volta che fai un commit stai registrando una istantanea del tuo progetto, che puoi ripristinare o comparare successivamente.
-### Saltare l'area di staging ###
+### Saltare l'Area di Stage ###
-Anche se può essere estremamente utile per amministrare i commit esattamente come li vuoi, l'area di staging è molto più complessa di quanto tu possa averne bisogno nel lavoro normale. Se vuoi saltare l'area di parcheggio, Git fornisce una semplice scorciatoia. Passando l'opzione `-a` al comando `git commit` Git automaticamente parcheggia tutti i file che sono già stati tracciati facendo il commit, permettendoti di saltare la parte `git add`:
+Anche se può essere estremamente utile per amministrare i commit esattamente come li vuoi, l'area di stage è molto più complessa di quanto tu possa averne bisogno nel lavoro normale. Se vuoi saltare l'area di parcheggio, Git fornisce una semplice scorciatoia. Passando l'opzione `-a` al comando `git commit` Git automaticamente parcheggia tutti i file che sono già stati tracciati facendo il commit, permettendoti di saltare la parte `git add`:
$ git status
# On branch master
@@ -340,11 +344,11 @@ Anche se può essere estremamente utile per amministrare i commit esattamente co
Nota come non hai bisogno, in questo caso, di lanciare `git add` sul file benchmarks.rb prima del commit.
-### Rimuovere file ###
+### Rimuovere File ###
-Per rimuovere un file con Git, hai bisogno di rimuoverlo dai file tracciati (più precisamente, rimuoverlo dall'area di staging) e poi di fare il commit. Il comando `git rm` fa questo ed inoltre rimuove il file dalla tua directory di lavoro così non lo vedrai come un file non tracciato la prossima volta.
+Per rimuovere un file con Git, hai bisogno di rimuoverlo dai file tracciati (più precisamente, rimuoverlo dall'area di stage) e poi di fare il commit. Il comando `git rm` fa questo ed inoltre rimuove il file dalla tua directory di lavoro così non lo vedrai come un file non tracciato la prossima volta.
-Se semplicemente rimuovi il file dalla directory di lavoro, sarà visto sotto l'area "Changes not staged for commit" (cioè, non parcheggiato) dell'output `git status`:
+Se semplicemente rimuovi il file dalla directory di lavoro, sarà visto sotto l'area "Changes not staged for commit" (cioè, _non parcheggiato_) dell'output `git status`:
$ rm grit.gemspec
$ git status
@@ -369,9 +373,9 @@ Poi, se lanci `git rm`, parcheggia il file rimosso:
# deleted: grit.gemspec
#
-La prossima volta che fai il commit, il file se ne andrà e non sarà più tracciato. Se modifichi il file e lo aggiungi nuovamente all'indice, devi forzarne la rimozione con l'opzione `-f`. Questa è una caratteristica di sicurezza per prevenire la rimozione accidentale dei dati che non sono ancora stati registrati in uno snapshot e che non possono essere recuperati da Git.
+La prossima volta che fai il commit, il file se ne andrà e non sarà più tracciato. Se modifichi il file e già aggiunto all'indice, devi forzarne la rimozione con l'opzione `-f`. Questa è una caratteristica di sicurezza per prevenire la rimozione accidentale dei dati che non sono ancora stati registrati in uno snapshot e che non possono essere recuperati da Git.
-Un'altra cosa utile che potresti voler fare è mantenere il file nel tuo albero di lavoro ma rimuoverlo dall'area di staging. In altre parole, vuoi mantenere il file sul tuo disco ma non vuoi che Git ne mantenga ancora traccia. Questo è particolarmente utile se ti dimentichi di aggiungere qualcosa al tuo file `.gitignore` ed accidentalmente lo aggiungi, come un lungo file di log od un gruppo di file `.a` compilati. Per fare questo, usa l'opzione `--cached`:
+Un'altra cosa utile che potresti voler fare è mantenere il file nel tuo albero di lavoro ma rimuoverlo dall'area di stage. In altre parole, vuoi mantenere il file sul tuo disco ma non vuoi che Git ne mantenga ancora traccia. Questo è particolarmente utile se ti dimentichi di aggiungere qualcosa al tuo file `.gitignore` ed accidentalmente lo aggiungi, come un lungo file di log od un gruppo di file `.a` compilati. Per fare questo, usa l'opzione `--cached`:
$ git rm --cached readme.txt
@@ -385,15 +389,15 @@ Nota la barra inversa (`\`) di fronte a `*`. Questo è necessario perché Git ha
Questo comando rimuove tutti i file che finiscono con `~`.
-### Movimenti di file ###
+### Muovere File ###
-A differenza di altri sistemi VCS, Git non traccia esplicitamente i movimenti di file. Se rinomini un file in Git, nessun metadata è immagazzinato in Git che ti dirà che hai rinominato il file. Come sempre, Git è abbastanza intelligente da capire il fatto — ci occuperemo di rilevare il movimento dei file dopo.
+A differenza di altri sistemi VCS, Git non traccia esplicitamente i movimenti di file. Se rinomini un file in Git, nessun metadato è immagazzinato in Git che ti dirà che hai rinominato il file. Tuttavia, Git è abbastanza intelligente da capirlo dopo che è avvenuto — ci occuperemo di rilevare il movimento dei file più tardi.
-Perciò crea un di confusione il fatto che Git abbia un comando `mv`. Se vuoi rinominare un file in Git, puoi lanciare qualcosa come
+Perciò crea un po' di confusione il fatto che Git abbia un comando `mv`. Se vuoi rinominare un file in Git, puoi lanciare qualcosa come
$ git mv file_from file_to
-e questo lavora bene. Infatti, se lanci qualcosa come questo e guardi lo stato, vedrai che Git considera il file rinominato:
+e questo funziona bene. Infatti, se lanci qualcosa come questo e guardi lo stato, vedrai che Git considera il file rinominato:
$ git mv README.txt README
$ git status
@@ -412,9 +416,9 @@ Ovviamente, questo è equivalente a lanciare qualcosa come:
$ git rm README.txt
$ git add README
-Git capisce implicitamente che è stato rinominato, così non è un problema rinominare un file in questo modo o con il comando `mv`. L'unica reale differenza è che `mv` è un solo comando invece di tre — non è conveniente. Più importante è che tu puoi usare qualsiasi strumento per rinominare un file, ed aggiungere/togliere poi prima di un commit.
+Git capisce implicitamente che è stato rinominato, così non è un problema rinominare un file in questo modo o con il comando `mv`. L'unica reale differenza è che `mv` è un solo comando invece di tre — è un comando di convenienza. Più importante è che tu puoi usare qualsiasi strumento per rinominare un file, ed aggiungere/togliere più tardi, prima di un commit.
-## Vedere la storia dei commit ##
+## Vedere la Storia dei Commit ##
Dopo che hai creato un po' di commit, o se hai clonato un repository che contiene una storia di commit, probabilmente vuoi guardare indietro per vedere cosa è successo. Lo strumento base e più potente per farlo è il comando `git log`.
@@ -487,7 +491,27 @@ Una delle opzioni più utili è `-p`, che mostra l'introduzione del diff di ogni
-end
\ No newline at end of file
-Questa opzione visualizza le stessi informazioni ma direttamente seguita dal diff di ogni voce. Questo è veramente utile per la revisione del codice o per navigare velocemente in cosa è successo durante una serie di commit che i collaboratori hanno eseguito.
+Questa opzione visualizza le stessi informazioni ma direttamente seguita dal diff di ogni voce. Questo è veramente utile per la revisione del codice o per sfogliare velocemente cosa è successo in una serie di commit che un collaboratore ha aggiunto.
+
+Qualche volta è più semplice controllare i cambiamenti per parole piuttosto che per linee. Esiste un'opzione `--word-diff` disponibile in Git, che puoi aggiungere al comando `git log -p` per ottenere un word diff (differenza per parole, ndt) invece del normale diff linea per linea. Il formato Word diff è piuttosto inutile quando applicato al codice sorgente, ma diviene utile quando applicato a grandi file di testo, come libri o la tua dissertazione. Ecco un esempio:
+
+ $ git log -U1 --word-diff
+ commit da734f4151c0bf92798edd67fb571f86ab4179e6
+ Author: Jed Hartman <jhartman@google.com>
+ Date: Tue Mar 19 18:00:35 2013 -0700
+
+ Added a missing "in" to a sentence.
+
+ diff --git a/en/01-chapter2.markdown b/en/01-chapter2.markdown
+ index 879e48c..a992ff3 100644
+ --- a/en/01-chapter2.markdown
+ +++ b/en/01-chapter2.markdown
+ @@ -553,3 +553,3 @@ You may be wondering what the difference is
+
+ This option adds a nice little ASCII graph showing your branch and merge history, which we can see {+in+} our copy of the Grit project repository:
+
+Come puoi vedere, non ci sono linee aggiunte o rimosse in questo output come in un normale diff. Invece i cambiamenti sono mostrati sulla linea. Puoi vedere la parola racchiusa in `{+ +}` (parole rimosse sarebbe state mostrate come `[-removed-]`). Potresti anche volere ridurre le solite tre linee di contesto nell'output di diff a solo una linea, dato che il contesto è ora costituito da parole, non linee. Puoi farlo con `-U1` come abbiamo fatto nell'esempio qui sopra.
+
Puoi anche usare una serie di opzioni di riassunto con `git log`. Per esempio, se vuoi vedere alcune statistiche brevi per ogni commit, puoi usare l'opzione `--stat`:
$ git log --stat
@@ -554,7 +578,7 @@ La Tabella 2-1 elenca alcune delle opzioni più utili da usare.
%cr Data di chi ha fatto il commit, relativa
%s Oggetto
-Sarai sorpreso dalla differenza tra _author_ (l'autore) e _committer_ (chi ha eseguito il commit). L'autore è la persona che originariamente ha scritto il lavoro, mentre chi ha eseguito il commit è la persona che per ultima ha applicato il lavoro. Così, se invii una patch ad un progetto ed uno dei membri del progetto applica la patch, entrambi sarete riconosciuti — tu sei l'autore ed il membro del progetto chi ha eseguito il commit. Scopriremo meglio questa distinzione nel Capitolo 5.
+Sarai sorpreso dalla differenza tra _author_ (l'autore) e _committer_ (chi ha eseguito il commit). L'autore è la persona che ha scritto originariamente il lavoro, mentre chi ha eseguito il commit è la persona che per ultima ha applicato il lavoro. Così, se invii una patch ad un progetto ed uno dei membri del progetto applica la patch, entrambi sarete riconosciuti — tu come l'autore ed il membro del progetto come colui il quale ha eseguito il commit. Scopriremo meglio questa distinzione nel Capitolo 5.
Le opzioni oneline e format sono particolarmente utili con un'altra opzione `log` chiamata `--graph`. Questa opzione aggiunge un grafico ASCII carino che mostra le diramazioni e le unioni della storia, che possiamo vedere nella copia del repository del progetto Grit:
@@ -570,10 +594,11 @@ Le opzioni oneline e format sono particolarmente utili con un'altra opzione `log
* d6016bc require time for xmlschema
* 11d191e Merge branch 'defunkt' into local
-Queste sono solo alcune opzioni semplici per la formattazione dell'output di `git log` — ce ne sono altri. La tabella 2-2 elenca le opzioni che abbiamo visto prima e altre opzioni comunemente usate che possono essere utili per cambiare l'output del comando log.
+Queste sono solo alcune opzioni semplici per la formattazione dell'output di `git log` — ce ne sono altre. La tabella 2-2 elenca le opzioni che abbiamo visto prima e altre opzioni comunemente usate che possono essere utili per cambiare l'output del comando log.
Opzione Descrizione
-p Mostra la patch introdotta per ogni commit.
+ --word-diff Mostra la patch nel formato word diff.
--stat Mostra le statistiche per i file modificati in ogni commit.
--shortstat Mostra solo le linee cambiate/inserite/cancellate dal comando --stat.
--name-only Mostra la lista dei file modificati dopo le informazione del commit.
@@ -582,10 +607,11 @@ Queste sono solo alcune opzioni semplici per la formattazione dell'output di `gi
--relative-date Mostra la data in un formato relativo (per esempio, "2 week ago", "2 settimane fa") invece di usare l'intero formato della data.
--graph Mostra un grafico ASCII dei rami e delle unioni della storia accando all'output di log.
--pretty Mostra i commit in un formato alternativo. L'opzione include oneline, short, full, fuller, e format (dove hai specificato la tua formattazione).
+ --oneline Un'opzione di convenienza abbreviazione per `--pretty=oneline --abbrev-commit`.
-### Limitare l'output di Log ###
+### Limitare l'Output di Log ###
-Oltre alle opzioni per la formattazione dell'output, git log accetta un numero di opzioni di limitazione — cioè, opzioni che ti permettono di vedere solo alcuni commit. Hai già visto una opzione del genere — l'opzione `-2`, che mostra solamente gli ultimi due commit. Infatti, puoi fare `-<n>`, dove `n` è un intero per vedere gli ultimi `n` commit. In realtà, non userai spesso questa possibilità, perché Git di base presenta tutti gli output tramite una pagina così vedrai solamente una pagina di log al momento.
+Oltre alle opzioni per la formattazione dell'output, git log accetta un numero di opzioni di limitazione — cioè, opzioni che ti permettono di vedere solo alcuni commit. Hai già visto una opzione del genere — l'opzione `-2`, che mostra solamente gli ultimi due commit. Infatti, puoi fare `-<n>`, dove `n` è un intero per vedere gli ultimi `n` commit. In realtà, non userai spesso questa possibilità, perché Git di base veicola tutti gli output attraverso un impaginatore così vedrai solamente una pagina di log alla volta.
Ovviamente, le opzioni di limitazione temporali come `--since` e `--until` sono molto utili. Per esempio, questo comando prende la lista dei commit fatti nelle ultime due settimane:
@@ -593,9 +619,9 @@ Ovviamente, le opzioni di limitazione temporali come `--since` e `--until` sono
Questo comando funziona con molti formati — puoi specificare una data (“2008-01-15”) o una data relativa come “2 years 1 day 3 minutes ago”.
-Puoi inoltre filtrare l'elenco dei commit che corrispondono a dei criteri di ricerca. L'opzione `--author` ti permette di filtrare uno specifico autore e l'opzione `--grep` permette di cercare fra delle parole chiavi nei messaggi dei commit. (Nota che se vuoi specificare sia le opzioni author e grep, devi aggiungere `--all-match` o il comando ricercherà i commit sia di uno sia di quell'altro.)
+Puoi inoltre filtrare l'elenco dei commit che corrispondono a dei criteri di ricerca. L'opzione `--author` ti permette di filtrare uno specifico autore e l'opzione `--grep` permette di cercare delle parole chiave nei messaggi dei commit. (Nota che se vuoi specificare sia le opzioni author e grep, devi aggiungere `--all-match` o il comando ricercherà i commit sia di uno sia di quell'altro.)
-L'ultima opzione di filtro veramente utile da passare a `git log` è path. Se specifichi una directory o un nome di file, puoi limitare l'output del log ai commit che introducono modifiche a questi file. E' sempre l'ultima opzione fornita ed è generalmente preceduta dal doppio meno (`--`) per separare i path dalle opzioni.
+L'ultima opzione di filtro veramente utile da passare a `git log` è un percorso. Se specifichi una directory o un nome di file, puoi limitare l'output del log ai commit che introducono modifiche a questi file. E' sempre l'ultima opzione fornita ed è generalmente preceduta dal doppio meno (`--`) per separare i path dalle opzioni.
Nella tabella 2-3 vediamo una lista di riferimento di queste e di altre opzioni comuni.
@@ -619,7 +645,7 @@ Per esempio, se vuoi vedere quali commit modificano i file nella storia del codi
Ci sono circa 20,000 commit nella storia del codice sorgente di git, questo comando mostra 6 righe corrispondenti ai termini di ricerca.
-### Usare una GUI per visualizzare la storia ###
+### Usare una GUI per Visualizzare la Storia ###
Se vuoi usare uno strumento più grafico per visualizzare la storia dei tuoi commit, puoi vedere un programma in Tck/Tk chiamato gitk che è distribuito con Git. Gitk è fondamentalmente uno strumento visuale come `git log`, e accetta circa tutte le opzioni di filtro che `git log` ha. Se digiti gitk dalla riga di comando del tuo progetto, dovresti vedere qualcosa di simile alla Figura 2-2.
@@ -628,17 +654,17 @@ Figura 2-2. Il visualizzatore della storia gitk.
Puoi vedere la storia dei commit nella metà alta della finestra con un grafico genealogico. La finestra di diff nella metà inferiore mostra i cambiamenti introdotti ad ogni commit che selezioni.
-## Annullare le cose ##
+## Annullare le Cose ##
-Ad ogni stadio potresti voler annullare qualcosa. Qui, vedremo alcuni strumenti fondamentali per annullare i cambiamenti che hai fatto. Attenzione, perché non sempre puoi annullare alcuni annullamenti. Questa è una delle aree in Git dove puoi perdere qualche lavoro se sbagli.
+Ad ogni stadio potresti voler annullare qualcosa. Qui, vedremo alcuni strumenti fondamentali per annullare i cambiamenti che hai fatto. Attenzione, perché non sempre puoi invertire alcuni annullamenti. Questa è una delle aree in Git dove puoi perdere qualche lavoro se sbagli.
-### Modifica il tuo ultimo commit ###
+### Modificare il Tuo Ultimo Commit ###
-Uno degli annullamenti comuni è quando invii troppo presto un commit e magari dimentichi di aggiungere alcuni file, o ti dimentichi di inserire un messaggio. Se provi nuovamente questo commit, puoi rilanciarlo con l'opzione `--amend`:
+Uno degli annullamenti comuni avviene quando invii troppo presto un commit e magari dimentichi di aggiungere alcuni file, o sbagli il messaggio di commit. Se vuoi provare nuovamente questo commit, puoi lanciare commit con l'opzione `--amend`:
$ git commit --amend
-Questo comando prende la tua area di parcheggio e la usa per il commit. Se non hai fatto cambiamenti dal tuo ultimo commit (per esempio, lanci questo comando subito dopo il tuo commit precedente), allora il tuo snapshot sarà esattamente uguale e potrai cambiare il tuo messaggio di commit.
+Questo comando prende la tua area di stage e la usa per il commit. Se non hai fatto cambiamenti dal tuo ultimo commit (per esempio, lanci questo comando subito dopo il tuo commit precedente), allora il tuo snapshot sarà esattamente uguale e potrai cambiare il tuo messaggio di commit.
L'editor per il messaggio del commit apparirà, ma già contiene il messaggio del commit precedente. Puoi modificare il messaggio come sempre, ma sovrascriverà il commit precedente.
@@ -650,9 +676,9 @@ Come esempio, se fai il commit e poi realizzi di aver dimenticato un cambiamento
Tutti e tre i comandi finisco in un singolo commit — il secondo commit riscrive il risultato del primo.
-### Disimpegnare un file parcheggiato ###
+### Disimpegnare un File Staged ###
-Le prossime due sezioni mostrano come gestire le modifiche della tua area di parcheggio (area di stage) e della directory di lavoro. La parte divertente è che il comando che usi per determinare lo stato di queste due aree ricorda come annullare i cambiamenti fatti. Per esempio, supponiamo che hai modificato due file e vuoi inviarli come modifiche separate, ma accidentalmente digiti `git add *` e li parcheggi entrambi. Come puoi disimpegnare uno dei due? Il comando `git status` ti ricorda:
+Le prossime due sezioni mostrano come gestire le modifiche della tua area di stage e della directory di lavoro. La parte divertente è che il comando che usi per determinare lo stato di queste due aree ricorda come annullare i cambiamenti fatti. Per esempio, supponiamo che hai modificato due file e vuoi inviarli come modifiche separate, ma accidentalmente digiti `git add *` e li parcheggi entrambi. Come puoi disimpegnare uno dei due? Il comando `git status` ti ricorda:
$ git add .
$ git status
@@ -684,9 +710,9 @@ Ora il testo sotto “Changes to be committed”, dice di usare `git reset HEAD
Il comando è un po' strano, ma funziona. Il file benchmarks.rb è modificato ma non parcheggiato.
-### Annullare la modifica ad un file ###
+### Annullare le Modifiche di un File Modificato ###
-Come fare se hai realizzato che non vuoi più tenere le modifiche che hai fatto al file benchmarks.rv? Come puoi annullarle facilmente — ritornare a come era al tuo ultimo commit (o alla clonazione iniziale, o come lo avevi nella tua directory di lavoro)? Fortunatamente, `git status` ci dice come farlo. Nell'ultimo output di esempio, l'area di unstage (file non parcheggiati) assomiglia a:
+Come fare se hai realizzato che non vuoi più tenere le modifiche che hai fatto al file `benchmarks.rb`? Come puoi annullarle facilmente — ritornare a come era al tuo ultimo commit (o alla clonazione iniziale, o come lo avevi nella tua directory di lavoro)? Fortunatamente, `git status` ci dice come farlo. Nell'ultimo output di esempio, l'area di unstage (file non parcheggiati) assomiglia a:
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
@@ -706,16 +732,16 @@ Ci dice abbastanza esplicitamente come annullare le modifiche fatte (al limite,
# modified: README.txt
#
-Puoi vedere come le modifiche sono state annullate. Dovresti inoltre realizzare che è un comando pericoloso: ogni cambiamento fatto al file è sparito — semplicemente hai copiato un altro file su di esso. Non usare mai questo comando a meno che non sai assolutamente cosa stai facendo. Se hai bisogno di riprenderlo in qualche modo, vai nei capitoli successivi sullo stashing e branching; queste sono generalmente le vie migliori da seguire.
+Puoi vedere come le modifiche sono state annullate. Dovresti inoltre realizzare che è un comando pericoloso: ogni cambiamento fatto al file è sparito — semplicemente hai copiato un altro file su di esso. Non usare mai questo comando a meno che non sai assolutamente che non vuoi il file. Se hai bisogno solamente di toglierlo di torno, vedremo ripostigli e ramificazioni nei capitoli successivi ; queste sono generalmente le vie migliori da seguire.
-Ricorda, qualsiasi cosa che è stata affidata a Git può essere recuperata. Tutti i commit che sono sui rami che sono stati cancellati o inviati con una sovra-scrizione tramite un commit `--amend` possono essere recuperati (vedi il Capitolo 9 per il recupero dei dati). Ovviamente, qualsiasi cosa che perdi e che non è stata affidata a Git non sarà più vista in futuro.
+Ricorda, qualsiasi cosa che è stata affidata a Git può quasi sempre essere recuperata. Tutti i commit che erano su rami che sono stati cancellati o sovrascritti tramite un commit `--amend` possono essere recuperati (vedi il *Capitolo 9* per il recupero dei dati). Tuttavia, qualsiasi cosa che perdi e che non è stata affidata a Git probabilmente non sarà mai più visto.
-## Lavorare con sorgenti remote ##
+## Lavorare con Sorgenti Remote ##
Per essere in grado di collaborare con un qualsiasi progetto Git, hai bisogno di sapere come amministrare il tuo repository remoto. I repository remoti sono versioni di progetti che sono ospitati in Internet o su una rete da qualche parte. Puoi averne più di uno, molti dei quali possono essere di sola lettura o di scrittura e lettura per te. Collaborare con altri implica di sapere amministrare questi repository remoti e mettere e togliere i dati a e da questi quando hai necessità di condividerli per lavoro.
Amministrare repository remoti include il sapere aggiungere repository remoti, rimuovere quelli che non sono validi, amministrare vari rami remoti e definire quando sono tracciati o meno, e altro. In questa sezione, vedremo le tecniche di amministrazione remota.
-### Visualizzare il sorgente remoto ###
+### Visualizzare la Sorgente Remota ###
Per vedere quale server remoto hai configurato, puoi lanciare il comando git remote. Questo elenca i soprannomi di ogni nodo specificato. Se hai clonato il tuo repository, dovresti al limite vedere origin — che è il nome predefinito che Git da al server che hai clonato:
@@ -733,7 +759,8 @@ Per vedere quale server remoto hai configurato, puoi lanciare il comando git rem
Puoi anche specificare `-v`, che mostra l'URL che Git ha salvato per il soprannome:
$ git remote -v
- origin git://github.com/schacon/ticgit.git
+ origin git://github.com/schacon/ticgit.git (fetch)
+ origin git://github.com/schacon/ticgit.git (push)
Se hai più di un repository remoto, il comando li elenca tutti. Per esempio, il mio repository Grit assomiglia a questo.
@@ -747,7 +774,7 @@ Se hai più di un repository remoto, il comando li elenca tutti. Per esempio, il
Questo significa che possiamo prendere i contributi da qualsiasi di questi utenti in modo facile. Ma nota che solo origin è un URL SSH, è l'unico dove posso fare il push (vedremo questa cosa nel Capitolo 4).
-### Aggiungere un repository remoto ###
+### Aggiungere un Repository Remoto ###
Ho menzionato e fornito alcune dimostrazioni, nelle sezioni precedenti, sull'aggiunta di repository remoti, ma qui scendo nello specifico. Per aggiungere un nuovo repository Git con un soprannome per riconoscerlo velocemente, avvia `git remote add [soprannome] [url]`:
@@ -771,29 +798,29 @@ Ora puoi usare la stringa pb dalla linea di comando al posto dell'intero URL. Pe
Il ramo master di Paul è accessibile localmente come `pb/master` — puoi unirlo in uno dei tuoi rami, o puoi caricare un tuo ramo locale a questo punto per ispezionarlo.
-### Prelevare ed attirare da sorgenti in remoto ###
+### Prelevare e Trarre da Sorgenti in Remoto ###
Come già visto, per ottenere i dati da un progetto remoto, puoi farlo:
$ git fetch [nome-remoto]
-Il comando va sul progetto remoto e si tira giù tutti i dati dal progetto remoto che ancora non hai. Dopo aver fatto questo, dovresti avere tutti i riferimenti ai rami da questa sorgente remota, che poi potrai fondere o ispezionare in ogni momento. (Vedremo cosa sono i rami e come usarli in maggior dettaglio al Capitolo 3.)
+Il comando va sul progetto remoto e si tira giù tutti i dati dal progetto remoto che ancora non hai. Dopo aver fatto questo, dovresti avere tutti i riferimenti ai rami da questa sorgente remota, che poi potrai fondere o ispezionare in ogni momento. (Vedremo cosa sono i rami e come usarli in maggior dettaglio al *Capitolo 3*).
-Se hai clonato un repository, il comando automaticamente aggiunge un repository remoto sotto il nome origin. Così, `git fetch origin` preleva ogni lavoro che è stato inserito su quel server da quando hai fatto la clonazione (o dall'ultimo prelievo). E' importante notare che il comando fetch mette i dati nel tuo repository locale — non unisce automaticamente e non modifica alcun file su cui tu stai lavorando. Devi eseguire la fusione manualmente nel tuo lavoro, quando sei pronto.
+Se hai clonato un repository, il comando automaticamente aggiunge un repository remoto sotto il nome origin. Così, `git fetch origin` preleva ogni lavoro che è stato inserito su quel server da quando hai fatto la clonazione (o dall'ultimo prelievo). E' importante notare che il comando `fetch` mette i dati nel tuo repository locale — non unisce automaticamente e non modifica alcun file su cui tu stai lavorando. Devi eseguire la fusione manualmente nel tuo lavoro, quando sei pronto.
-Se hai un ramo impostato per tracciare un ramo remoto (vedi la prossima sezione e il Capitolo 3 per maggiori informazioni), puoi usare il comando `git pull` per prelevare automaticamente e poi fondere un ramo remoto nel ramo corrente. Questo è un modo più facile e comodo di lavorare; e in modo predefinito, il comando `git clone` automaticamente imposta il tuo ramo locale master per tracciare il ramo remoto master del server che hai clonato (assumendo che il sorgente remoto ha un ramo master). Lanciare `git pull` generalmente preleva i dati dal server di origine clonato e automaticamente prova a fondere il codice con il codice su cui stai lavorando.
+Se hai un ramo impostato per tracciare un ramo remoto (vedi la prossima sezione e il Capitolo 3 per maggiori informazioni), puoi usare il comando `git pull` per prelevare automaticamente e poi fondere un ramo remoto nel ramo corrente. Questo è un modo più facile e comodo di lavorare; e in modo predefinito, il comando `git clone` automaticamente imposta il tuo ramo locale master per tracciare il ramo remoto master del server che hai clonato (assumendo che il sorgente remoto abbia un ramo master). Lanciare `git pull` generalmente preleva i dati dal server di origine clonato e automaticamente prova a fondere il codice con il codice su cui stai lavorando.
-### Inserire nel sorgente remoto ###
+### Inserire nella Sorgente Remota ###
-Quando hai il tuo progetto al punto che lo vuoi condividere, devi metterlo (fare il push) online (in upstream). Il comando per fare questo è semplice: `git push [nome-remoto] [nome-ramo]`. Se vuoi fare il push del tuo ramo master al tuo server `origin` (ancora, generalmente con la clonazione sono impostati entrambi questi nomi automaticamente), puoi lanciare il push per mettere il tuo lavoro sul server:
+Quando hai il tuo progetto al punto in cui lo vuoi condividere, devi inviarlo a monte (push upstream). Il comando per fare questo è semplice: `git push [nome-remoto] [nome-ramo]`. Se vuoi fare il push del tuo ramo master al tuo server `origin` (ancora, generalmente con la clonazione sono impostati entrambi questi nomi automaticamente), puoi lanciare il push per mettere il tuo lavoro sul server:
$ git push origin master
-Questo comando funziona solamente se hai fatto una clonazione da un server in cui hai i permessi di scrittura e se nessuno ha fatto un push nel mentre. Se tu o qualcuno clona un repository nello stesso momento e fanno il push in upstream, il tuo push verrà rigettato. Devi prima scaricare il loro lavoro ed incorporarlo nel tuo per poter inviare le tue modifiche. Vedi il Capitolo 3 per maggiori dettagli ed informazioni su come fare il push su server remoti.
+Questo comando funziona solamente se hai fatto una clonazione da un server in cui hai i permessi di scrittura e se nessuno ha inviato dati nel mentre. Se tu e qualcun altro clonate un repository nello stesso momento ed essi inviano i dati, e poi tu invii i dati, il tuo invio verrà gustamente rifiutato. Devi prima scaricare il loro lavoro ed incorporarlo nel tuo per poter inviare le tue modifiche. Vedi il *Capitolo 3* per maggiori dettagli ed informazioni su come fare il push su server remoti.
-### Ispezionare un sorgente remoto ###
+### Ispezionare una Sorgente Remota ###
-Se vuoi vedere più informazioni su una sorgente remota in particolare, puoi usare il comando `git remote show [nome-remoto]`. Se lanci il comando con un soprannome particolare, come `origin`, avrai qualcosa di simile a questo:
+Se vuoi vedere più informazioni su di una sorgente remota in particolare, puoi usare il comando `git remote show [nome-remoto]`. Se lanci il comando con un soprannome particolare, come `origin`, avrai qualcosa di simile a questo:
$ git remote show origin
* remote origin
@@ -804,9 +831,9 @@ Se vuoi vedere più informazioni su una sorgente remota in particolare, puoi usa
master
ticgit
-Questo elenca tutti gli URL del repository remoto oltre che alle informazioni sui rami tracciati. Il comando fortunatamente ti dirà che sei sul ramo principale e se lanci `git pull`, questo automaticamente unirà il ramo master sul server remoto dopo aver prelevato tutte le referenze remote. Inoltre elencherà le referenze che saranno scaricate.
+Questo elenca tutti gli URL del repository remoto oltre che alle informazioni sui rami tracciati. Il comando utilmente ti dirà che sei sul ramo principale e se lanci `git pull`, questo automaticamente unirà il ramo master sul server remoto dopo aver prelevato tutte i riferimenti remoti. Inoltre elencherà i riferimenti che ha scaricato.
-Questo è un semplice esempio che potrai incontrare. Quando usi moltissimo Git, ovviamente, potrai vedere molte informazioni da `git remote show`:
+Questo è un semplice esempio che potrai incontrare. Quando usi moltissimo Git, tuttavia, potrai vedere molte più informazioni da `git remote show`:
$ git remote show origin
* remote origin
@@ -830,11 +857,11 @@ Questo è un semplice esempio che potrai incontrare. Quando usi moltissimo Git,
Local branch pushed with 'git push'
master:master
-Questo comando mostra quale ramo è automaticamente caricato quando lanci `git push` su certe diramazioni. Inoltre ti mostrerà quali rami remoti sul server che ancora non possiedi, quali rami remoti possiedi e che saranno rimossi dal server, e le diramazioni che saranno automaticamente unite quando lancerai `git pull`.
+Questo comando mostra quale rame è automaticamente caricato quando lanci `git push` su certe diramazioni. Inoltre ti mostrerà quali rami remoti sul server che ancora non possiedi, quali rami remoti possiedi e che saranno rimossi dal server, e le diramazioni che saranno automaticamente unite quando lancerai `git pull`.
-### Rimuovere e rinominare sorgenti remote ###
+### Rimuovere e Rinominare Sorgenti Remote ###
-Se vuoi rinominare una referenza, nelle nuove versioni di Git, puoi lanciare `git remote rename` per cambiare il soprannome di un sorgete remoto. Per esempio, se vuoi rinominare `pb` in `paul`, puoi farlo con `git remote rename`:
+Se vuoi rinominare un riferimento, nelle nuove versioni di Git, puoi lanciare `git remote rename` per cambiare il soprannome di una sorgente remota. Per esempio, se vuoi rinominare `pb` in `paul`, puoi farlo con `git remote rename`:
$ git remote rename pb paul
$ git remote
@@ -843,27 +870,27 @@ Se vuoi rinominare una referenza, nelle nuove versioni di Git, puoi lanciare `gi
Vale la pena ricordare che questo cambia anche i nomi dei rami remoti. Quello che prima era riferito a `pb/master` ora è `paul/master`.
-Se vuoi rimuovere una referenza per una qualche ragione — hai spostato il server o non stai più usando un mirror particolare, o magari un collaboratore non collabora più — puoi usare `git remote rm`:
+Se vuoi rimuovere un riferimento per una qualche ragione — hai spostato il server o non stai più usando un mirror particolare, o magari un collaboratore non collabora più — puoi usare `git remote rm`:
$ git remote rm paul
$ git remote
origin
-### Tagging ###
+### Etichettare ###
-Come la maggior parte dei VCS, Git ha la possibilità di aggiungere dei tag, dei riferimenti, a dei punti specifici, che sono importanti, della storia. Generalmente, le persone usano questa funzionalità per marcare i punti di rilascio (v1.0, e così via). In questa sezione, imparerai come elencare i tag disponibili, come crearne di nuovi, e i differenti tipi di tag esistenti.
+Come la maggior parte dei VCS, Git ha la possibilità di contrassegnare (tag, ndt) dei punti specifici della storia come importanti. Generalmente, le persone usano questa funzionalità per marcare i punti di rilascio (v1.0, e così via). In questa sezione, imparerai come elencare le etichette disponibili, come crearne di nuove, ed i differenti tipi di etichette esistenti.
-### Elencare i propri tag ###
+### Elencare le Proprie Etichette ###
-Elencare i tag disponibili in Git è facilissimo. Semplicemente digita `git tag`:
+Elencare le etichette disponibili in Git è facilissimo. Semplicemente digita `git tag`:
$ git tag
v0.1
v1.3
-Questo comando elenca i tag in ordine alfabetico; l'ordine con il quale compaiono non è realmente importante.
+Questo comando elenca le etichette in ordine alfabetico; l'ordine con il quale compaiono non è realmente importante.
-Puoi inoltre cercare i tag con un pattern specifico. Il repo sorgente di Git, per esempio, contiene più di 240 tag. Se sei solo interessato a vedere quelli della serie 1.4.2, puoi lanciare:
+Puoi inoltre cercare le etichette con uno schema specifico. Il repository sorgente di Git, per esempio, contiene più di 240 etichette. Se sei solo interessato a vedere quelli della serie 1.4.2, puoi lanciare:
$ git tag -l 'v1.4.2.*'
v1.4.2.1
@@ -871,13 +898,13 @@ Puoi inoltre cercare i tag con un pattern specifico. Il repo sorgente di Git, pe
v1.4.2.3
v1.4.2.4
-### Creare tag ###
+### Creare Etichette ###
-Git usa due principali tipi di tag: lightweight (semplificati) e annotated (commentati). Un tag lightweight è molto simile ad un ramo che non è cambiato — è semplicemente un riferimento ad uno specifico commit. I tag annotated, tuttavia, sono salvati come oggetti nel database Git. Ne viene calcolato il checksum; contengono il nome, l'e-mail e la data di chi ha inserito il tag; hanno un messaggio; e possono essere firmati e verificati con GNU Privacy Guard (GPG). E' generalmente raccomandato creare tag annotated così puoi avere tutte queste informazioni; ma se vuoi temporaneamente inserire un tag e per qualche ragione non vuoi avere queste informazioni, i lightweight tag, o tag semplificati, sono ancora disponibili.
+Git usa due principali tipi di etichette: lightweight (semplificate, ndt) e annotated (commentate, ndt). Un'etichetta lightweight è molto simile ad un ramo che non è cambiato — è semplicemente un riferimento ad uno specifico commit. Le etichette annotated, tuttavia, sono salvate come oggetti nel database Git. Ne viene calcolato il checksum; contengono il nome, l'e-mail e la data di chi ha inserito l'etichetta; hanno un messaggio; e possono essere firmati e verificati con GNU Privacy Guard (GPG). É generalmente raccomandato creare etichette annotated così puoi avere tutte queste informazioni; ma se vuoi temporaneamente inserire un'etichetta e per qualche ragione non vuoi avere queste informazioni, le etichette lightweight sono ancora disponibili.
-### Annotated tag (tag commentati) ###
+### Etichette Annotated ###
-Creare un tag annotated in Git è semplice. La via più facile è specificare `-a` quando si lancia il comando `tag`:
+Creare un'etichetta annotated in Git è semplice. La via più facile è specificare `-a` quando si lancia il comando `tag`:
$ git tag -a v1.4 -m 'my version 1.4'
$ git tag
@@ -885,9 +912,9 @@ Creare un tag annotated in Git è semplice. La via più facile è specificare `-
v1.3
v1.4
-`-m` specifica il messaggio, che è salvato con il tag. Se non specifichi un messaggio per i tag annotated, Git lancerà il tuo editor così potrai inserirlo.
+`-m` specifica il messaggio, che è salvato con l'etichetta. Se non specifichi un messaggio per una etichetta annotated, Git lancerà il tuo editor così potrai inserirlo.
-Puoi vedere i dati del tag assieme al commit in cui è stato inserito il tag con il comando `git show`:
+Puoi vedere i dati dell'etichetta assieme al commit in cui è stato inserito l'etichetta con il comando `git show`:
$ git show v1.4
tag v1.4
@@ -902,18 +929,18 @@ Puoi vedere i dati del tag assieme al commit in cui è stato inserito il tag con
Merge branch 'experiment'
-Questo mostra le informazioni di chi ha eseguito il tag, la data del commit del tag, ed il messaggio prima di mostrare le informazioni del commit.
+Questo mostra le informazioni di chi ha eseguito l'etichetta, la data del commit della stessa, ed il messaggio prima di mostrare le informazioni del commit.
-### Firmare i tag ###
+### Firmare le Etichette ###
-Puoi anche firmare i tuoi tag con GPG, assumendo che tu hai una chiave privata. Tutto quello che devi fare è usare `-s` invece di `-a`:
+Puoi anche firmare le tue etichette con GPG, assumendo che tu abbia una chiave privata. Tutto quello che devi fare è usare `-s` invece di `-a`:
$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon <schacon@gee-mail.com>"
1024-bit DSA key, ID F721C45A, created 2009-02-09
-Se lanci `git show` su questo tag, potrai vedere la tua firma GPG in allegato ad essa:
+Se lanci `git show` su questa etichetta, potrai vedere la tua firma GPG in allegato ad essa:
$ git show v1.5
tag v1.5
@@ -935,11 +962,11 @@ Se lanci `git show` su questo tag, potrai vedere la tua firma GPG in allegato ad
Merge branch 'experiment'
-Più avanti, imparerai come verificare i tag firmati.
+Più avanti, imparerai come verificare le etichette firmate.
-### Lightweight tag (tag semplici) ###
+### Etichette Lightweight ###
-Un altro modo per marcare i commit è usare i tag lightweight. Questo è semplicemente fare il checksum del commit salvato in un file — nessun'altra informazione è mantenuta. Per creare un tag semplificato, non fornire l'opzione `-a`, `s` o `-m`:
+Un altro modo per marcare i commit è usare le etichette lightweight. Questo è semplicemente fare il checksum del commit salvato in un file — nessun'altra informazione è mantenuta. Per creare un'etichetta semplificata, non fornire l'opzione `-a`, `s` o `-m`:
$ git tag v1.4-lw
$ git tag
@@ -949,7 +976,7 @@ Un altro modo per marcare i commit è usare i tag lightweight. Questo è semplic
v1.4-lw
v1.5
-A questo punto, se lanci `git show` sul tag, non vedrai altre informazioni aggiuntive. Il comando semplicemente mostra il commit:
+A questo punto, se lanci `git show` sulla tua etichetta, non vedrai altre informazioni aggiuntive. Il comando semplicemente mostra il commit:
$ git show v1.4-lw
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
@@ -959,9 +986,9 @@ A questo punto, se lanci `git show` sul tag, non vedrai altre informazioni aggiu
Merge branch 'experiment'
-### Verificare i tag ###
+### Verificare le Etichette ###
-Per verificare i tag firmati, usa `git tag -v [nome-tag]`. Questo comando usa la verifica GPG della firma. Avrai bisogno della chiave pubblica del firmatario nel tuo portachiavi affinché funzioni correttamente:
+Per verificarele etichetta firmate, usa `git tag -v [nome-tag]`. Questo comando usa la verifica GPG della firma. Avrai bisogno della chiave pubblica del firmatario nel tuo portachiavi affinché funzioni correttamente:
$ git tag -v v1.4.2.1
object 883653babd8ee7ea23e6a5c392bb739348b1eb61
@@ -983,9 +1010,9 @@ Se non hai la chiave pubblica del firmatario, otterrai qualche cosa di simile a
gpg: Can't check signature: public key not found
error: could not verify the tag 'v1.4.2.1'
-### Inserire un tag successivamente ###
+### Inserire una Etichetta Successivamente ###
-Puoi anche marcare con tag i commit che già sono stati inviati. Supponiamo che la storia dei tuoi commit è come questa:
+Puoi anche etichettare i commit che hai già superato. Supponiamo che la storia dei tuoi commit sia come questa:
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
@@ -999,7 +1026,7 @@ Puoi anche marcare con tag i commit che già sono stati inviati. Supponiamo che
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
-Ora, supponiamo che ti sei dimenticato di mettere il tag v1.2 al tuo progetto, che è al commit "updated rakefile". Puoi aggiungerlo successivamente. Per marcare questo commit, devi specificare il checksum (o parte di esso) del commit alla fine del comando:
+Ora, supponiamo che ti sia dimenticato di mettere l'etichetta v1.2 al tuo progetto, che è al commit "updated rakefile". Puoi aggiungerlo successivamente. Per marcare questo commit, devi specificare il checksum (o parte di esso) del commit alla fine del comando:
$ git tag -a v1.2 9fceb02
@@ -1026,9 +1053,9 @@ Puoi vedere che hai marcato il commit:
updated rakefile
...
-### Condividere i tag ###
+### Condividere le Etichette ###
-Di base, il comando `git push` non trasferisce i tag sui server remoti. Devi esplicitamente inviare i tag da condividere con il server dopo averli creati. Questo processo è come condividere branche remote — puoi lanciare `git push origin [nometag]`.
+Di base, il comando `git push` non trasferisce le etichette sui server remoti. Devi esplicitamente inviare le etichette da condividere con il server dopo averle create. Questo processo è come condividere rami remoti — puoi lanciare `git push origin [nometag]`.
$ git push origin v1.5
Counting objects: 50, done.
@@ -1038,7 +1065,7 @@ Di base, il comando `git push` non trasferisce i tag sui server remoti. Devi esp
To git@github.com:schacon/simplegit.git
* [new tag] v1.5 -> v1.5
-Se hai molti tag che puoi inviare tutti assieme, puoi farlo usando l'opzione `--tags` del comando `git push`. Questo trasferirà tutti i tuoi tag sul server remoto che non sono ancora presenti.
+Se hai molte etichetta che vuoi inviare tutte assieme, puoi farlo usando l'opzione `--tags` del comando `git push`. Questo trasferirà tutti le tue etichette sul server remoto che non sono ancora presenti.
$ git push origin --tags
Counting objects: 50, done.
@@ -1052,13 +1079,13 @@ Se hai molti tag che puoi inviare tutti assieme, puoi farlo usando l'opzione `--
* [new tag] v1.4-lw -> v1.4-lw
* [new tag] v1.5 -> v1.5
-Ora, quando qualcun altro clona o scarica dal tuo repository, avrà anche tutti i tuoi tag.
+Ora, quando qualcun altro clona o scarica dal tuo repository, avrà anche tutti le tue etichette.
-## Tips and Tricks ##
+## Suggerimenti e Trucchi ##
-Prima di finire questo capitolo sulle basi di Git, ecco alcuni suggerimenti e trucchi per rendere l'esperienza nell'uso di Git più semplice, facile e familiare. Molte persone usano Git senza usare questi consigli e non vogliamo riferirci a loro o presumere di usarli successivamente nel libro; ma si dovrebbero conoscere.
+Prima di finire questo capitolo sulle basi di Git, ecco alcuni suggerimenti e trucchi per rendere l'esperienza nell'uso di Git più semplice, facile e familiare. Molte persone usano Git senza usare questi suggerimenti e non ci riferiremo ad essi o presumeremo che tu li abbia usati successivamente nel libro; ma probabilmente dovresti sapere come realizzarli.
-### Auto completamento ###
+### Auto-Completamento ###
Se usi una shell Bash, Git fornisce un piacevole script di auto completamento che può essere usato. Scarica il codice sorgente di Git, e guarda nella directory `contrib/completation`; dovrebbe esserci un file chiamato `git-completation.bash`. Copia questo file nella tua directory di home e aggiungila al tuo file `.bashrc`:
@@ -1093,7 +1120,7 @@ Git non deduce il comando se si digita solo in parte. Se non si vuole scrivere l
Questo significa che, per esempio, invece di digitare `git commit`, hai solamente bisogno di scrivere `git ci`. Andando avanti con l'uso di Git, probabilmente ci saranno altri comandi che userai di frequente; in questi casi, non esitare a creare nuovi alias.
-Questa tecnica può anche essere molto utile per creare comandi che pensi non esistono. Per esempio, per correggere un problema comune in cui si incorre quando si vuole disimpegnare un file dall'area di stage, puoi aggiungere il tuo alias unstage a Git:
+Questa tecnica può anche essere molto utile per creare comandi che ritieni dovrebbero esistere. Per esempio, per correggere un problema comune in cui si incorre quando si vuole disimpegnare un file dall'area di stage, puoi aggiungere il tuo alias unstage a Git:
$ git config --global alias.unstage 'reset HEAD --'
@@ -1102,7 +1129,7 @@ Questo rende i seguenti due comandi equivalenti:
$ git unstage fileA
$ git reset HEAD fileA
-Questo sembra più pulito. E' anche comodo aggiungere il comando `last`, come:
+Questo sembra più pulito. É anche comodo aggiungere il comando `last`, come:
$ git config --global alias.last 'log -1 HEAD'
@@ -1117,10 +1144,10 @@ In questo modo puoi vedere l'ultimo commit facilmente:
Signed-off-by: Scott Chacon <schacon@example.com>
-Git semplicemente sostituisce il nuovo comando con quello che corrisponde nell'alias. Magari, vuoi avviare un comando esterno, invece dei sotto comandi Git. In questo caso, devi avviare il comando con il carattere "!". Questo è utile se stai scrivendo i tuoi strumenti di lavoro con un repository Git. Per esempio creiamo un alias `git visual` per lanciare `gitk`:
+Git semplicemente sostituisce il nuovo comando con quello che corrisponde all'alias. Magari, vuoi avviare un comando esterno, invece dei sotto comandi Git. In questo caso, devi avviare il comando con il carattere "!". Questo è utile se stai scrivendo i tuoi strumenti di lavoro con un repository Git. Per esempio creiamo un alias `git visual` per lanciare `gitk`:
$ git config --global alias.visual '!gitk'
-## Conclusione ##
+## Riassunto ##
-A questo punto, sei in grado di fare tutte le operazioni di Git base in locale — creare o clonare un repository, fare delle modifiche, parcheggiare ed inviare queste modifiche, vedere la storia di tutti i cambiamenti del repository fatti. Nel prossimo capitolo, vedremo una caratteristica di Git da suicidio (la killer feature): il suo modello di ramificazione.
+A questo punto, sei in grado di fare tutte le operazioni di Git base in locale — creare o clonare un repository, fare delle modifiche, parcheggiare ed inviare queste modifiche, vedere la storia di tutti i cambiamenti del repository fatti. Nel prossimo capitolo, vedremo una caratteristica vincente di Git: il suo modello di ramificazione.
176 it/03-git-branching/01-chapter3.markdown
View
@@ -1,21 +1,21 @@
-# Git Branching, le diramazioni #
+# Diramazioni in Git #
-Praticamente ogni VCS ha un suo modo di supportare il branching. Branching significa distanziarsi dal flusso principale di sviluppo continuando a lavorare senza correre il rischio di fare pasticci sul flusso principale. In molti strumenti VCS questo è un processo in alcuni termini dispendioso, spesso richiede la creazione di una nuova copia della directory del codice sorgente che in grandi progetti può richiedere molto tempo.
+Praticamente ogni VCS ha un suo modo di supportare le diramazioni. Diramazione significa divergere dal flusso principale di sviluppo continuando a lavorare senza correre il rischio senza pasticciare il flusso principale. In molti strumenti VCS questo è un processo per certi versi dispendioso, spesso richiede la creazione di una nuova copia della directory del codice sorgente che in grandi progetti può richiedere molto tempo.
-Molte persone fanno riferimento al modello di branching di Git indicandola come la “killer feature“, e questo certamente separa Git dagli altri VCS. Perché è così speciale? Git crea ramificazioni in modo incredibilmente semplice e leggero, permettendo operazioni di branching praticamente istantanee come lo sono anche i passaggi da un ramo ad un altro. Diversamente da molti altri VCS, Git incoraggia un sistema di lavorare che sfrutta le ramificazioni e le unioni frequentemente, anche molte volte al giorno. Capire e padroneggiare questa funzionalità mette a disposizione uno strumento potente ed unico e può letteralmente modificare il modo in cui si lavora.
+Molte persone fanno riferimento al modello di diramazioni di Git indicandola come la “caratteristica vincente“, e questo certamente separa Git dagli altri VCS. Perché è così speciale? Git crea ramificazioni in modo incredibilmente semplice e leggero, permettendo operazioni di diramazione praticamente istantanee come lo sono anche i passaggi da un ramo ad un altro. Diversamente da molti altri VCS, Git incoraggia un metodo di lavoro che sfrutta le ramificazioni e le unioni frequentemente, anche molte volte al giorno. Capire e padroneggiare questa funzionalità mette a disposizione uno strumento potente ed unico e può letteralmente modificare il modo in cui si lavora.
-## Cos'è un branch o ramo ##
+## Cos'è un Ramo ##
-Per capire realmente come Git fa il branching, dobbiamo tornare un attimo indietro ed esaminare come Git immagazzina i dati. Come ricorderai dal Capitolo 1, Git non salva i dati in una serie di piccoli cambiamenti o delta file, ma in una serie di snapshot, istantanee.
+Per capire realmente come Git sfrutta le diramazioni, dobbiamo tornare un attimo indietro ed esaminare come Git immagazzina i dati. Come ricorderai dal Capitolo 1, Git non salva i dati come una serie di cambiamenti o codifiche delta, ma come una serie di istantanee.
-Quando fai un commit con Git, Git immagazzina i commit che contengono un puntatore allo snapshot del contenuto di ciò che hai parcheggiato, l'autore ed il messaggio, e zero o più puntatori al o ai commit che sono i diretti genitori del commit: zero genitori per il primo commit, un genitore per un commit normale, e più genitori per un commit che risulta da una fusione di due o più rami.
+Quando fai un commit con Git, Git immagazzina un oggetto commit che contiene un puntatore all'istantanea del contenuto di ciò che hai parcheggiato, l'autore ed il messaggio, e zero o più puntatori al o ai commit che sono i diretti genitori del commit: zero genitori per il primo commit, un genitore per un commit normale, e più genitori per un commit che risulta da una fusione di due o più rami.
Per visualizzarli, assumiamo che tu abbia una directory con tre file, li parcheggi ed esegui il commit. Parcheggiando il checksum di ogni singolo file (abbiamo parlato dell'hash SHA-1 nel Capitolo 1), salviamo la versione del file nel repository Git (Git fa riferimento ad essi come blob), e aggiunge questi checksum all'area di staging, o di parcheggio:
$ git add README test.rb LICENSE
$ git commit -m 'initial commit of my project'
-Quando crei il commit lanciado `git commit`, Git calcola il checksum di ogni directory (in questo caso, solamente la directory radice del progetto) e salva questi tre oggetti nel repository Git. Git poi crea un commit dell'oggetto che ha i metadati ed un puntatore alla radice dell'albero del progetto in maniera da ricreare lo snapshot quando si vuole.
+Quando crei il commit lanciado `git commit`, Git calcola il checksum di ogni directory (in questo caso, solamente la directory radice del progetto) e salva questi tre oggetti nel repository Git. Git poi crea un commit dell'oggetto che ha i metadati ed un puntatore alla radice dell'albero del progetto in maniera da ricreare l'istantanea quando si vuole.
Il tuo repository Git ora contiene cinque oggetti: un blob per i contenuti di ogni singolo file nell'albero, un albero che elenca i contenuti della directory e specifica i nomi dei file che devono essere salvati come blob, e un commit con il puntatore alla radice dell'albero e a tutti i metadati del commit. Concettualmente, i dati nel tuo repository Git assomigliano alla Figura 3-1.
@@ -27,12 +27,12 @@ Se fai dei cambiamenti ed esegui il commit nuovamente, il commit successivo imma
Insert 18333fig0302.png
Figura 3-2. Dati di Git per commit multipli.
-In Git un ramo (branch) è semplicemente un puntatore ad uno di questi commit. Il nome del ramo principale in Git è master. Quando inizi a fare dei commit, li stai dando al ramo master che punterà all'ultimo commit che hai eseguito. Ogni volta che invierai un commit, lui si sposterà in avanti automaticamente.
+In Git un ramo è semplicemente un puntatore ad uno di questi commit. Il nome del ramo principale in Git è master. Quando inizi a fare dei commit, li stai dando al ramo master che punterà all'ultimo commit che hai eseguito. Ogni volta che invierai un commit, lui si sposterà in avanti automaticamente.
Insert 18333fig0303.png
Figura 3-3. Ramo che punta alla storia dei commit dei dati.
-Cosa succede se crei un nuovo ramo? Bene, fallo così creerai un nuovo puntatore su cui muoverti. Diciamo che crei un ramo chiamato testing. Lo farai con il comando `git branch`:
+Cosa succede se crei un nuovo ramo? Beh, farlo crea un nuovo puntatore che tu puoi muovere. Diciamo che crei un ramo chiamato testing. Lo farai con il comando `git branch`:
$ git branch testing
@@ -88,33 +88,33 @@ Figura 3-9. Le storie dei rami sono separate.
Dato che un ramo in Git è semplicemente un file che contiene 40 caratteri di un checksum SHA-1 del commit al quale punta, i rami si possono creare e distruggere facilmente. Creare un nuovo ramo è semplice e veloce quanto scrivere 41 byte in un file (40 caratteri ed il fine riga).
-Questo è in netto contrasto con il sistema utilizzato da molti altri VCS, che funzionano copiano tutti i file di un progetto in una seconda directory. Questo può richiedere diversi secondi o minuti, a seconda delle dimensioni del progetto, mentre in Git è un processo sempre istantaneo. Inoltre, dato che registreremo i genitori dei commit, trovare una base di unione per il merging è automaticamente già fatto ed è generalmente molto semplice da fare. Questa funzionalità aiuta ed incoraggia gli sviluppatori a creare e fare uso dei rami di sviluppo.
+Questo è in netto contrasto con il sistema utilizzato da molti altri VCS, che comporta la copia di tutti i file di un progetto in una seconda directory. Questo può richiedere diversi secondi o minuti, a seconda delle dimensioni del progetto, mentre in Git è un processo sempre istantaneo. Inoltre, dato che registreremo i genitori dei commit, trovare la base adatta per la fusione è fatto automaticamente per noi ed è generalmente molto semplice da fare. Questa funzionalità aiuta ed incoraggia gli sviluppatori a creare e fare uso dei rami di sviluppo.
Andiamo a vedere perché dovresti usarli.
-## Le basi de Branching e del Merging ##
+## Basi di Diramazione e Fusione ##
-Ora vediamo un po' di esempi di branching e merging in un flusso di lavoro che potresti seguire nella vita reale. Supponiamo questi passaggi:
+Ora vediamo un semplice esempio di diramazione e fusione in un flusso di lavoro che potresti seguire nella vita reale. Supponiamo questi passaggi:
-1. Stai facendo un lavoro in un sito web.
-2. Crei un ramo per una nuova storia su cui puoi lavorare.
+1. Lavori su un sito web.
+2. Crei un ramo per una nuova storia su cui stai lavorando.
3. Fai un po' di lavoro in questo nuovo ramo.
A questo punto, ricevi una chiamata per un problema critico e hai bisogno subito di risolvere il problema. Farai in questo modo:
1. Tornerai indietro nel tuo ramo di produzione.
-2. Creerai un ramo su cui aggiungere la soluzione.
+2. Creerai un ramo in cui aggiungere la soluzione.
3. Dopo aver testato il tutto, unirai il ramo con la soluzione e lo metterai in produzione.
4. Salterai indietro alla tua storia originaria e continuerai con il tuo lavoro.
-### Branching base ###
+### Basi di Diramazione ###
Primo, diciamo che stai lavorando sul tuo progetto e hai già un po' di commit (vedi Figura 3-10).
Insert 18333fig0310.png
Figura 3-10. Una storia di commit corta e semplice.
-Hai deciso che lavorerai alla richiesta #53 di un qualsiasi sistema di tracciamento dei problemi che la tua compagnia utilizza. Per essere chiari, Git non si allaccia a nessun particolare sistema di tracciamento; ma dato che il problema #53 è un discorso su cui vuoi lavorare, creerai un nuovo ramo su cui lavorerai. Per creare un ramo e spostarsi direttamente in esso, puoi lanciare il comando `git checkout` con `-b`:
+Hai deciso che lavorerai alla richiesta #53 di un qualsiasi sistema di tracciamento dei problemi che la tua compagnia utilizza. Per essere chiari, Git non si allaccia a nessun particolare sistema di tracciamento; ma dato che il problema #53 è un argomento specifico su cui vuoi lavorare, creerai un nuovo ramo su cui lavorare. Per creare un ramo e spostarsi direttamente in esso, puoi lanciare il comando `git checkout` con `-b`:
$ git checkout -b iss53
Switched to a new branch "iss53"
@@ -127,7 +127,7 @@ Questa è la scorciatoia per:
La Figura 3-11 illustra il risultato.
Insert 18333fig0311.png
-Figura 3-11. E' stato creato un nuovo ramo.
+Figura 3-11. É stato creato un nuovo ramo.
Lavori sul tuo sito web e fai alcuni commit. Facendo questo muoverai il ramo `iss53` avanti, perché ti sei spostato in esso (infatti, il puntatore HEAD rimanda ad esso, vedi Figura 3-12):
@@ -139,14 +139,14 @@ Figura 3-12. Il ramo iss53 è stato spostato in avanti con il tuo lavoro.
Ora ricevi la telefonata che ti avverte c'è un problema con il sito web, e devi risolverlo immediatamente. Con Git, non devi fare un deploy della tua soluzione con i cambiamenti del ramo `iss53` e non devi fare alcuno sforzo per riavvolgere le modifiche che hai fatto prima di applicare il fix a quello che è in produzione. Tutto ciò che devi fare è spostarti nel ramo master.
-Ovviamente, prima di fare questo, nota che se hai delle modifiche nella tua directory di lavoro o nell'area di parcheggio (staging) che vanno in conflitto con il ramo su cui ti vuoi spostare, Git non ti permetterà lo spostamento. E' meglio avere uno stato di lavoro pulito quando ci si sposta nei vari rami. Ci sono dei modi per aggirare questa cosa (namely, stashing e commit amending) che vedremo in seguito. Per ora, ha inviato in commit tutte le tue modifiche, così puoi spostarti nel ramo master:
+Ovviamente, prima di fare questo, nota che se hai delle modifiche nella tua directory di lavoro o nell'area di parcheggio (staging) che vanno in conflitto con il ramo su cui ti vuoi spostare, Git non ti permetterà lo spostamento. E' meglio avere uno stato di lavoro pulito quando ci si sposta nei vari rami. Ci sono dei modi per aggirare questa cosa (cioè, riporre e modificare i commit) che vedremo in seguito. Per ora, ha inviato tutte le tue modifiche, così puoi spostarti nel ramo master:
$ git checkout master
Switched to branch "master"
-A questo punto, la directory di lavoro del tuo progetto è esattamente come era prima che tu iniziassi a lavorare alla richiesta #53, e puoi concentrarti sulla soluzione al problema. Questo è un punto importante da ricordare: Git reimposta la tua directory di lavoro all'istantanea del commit eseguito quando ti sei spostato di ramo. Lui aggiunge, rimuove e modifica i file automaticamente per essere sicuro che la tua copia di lavoro sia identica al tuo ultimo commit in quel ramo.
+A questo punto, la directory di lavoro del tuo progetto è esattamente come era prima che tu iniziassi a lavorare alla richiesta #53, e puoi concentrarti sulla soluzione al problema. Questo è un punto importante da ricordare: Git reimposta la tua directory di lavoro all'istantanea del commit a cui punta il checkout. Lui aggiunge, rimuove e modifica i file automaticamente per essere sicuro che la tua copia di lavoro sia identica al tuo ultimo commit in quel ramo.
-Successivamente, hai una soluzione da creare. Crea un ramo hotfix su cui lavorare fin quando non è completo (vedi Figura 3-13):
+Successivamente, hai un hotfix da creare. Crea un ramo hotfix su cui lavorare fin quando non è completo (vedi Figura 3-13):
$ git checkout -b 'hotfix'
Switched to a new branch "hotfix"
@@ -156,7 +156,7 @@ Successivamente, hai una soluzione da creare. Crea un ramo hotfix su cui lavorar
1 files changed, 0 insertions(+), 1 deletions(-)
Insert 18333fig0313.png
-Figura 3-13. Ramo hotfix branch basato sul ramo master.
+Figura 3-13. Ramo hotfix basato sul ramo master.
Puoi avviare il tuo test, essere sicuro che la tua soluzione sia ciò che vuoi ottenere, e fonderla nel ramo master per inserirla nella fase di produzione. Puoi fare questo con il comando `git merge`:
@@ -167,7 +167,7 @@ Puoi avviare il tuo test, essere sicuro che la tua soluzione sia ciò che vuoi o
README | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
-Avrai notato la frase "Fast forward" nel merge. Dato che il commit di unione punta direttamente a monte rispetto al commit in cui ci si trova, Git muove il puntatore in avanti. Per parafrasare in un altro modo, quando provi ad unire un commit con un commit che può essere portato al primo commit della storia, Git semplifica le cose muovendo il puntatore in avanti perché non c'è un lavoro differente da fondere insieme — questo sistema è chiamato "fast forward".
+Avrai notato la frase "Fast forward" nella fusione. Dato che il commit a cui puntava il ramo unito era direttamente a monte rispetto al commit in cui ci ti trovi, Git muove il puntatore in avanti. Per dirla in un altro modo, quando provi ad unire un commit con un commit che può essere portato al primo commit della storia, Git semplifica le cose muovendo il puntatore in avanti perché non c'è un lavoro differente da fondere insieme — questo sistema è chiamato "fast forward".
I tuoi cambiamenti sono ora nell'istantanea del commit che punta al ramo `master`, e puoi utilizzare la tua modifica (vedi Figura 3-14).
@@ -193,9 +193,9 @@ Figura 3-15. Il ramo iss53 può andare avanti indipendentemente.
Non è un problema non avere il lavoro svolto nel ramo `hotfix` nei file del ramo `iss53`. Se hai bisogno di inserire le modifiche, puoi fondere il ramo `master` nel ramo `iss53` lanciando `git merge master`, o puoi aspettare di integrare queste modifiche quando deciderai ti inserire il ramo `iss53` nel ramo `master`.
-### Merging base ###
+### Basi di Fusione ###
-Supponiamo che hai deciso che il lavoro sul discorso #53 sia completo e pronto per la fusione con il ramo `master`. Per fare questo, unirai il ramo `iss53`, esattamente come la fusione precedente del ramo `hotfix`. Tutto ciò che devi fare è spostarti nel ramo in cui vuoi fare la fusione e lanciare il comando `git merge`:
+Supponiamo tu abbia deciso che il lavoro sul problema #53 sia completo e pronto per la fusione con il ramo `master`. Per fare questo, unirai il ramo `iss53`, esattamente come la fusione precedente del ramo `hotfix`. Tutto ciò che devi fare è spostarti nel ramo in cui vuoi fare la fusione e lanciare il comando `git merge`:
$ git checkout master
$ git merge iss53
@@ -203,7 +203,7 @@ Supponiamo che hai deciso che il lavoro sul discorso #53 sia completo e pronto p
README | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
-Il risultato è leggermente differente rispetto alla fusione precedente di `hotfix`. In questo caso, Git ha eseguito la fusione in tre vie, usando le due istantanee (snapshot) che puntano all'estremità del ramo e al progenitore comune dei due. La Figura 3-16 evidenza i tre snapshot che Git usa per fare la fusione di questo caso.
+Il risultato è leggermente differente rispetto alla fusione precedente di `hotfix`. In questo caso, Git ha eseguito la fusione in tre punti, usando le due istantanee che puntano all'estremità del ramo e al progenitore comune dei due. La Figura 3-16 evidenza i tre snapshot che Git usa per fare la fusione di questo caso.
Insert 18333fig0316.png
Figura 3-16. Git automaticamente identifica il miglior progenitore comune su cui basare la fusione dei rami.
@@ -219,7 +219,7 @@ Ora che il tuo lavoro è fuso, non hai più bisogno del ramo `iss53`. Puoi elimi
$ git branch -d iss53
-### Basi sui conflitti di fusione ###
+### Basi sui Conflitti di Fusione ###
Occasionalmente, questo processo non è così semplice. Se modifichi la stessa parte di uno stesso file in modo differente nei due rami che stai fondendo assieme, Git non è in grado di unirli in modo pulito. Se il tuo fix per il problema #53 modifica la stessa parte di un file di `hotfix`, avrai un conflitto di fusione che assomiglierà a qualcosa di simile a questo:
@@ -250,7 +250,7 @@ Qualsiasi cosa che ha un conflitto di fusione e non è stato risolto è elencato
</div>
>>>>>>> iss53:index.html
-Questo significa che la versione in HEAD (del ramo principale, perché è dove ti sei spostato precedentemente quando hai avviato il comando di fusione) è la parte superiore del blocco (tutto quello che sta sopra a `=======`), mentre la versione nel ramo `iss53` sarà la parte sottostante. Per risolvere il conflitto, dovrai scegliere quale parte o altro o fondere i contenuti di persona. Per esempio, puoi risolvere il conflitto sostituendo l'intero blocco con questo:
+Questo significa che la versione in HEAD (del ramo principale, perché è dove ti sei spostato precedentemente quando hai avviato il comando di fusione) è la parte superiore del blocco (tutto quello che sta sopra a `=======`), mentre la versione nel ramo `iss53` sarà la parte sottostante. Per risolvere il conflitto, dovrai scegliere una parte o l'altra oppure fondere i contenuti di persona. Per esempio, puoi risolvere il conflitto sostituendo l'intero blocco con questo:
<div id="footer">
please contact us at email.support@github.com
@@ -282,7 +282,7 @@ Puoi avviare `git status` nuovamente per verificare che tutti i conflitti sono s
# modified: index.html
#
-Se sei soddisfatto di questo, e hai verificato che tutti i conflitti sono stati messi in stage, puoi dare `git commit` per terminare la fusione. Il messaggio del commit di default assomiglierà a qualcosa tipo:
+Se sei soddisfatto di questo, e hai verificato che tutti i conflitti sono stati messi in stage, puoi dare `git commit` per terminare la fusione. Il messaggio del commit predefinito assomiglierà a qualcosa tipo:
Merge branch 'iss53'
@@ -297,18 +297,18 @@ Se sei soddisfatto di questo, e hai verificato che tutti i conflitti sono stati
Puoi modificare questo messaggio con i dettagli su come hai risolto la fusione se pensi possa tornare utile ad altri che vedranno questa unione in futuro — perché hai fatto quel che hai fatto, se non era ovvio.
-## Amministrazione dei rami ##
+## Amministrazione dei Rami ##
-Ora che hai creato, fuso ed eliminato alcuni rami, diamo un occhio ad alcuni strumenti di amministrazione dei rami che risulteranno utili quando inizierai ad usare i rami di continuo.
+Ora che hai creato, fuso ed eliminato alcuni rami, diamo un'occhiata ad alcuni strumenti di amministrazione dei rami che risulteranno utili quando inizierai ad usare i rami di continuo.
-Il comando `git branch` fa molto di più che creare ed eliminare rami. Se lo si lancia senza argomenti, otterrai una semplice lista dei rami correnti:
+Il comando `git branch` fa molto di più che creare ed eliminare rami. Se lo lanci senza argomenti, otterrai una semplice lista dei rami correnti:
$ git branch
iss53
* master
testing
-Nota il carattere `*` che premette il ramo `master`: esso indica il ramo in cui ti trovi in questo momento. Significa che se esegui un commit a questo punto, la branca `master` avanzerà con il tuo lavoro. Per vedere l'ultimo commit di ogni ramo, puoi lanciare `git branch -v`:
+Nota il carattere `*` che precede il ramo `master`: esso indica il ramo in cui ti trovi in questo momento. Significa che se esegui un commit a questo punto, il ramo `master` avanzerà con il tuo lavoro. Per vedere l'ultimo commit di ogni ramo, puoi lanciare `git branch -v`:
$ git branch -v
iss53 93b412c fix javascript issue
@@ -321,7 +321,7 @@ Un'altra opzione utile per vedere in che stato sono i tuoi rami è filtrare la l
iss53
* master
-Dato che già hai fuso precedentemente `iss53`, lo vedrai nella tua lista. Rami in questa lista senza l'`*` davanti possono generalmente essere eliminati con `git branch -d`; hai già incorporato il loro lavoro in un altro ramo, quindi non perderai niente.
+Dato che già hai fuso precedentemente `iss53`, lo vedrai nella tua lista. Rami in questa lista senza lo `*` davanti possono generalmente essere eliminati con `git branch -d`; hai già incorporato il loro lavoro in un altro ramo, quindi non perderai niente.
Per vedere tutti i rami che contengono un lavoro non ancora fuso nel ramo attuale, puoi lanciare `git branch --no-merged`:
@@ -334,61 +334,61 @@ Questo mostrerà gli altri tuoi rami. Dato che contengono lavoro che non è stat
error: The branch 'testing' is not an ancestor of your current HEAD.
If you are sure you want to delete it, run 'git branch -D testing'.
-Se vuoi realmente cancellare questo ramo e perdere il lavoro svolto, puoi forzare la cosa con `-D`, come avvisato dal messaggio di informazione.
+Se vuoi realmente cancellare questo ramo e perdere il lavoro svolto, puoi forzare la cosa con `-D`, come l'utile messaggio ti fa notare.
-## Lavorare con i rami di sviluppo ##
+## Flusso di Lavoro con le Ramificazioni ##
-Ora che hai le basi suoi rami e sulle fusioni, cosa puoi o dovresti fare con loro? In questa sezione, vedremo il modo di lavorare comune che questo sistema leggero di ramificazione rende possibile, così puoi decidere se incorporare Git nel tuo ciclo di sviluppo questo sistema di sviluppo.
+Ora che hai le basi sui rami e sulle fusioni, cosa puoi o dovresti fare con loro? In questa sezione, vedremo il modo di lavorare comune che questo sistema leggero di ramificazioni rende possibile, così puoi decidere se incorporarlo nel tuo ciclo di sviluppo questo sistema di sviluppo.
-### Rami di lunga durata ###
+### Rami di Lunga Durata ###
-Dato che Git usa un sistema semplice di fusione a tre vie, unire un ramo con un altro più volte dopo un lungo periodo è generalmente facile da fare. Questo significa che puoi avere molti rami che sono sempre aperti e che puoi usare per differenti fai del tuo ciclo di sviluppo; puoi fare fusioni regolarmente da alcune di esse in altre.
+Dato che Git usa un sistema semplice di fusione a tre vie, unire un ramo con un altro più volte dopo un lungo periodo è generalmente facile da fare. Questo significa che puoi avere molti rami che sono sempre aperti e che puoi usare per differenti fasi del tuo ciclo di sviluppo; puoi fare fusioni regolarmente da alcune di esse in altre.
-Alcuni sviluppatori Git hanno un flusso di lavoro che abbraccia questo approccio, come avere un unico codice che è interamente stabile nel loro ramo `master` — possibilmente solo codice che è o sarà rilasciato. Loro hanno poi un altro ramo parallelo chiamato sviluppo o successivo su cui lavorano o usano per i test di stabilità — non necessariamente sempre stabile, ma ogni volta che è in uno stato stabile, può essere fuso in `master`. E' usato per inserire "topic branch" (rami a tema o short-lived branche, come visto per il ramo `iss53`) nei rami principali quando sono pronti, per essere sicuri di aver passato tutti i test e non introdurre bug.
+Alcuni sviluppatori Git hanno un flusso di lavoro che abbraccia questo approccio, come avere un unico codice che è interamente stabile nel loro ramo `master` — possibilmente solo codice che è o sarà rilasciato. Essi hanno poi un altro ramo parallelo chiamato sviluppo o successivo su cui lavorano o usano per i test di stabilità — non necessariamente sempre stabile, ma ogni volta che è in uno stato stabile, può essere fuso in `master`. É usato per inserire rami a tema (rami di breve durata, come il precedente ramo `iss53`) nei rami principali quando sono pronti, per essere sicuri di aver passato tutti i test e non introdurre bug.
In realtà, stiamo parlando dello spostamento dei puntatori sulla linea dei commit eseguiti. I rami stabili saranno alla base della storia dei tuoi commit e i rami di sviluppo saranno al di sopra della storia (vedi Figura 3-18).
Insert 18333fig0318.png
Figura 3-18. I rami più stabili sono generalmente all'inizio della storia dei commit.
-E' generalmente facile pensare come un sistema di silos, dove una serie di commit gradualmente vanno in un contenitore più stabile quando sono bene testati (vedi Figura 3-19).
+É generalmente facile pensare come un sistema di silos, dove una serie di commit gradualmente vanno in un contenitore più stabile quando sono bene testati (vedi Figura 3-19).
Insert 18333fig0319.png
Figura 3-19. Può essere di aiuto pensare ai rami come dei silos.
-Puoi mantenere questa cosa per una serie di livelli di stabilità. Alcuni progetti molto grandi hanno inoltre un ramo `proposed` (proposta) o `pu` (proposed updates) che integrano rami che non sono pronti per entrare nel ramo `master` o `next`. L'idea è che i tuoi rami sono a vari livelli di stabilità; quando raggiungono un maggior livello di stabilità, sono fusi nel ramo superiore.
+Puoi mantenere questa cosa per svariati livelli di stabilità. Alcuni progetti molto grandi hanno inoltre un ramo `proposte` o `ap` (aggiornamenti proposti) che integrano rami che non sono pronti per entrare nel ramo `master` o `successivo`. L'idea è che i tuoi rami sono a vari livelli di stabilità; quando raggiungono un maggior livello di stabilità, sono fusi nel ramo superiore.
Ancora, avere rami di lunga durata non è necessario, ma a volte può essere utile, specialmente quando si ha a che fare con progetti molto grandi e complessi.
-### Rami a tema (Topic Branches) ###
+### Rami a Tema ###
-I rami a tema, o topic branches, come sempre, sono utili in progetti di ogni dimensione. Un ramo a tema è un ramo a breve vita che crei e usi per una singola funzionalità particolare o per un lavoro collegato. Questo è qualcosa che non hai mai fatto con un VCS prima perché è generalmente troppo dispendioso creare e fondere rami di sviluppo. Ma con Git è facile creare, lavorare, unire ed eliminare rami più volte al giorno.
+I rami a tema, tuttavia, sono utili in progetti di ogni dimensione. Un ramo a tema è un ramo di breve durata che crei e usi per una singola funzionalità particolare o per un lavoro collegato. Questo è qualcosa che non hai mai fatto con un VCS prima perché è generalmente troppo dispendioso creare e fondere rami di sviluppo. Ma con Git è facile creare, lavorare, unire ed eliminare rami più volte al giorno.
-Lo hai visto nell'ultima sezione per le branche `iss53` e `hotfix`. Hai fatto alcuni commit in questi rami, li hai eliminati direttamente dopo averli fusi nel ramo principale. Questa tecnica ti permette di cambiare contenuto velocemente e completamente — perché il tuo lavoro è separato in silos dove tutti i cambiamenti in quei rami avverranno li, è più facile vedere cosa è successo durante una revisione del codice o altro. Puoi lasciare li i cambiamenti per minuti, giorni o mesi e fonderli assieme quando sono pronti, indipendentemente dall'ordine con cui sono stati creati o su come si è lavorato.
+Lo hai visto nell'ultima sezione per i rami `iss53` e `hotfix`. Hai fatto alcuni commit in essi, li hai eliminati direttamente dopo averli fusi nel ramo principale. Questa tecnica ti permette di cambiare contenuto velocemente e completamente — perché il tuo lavoro è separato in silos dove tutti i cambiamenti in quei rami avverranno li, è più facile vedere cosa è successo durante una revisione del codice o altro. Puoi lasciare lì i cambiamenti per minuti, giorni o mesi e fonderli assieme quando sono pronti, indipendentemente dall'ordine con cui sono stati creati o su come si è lavorato.
Considera un esempio di lavoro (su `master`), ti sposti in un altro ramo per un problema (`iss91`), lavori su questo per un po', ti sposti in una seconda branca per provare un altro modo per risolvere il problema (`iss91v2`), torni al ramo principale e lavori su questo per un poco, e poi vai in un altro ramo per fare un lavoro che non sei sicuro sia proprio una buona idea (ramo `dumbidea`). La storia dei tuoi commit assomiglierà a qualcosa come la Figura 3-20.
Insert 18333fig0320.png
Figura 3-20. La storia dei tuoi commit con più rami.
-Ora, diciamo che hai deciso che ti piace la seconda soluzione per risolvere il problema (`iss91v2`); e hai mostrato il ramo `dumbidea` ai tuoi collaboratori, e si scopre una genialata. Puoi tornare al ramo `iss91` (perdere i commit C5 e C6) e fonderlo negli altri due. La tua storia assomiglierà alla Figura 3-21.
+Ora, diciamo che hai deciso che ti piace la seconda soluzione per risolvere il problema (`iss91v2`); e hai mostrato il ramo `dumbidea` ai tuoi collaboratori, e si scopre una genialata. Puoi gettare via il ramo `iss91` (perdendo i commit C5 e C6) e fondere gli altri due. La tua storia assomiglierà alla Figura 3-21.
Insert 18333fig0321.png
-Figura 3-21. La tua storia dopo che hai fatto la fusione in dumbidea e iss91v2.
+Figura 3-21. La tua storia dopo che hai fatto la fusione di dumbidea e iss91v2.
-E' importante ricordare che ogni volta che si fa una cosa simile le branche sono completamente separate. Quando crei rami o fai fusioni, tutto è eseguito nel tuo repository Git — nessuna comunicazione con il server è avvenuta.
+É importante ricordare che ogni volta che si fa una cosa simile i rami sono completamente separate. Quando crei rami o fai fusioni, tutto è eseguito nel tuo repository Git — nessuna comunicazione con il server è avvenuta.
-## Rami remoti ##
+## Rami Remoti ##
-I rami remoti (o Remote Branches) fanno riferimento allo stato dei tuoi rami sul repository remoto. Sono branche locali che non puoi muovere; sono spostate automaticamente ogni volta che tu fai una comunicazione in rete. I rami remoti sono come dei segnalibri per ricordarti dove i rami sul tuo repository remoto erano quando tu sei connesso l'ultima volta.
+I rami remoti sono riferimenti allo stato dei rami sui tuoi repository remoti. Sono rami locali che non puoi muovere; sono spostate automaticamente ogni volta che fai una comunicazione di rete. I rami remoti sono come dei segnalibri per ricordarti dove i rami sui tuoi repository remoti erano quando ti sei connesso l'ultima volta.
-Prendono la forma di `(remote)/(branch)`. Per esempio, se vuoi vedere cosa assomigliava il ramo `master` sul tuo ramo `origin` l'ultima volta che hai comunicato con lui, puoi controllare il ramo `origin/master`. Se stavi lavorando su un problema con un compagno ed hanno inviato un ramo `iss53`, potresti avere il ramo `iss53` in locale; ma il ramo sul server punta al commit `origin/iss53`.
+Prendono la forma di `(remote)/(branch)`. Per esempio, se vuoi vedere come appariva il ramo `master` sul tuo ramo `origin` l'ultima volta che hai comunicato con esso, puoi controllare il ramo `origin/master`. Se stavi lavorando su un problema con un compagno ed hanno inviato un ramo `iss53`, potresti avere il ramo `iss53` in locale; ma il ramo sul server punta al commit `origin/iss53`.
-Questo può un po' confondere, quindi vediamo un esempio. Diciamo che hai un server Git nella tua rete raggiungibile a `git.ourcompany.com`. Se fai una clonazione da qui, Git automaticamente lo nomina `origin` per te, effettua il pull di tutti i dati, crea un puntatore dove si trova il ramo `master` e lo nomina localmente `origin/master`; e non puoi spostarlo. Git inoltre ti da il tuo ramo `master` che parte dallo stesso punto del ramo originario `master`, così hai qualcosa da cui puoi inizierai a lavorare (vedi Figura 3-22).
+Questo può un po' confondere, quindi vediamo un esempio. Diciamo che hai un server Git nella tua rete raggiungibile a `git.ourcompany.com`. Se fai una clonazione da qui, Git automaticamente lo nomina `origin` per te, effettua il pull di tutti i dati, crea un puntatore dove si trova il ramo `master` e lo nomina localmente `origin/master`; e non puoi spostarlo. Git inoltre ti da il tuo ramo `master` che parte dallo stesso punto del ramo originario `master`, così hai qualcosa da cui puoi iniziare a lavorare (vedi Figura 3-22).
Insert 18333fig0322.png
Figura 3-22. Un clone con Git fornisce un proprio ramo principale e un puntatore origin/master al ramo principale di origine.
-Se fai del lavoro sul tuo ramo principale locale, e, allo stesso temo, qualcuno ha inviato degli aggiornamento al ramo principale di `git.ourcompany.com`, allora la tua storia si muoverà in avanti in modo differente. Inoltre, mentre non hai contatti con il tuo server di partenza, il tuo puntatore `origin/master` non si sposterà (vedi Figura 3-23).
+Se fai del lavoro sul tuo ramo principale locale, e, allo stesso temo, qualcuno ha inviato degli aggiornamenti al ramo principale di `git.ourcompany.com`, allora la tua storia si muoverà in avanti in modo differente. Inoltre, mentre non hai contatti con il tuo server di partenza, il tuo puntatore `origin/master` non si sposterà (vedi Figura 3-23).
Insert 18333fig0323.png
Figura 3-23. Lavorando in locale ed avendo qualcuno che ha inviato al server remoto qualcosa rende l'avanzamento delle storie differente.
@@ -398,21 +398,21 @@ Per sincronizzare il tuo lavoro, devi avviare il comando `git fetch origin`. Que
Insert 18333fig0324.png
Figura 3-24. Il comando git fetch aggiorna i tuoi riferimenti remoti.
-Avendo più server remoti e volendo vedere come sono i rami remoti per questi progetti esterni, assumiamo che hai un altro server Git interno che è usato solamente per lo sviluppo di un tuo team. Questo server è `git.team1.ourcompany.com`. Puoi aggiungerlo come una nuova referenza remoto al tuo progetto su cui stai lavorando avviando il comando `git remote add` come visto al Capitolo 2. Nominalo `teamone`, che sarà l'abbreviazione per tutto l'URL (vedi Figura 3-25).
+Avendo più server remoti e volendo vedere come sono i rami remoti per questi progetti esterni, assumiamo che abbia un altro server Git interno che è usato solamente per lo sviluppo di un tuo team. Questo server è `git.team1.ourcompany.com`. Puoi aggiungerlo come una nuova referenza remoto al tuo progetto su cui stai lavorando avviando il comando `git remote add` come visto al Capitolo 2. Nominalo `teamone`, che sarà l'abbreviazione per tutto l'URL (vedi Figura 3-25).
Insert 18333fig0325.png
Figura 3-25. Aggiungere un altro server remoto.
-Ora, puoi lanciare `git fetch teamone` per prelevare tutto quello che non possiedi dal server remoto `teamone`. Dato che il server è un sottoinsieme del server `origin` che già possiedi, Git non ricerca nessun dato ma imposta il ramo chiamato `teamone/master` a puntare al commit che `teamone` ha come suo ramo `master` (vedi Figura 3-26).
+Ora, puoi lanciare `git fetch teamone` per prelevare tutto quello che non possiedi dal server remoto `teamone`. Dato che il server ha un sottoinsieme dei dati del server `origin` che già possiedi, Git non va a prendere nessun dato ma imposta un ramo remoto chiamato `teamone/master` a puntare al commit che `teamone` ha come suo ramo `master` (vedi Figura 3-26).
Insert 18333fig0326.png
-Figura 3-26. Hai una referenza al ramo principale di teamone posizionato localmente.
+Figura 3-26. Hai un riferimento al ramo principale di teamone posizionato localmente.
-### Pushing ###
+### Invio ###
-Quando vuoi condividere un ramo con il mondo, hai bisogno di inviarlo su un server remoto su cui hai accesso in scrittura. I tuoi rami locali non sono automaticamente sincronizzati sul remoto in cui scrivi — devi esplicitamente dire di inviare il ramo che vuoi condividere. In questo modo, puoi usare rami privati per il lavoro che non vuoi condividere ed inviare solamente le branche su cui vuoi collaborazione.
+Quando vuoi condividere un ramo con il mondo, hai bisogno di inviarlo su di un server remoto su cui hai accesso in scrittura. I tuoi rami locali non sono automaticamente sincronizzati sul remoto in cui scrivi — devi esplicitamente dire di inviare il ramo che vuoi condividere. In questo modo, puoi usare rami privati per il lavoro che non vuoi condividere ed inviare solamente i rami su cui vuoi collaborare.
-Se hai un ramo chiamato `serverfix` su cui vuoi lavorare con altri, puoi inviarlo nello stesso modo con cui hai inviato la prima branca. Lancia `git push (remote) (branch)`:
+Se hai un ramo chiamato `serverfix` su cui vuoi lavorare con altri, puoi inviarlo nello stesso modo con cui hai inviato il primo ramo. Lancia `git push (remote) (branch)`:
$ git push origin serverfix
Counting objects: 20, done.
@@ -422,7 +422,7 @@ Se hai un ramo chiamato `serverfix` su cui vuoi lavorare con altri, puoi inviarl
To git@github.com:schacon/simplegit.git
* [new branch] serverfix -> serverfix
-Questa è una piccola abbreviazione. Git automaticamente espande il nome del ramo `serverfix` to `refs/heads/serverfix:refs/heads/serverfix`, questo significa, “Prendi il mio ramo locale serverfix e buttalo per l'aggiornamento sul ramo remoto serverfix.“ Vedremo in modo più approfondito la parte `refs/heads/` nel Capitolo 9, ma puoi generalmente lasciare perdere. Puoi anche fare `git push origin serverfix:serverfix`, che fa la stessa cosa — questo dice, “Prendi il mio serverfix e crea il serverfix remoto.“ Puoi usare questo formato per inviare rami locali in rami remoti che hanno nomi differenti. Se non vuoi chiamare il ramo remoto `serverfix`, puoi avviare `git push origin serverfix:awesomebranch` per inviare il tuo ramo locale `serverfix` in `awesomebranch` sul progetto remoto.
+Questa è una piccola abbreviazione. Git automaticamente espande il nome del ramo `serverfix` to `refs/heads/serverfix:refs/heads/serverfix`, questo significa, “Prendi il mio ramo locale serverfix ed invialo per aggiornare il ramo remoto serverfix.“ Vedremo in modo più approfondito la parte `refs/heads/` nel Capitolo 9, ma puoi generalmente lasciare perdere. Puoi anche fare `git push origin serverfix:serverfix`, che fa la stessa cosa — questo dice, “Prendi il mio serverfix e crea il serverfix remoto.“ Puoi usare questo formato per inviare rami locali in rami remoti che hanno nomi differenti. Se non vuoi chiamare il ramo remoto `serverfix`, puoi avviare `git push origin serverfix:awesomebranch` per inviare il tuo ramo locale `serverfix` in `awesomebranch` sul progetto remoto.
La prossima volta che i tuoi collaboratori preleveranno dal server, avranno un riferimento di dove si trova la versione del server di `serverfix` nel ramo `origin/serverfix`:
@@ -434,7 +434,7 @@ La prossima volta che i tuoi collaboratori preleveranno dal server, avranno un r
From git@github.com:schacon/simplegit
* [new branch] serverfix -> origin/serverfix
-E' importante notare che quando fai un prelievo di un nuovo ramo, non hai automaticamente un ramo locale modificabile. In altre parole, in questo caso, non hai un nuovo ramo `serverfix` — hai solamente il puntatore `origin/serverfix` che non puoi modificare.
+É importante notare che quando fai un prelievo di un nuovo ramo, non hai automaticamente un ramo locale modificabile. In altre parole, in questo caso, non hai un nuovo ramo `serverfix` — hai solamente il puntatore `origin/serverfix` che non puoi modificare.
Per fondere questo lavoro nel ramo corrente, puoi avviare `git merge origin/serverfix`. Se vuoi il tuo ramo `serverfix` su cui poter lavorare, puoi basarlo sul ramo remoto:
@@ -444,11 +444,11 @@ Per fondere questo lavoro nel ramo corrente, puoi avviare `git merge origin/serv
Questo ti fornirà un ramo locale da dove si trovava `origin/serverfix` su cui tu puoi iniziare a lavorare.
-### Il Tracking Branch ###
+### Rami di Monitoraggio ###
-Quando crei e ti sposti in un ramo locale partendo da un ramo remoto crei quello che viene chiamato tracking branch. Questi sono rami locali che hanno una relazione diretta con il ramo remoto. Se ti trovi su uno di questi rami e dai `git push`, Git automaticamente sa a quale server e ramo inviare i dati. Inoltre, avviando `git pull` mentre si è su uno di questi rami si prelevano tutte le referenze remote ed automaticamente si fa la fusione dei corrispondenti rami remoti.
+Quando crei e ti sposti in un ramo locale partendo da un ramo remoto crei quello che viene chiamato _ramo di monitoraggio_. Questi sono rami locali che hanno una relazione diretta con il ramo remoto. Se ti trovi su uno di questi rami e dai `git push`, Git automaticamente sa a quale server e ramo inviare i dati. Inoltre, avviando `git pull` mentre si è su uno di questi rami si prelevano tutte le referenze remote ed automaticamente si fa la fusione dei corrispondenti rami remoti.
-Quando cloni un repository, generalmente crea automaticamente un ramo `master` che traccia `origin/master`. Questo perché `git push` e `git pull` lavorano senza argomenti. Come sempre, puoi impostare altre traccie di branche che vuoi — quelle che non tracciano i rami su `origin` e non tracciano il ramo `master`. Il modo più semplice è l'esempio che hai già visto, lancia `git checkout -b [branch] [remotename]/[branch]`. Se hai una versione 1.6.2 o successiva di Git, puoi inoltre usare l'abbreviazione `--track`:
+Quando cloni un repository, generalmente crea automaticamente un ramo `master` che traccia `origin/master`. Questa è la ragione per cui `git push` e `git pull` lavorano senza argomenti dall'inizio. Tuttavia, puoi impostare altri rami di monitoraggio se vuoi — che non monitorano i rami su `origin` e non monitorano il ramo `master`. Il caso più semplice è l'esempio che hai già visto, lancia `git checkout -b [branch] [remotename]/[branch]`. Se hai una versione 1.6.2 o successiva di Git, puoi inoltre usare l'abbreviazione `--track`:
$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
@@ -462,9 +462,9 @@ Per impostare un ramo locale con un nome differente rispetto al remoto, puoi fac
Ora il tuo ramo locale sf verrà automaticamente collegato a origin/serverfix.
-### Eliminare rami remoti ###
+### Eliminazione di Rami Remoti ###
-Supponiamo che stai lavorando con un ramo remoto — dici che tu e i tuoi collaboratori abbiate finito con una funzionalità e l'avete fusa nel ramo remoto `master` (o qualsiasi ramo stabile del progetto). Puoi eliminare un ramo remoto con una sintassi abbastanza ottusa `git push [remotename] :[branch]`. Se vuoi eliminare il ramo `serverfix`, lancia il seguente comando:
+Supponiamo che tu stia lavorando con un ramo remoto — diciamo che tu e i tuoi collaboratori avete finito con una funzionalità e l'avete fusa nel ramo remoto `master` (o qualsiasi ramo stabile del progetto). Puoi eliminare un ramo remoto con una sintassi abbastanza ottusa `git push [remotename] :[branch]`. Se vuoi eliminare il ramo `serverfix`, lancia il seguente comando:
$ git push origin :serverfix
To git@github.com:schacon/simplegit.git
@@ -472,23 +472,23 @@ Supponiamo che stai lavorando con un ramo remoto — dici che tu e i tuoi collab
Boom. Non c'è più il ramo sul server. Tieni d'occhio questa pagina perché avrai bisogno di questo comando e dimenticherai facilmente la sintassi. Un modo per ricordare questo comando è richiamare la sintassi `git push [remotename] [localbranch]:[remotebranch]` che abbiamo visto precedentemente. Se lasci bianca la porzione `[localbranch]`, stai dicendo, “Non prendere niente dalla mia parte e rendila `[remotebranch]`.“
-## Rebasing##
+## Rifondazione ##
-In Git, ci sono due modi per integrare i cambiamenti da un ramo in un altro: il `merge` ed il `rebase`. In questa sezione imparerai cos'è il rebasing, come farlo, perché è uno strumento così fantastico, ed in quali casi puoi non volerlo utilizzare.
+In Git, ci sono due modi per integrare i cambiamenti da un ramo in un altro: il `merge` ed il `rebase`. In questa sezione imparerai cos'è la rifondazione, come farlo, perché è uno strumento così fantastico, ed in quali casi puoi non volerlo utilizzare.
-### Le basi del rebase ###
+### Le Basi del Rebase ###
Se torni indietro in un precedente esempio alla sezione sulla fusione (vedi Figura 3-27), puoi vedere che hai separato il tuo lavoro e hai fatto dei commit in rami differenti.
Insert 18333fig0327.png
Figura 3-27. L'inizio della divisione della storia dei commit.
-Il modo più semplice per integrare le due branche, come abbiamo visto, è il comando `merge`. Lui avvia una fusione a tre vie con le ultime due istantanee dei rami (C3 e C4) ed il più recente progenitore comune dei due (C2), creando un nuovo snapshot (e commit), come visualizzato in Figura 3-28.
+Il modo più semplice per integrare i due rami, come abbiamo visto, è il comando `merge`. Lui avvia una fusione a tre vie con le ultime due istantanee dei rami (C3 e C4) ed il più recente progenitore comune dei due (C2), creando un nuovo snapshot (e commit), come visualizzato in Figura 3-28.
Insert 18333fig0328.png
Figura 3-28. Fusione di un ramo per integrare una storia divisa.
-Tuttavia, esiste un'altra possibilità: puoi prendere una patch del cambiamento che abbiamo introdotto in C3 ed applicarla all'inizio di C4. In Git, questo è chiamato _rebasing_. E con il comando `rebase`, puoi prendere tutti i cambiamenti che sono stati inviati su un ramo ed applicarli su un altro.
+Tuttavia, esiste un'altra possibilità: puoi prendere una patch del cambiamento che abbiamo introdotto in C3 ed applicarla all'inizio di C4. In Git, questo è chiamato _rifondazione_. E con il comando `rebase`, puoi prendere tutti i cambiamenti che sono stati inviati su un ramo ed applicarli su un altro.
In questo esempio, digita quanto segue:
@@ -500,34 +500,34 @@ In questo esempio, digita quanto segue:
Questi comandi funzionano andando al progenitore comune dei due rami (uno è quello in cui ti trovi e uno è quello su cui stai facendo il rebase), ottiene il diff di ogni commit del ramo in cui ti trovi, salva le informazioni in un file temporaneo, reimposta il ramo corrente allo stesso commit del ramo su cui stai facendo il rebase, e alla fine applica ogni singolo cambiamento. La Figura 3-29 illustra questo processo.
Insert 18333fig0329.png
-Figura 3-29. Rebasing dei cambiamenti introdotti in C3 in C4.
+Figura 3-29. Rifondazione dei cambiamenti introdotti in C3 in C4.
A questo punto, puoi tornare indietro sul ramo principale e fare una fusione veloce (vedi Figura 3-30).
Insert 18333fig0330.png
-Figura 3-30. Fast-forwarding del ramo principale.
+Figura 3-30. Avanzamento veloce del ramo principale.
-Ora, lo snapshot puntato da C3' è esattamente lo stesso del puntatore nell'esempio di fusione. Non c'è differenza nel prodotto finale dell'integrazione, ma il rebasing crea una storia più pulita. Se esamini il log del ramo su cui è stato fatto il rebase, assomiglia ad una storia lineare: appare come se tutto il lavoro è stato fatto in serie, invece è stato fatto in parallelo.
+Ora, lo snapshot puntato da C3' è esattamente lo stesso del puntatore nell'esempio di fusione. Non c'è differenza nel prodotto finale dell'integrazione, ma la rifondazione crea una storia più pulita. Se esamini il log del ramo su cui è stato fatto il rebase, assomiglia ad una storia lineare: appare come se tutto il lavoro fosse stato fatto in serie, invece è stato fatto in parallelo.
A volte, farai questa cosa per essere sicuro che i tuoi commit appaiano puliti nel ramo remoto — probabilmente in un progetto a cui stai cercando di contribuire ma che non mantieni. In questo caso, fai il tuo lavoro in un ramo e poi fai il rebase in `origin/master` quando sei pronto per inviare le tue patch al progetto principale. In questo modo, gli amministratori non hanno da integrare niente — semplicemente applicano la fusione o fanno una fusione veloce.
-Nota che lo snapshot punta al commit finale, che è l'ultimo dei commit su cui è stato fatto il rebase per un rebase o il commit finale di fusione dopo un merge, è lo stesso snapshot — è solo la storia che è differente. Il rebasing applica i cambiamenti su una linea di lavoro in un'altra nell'ordine con cui sono stati introdotti, dove la fusione prende lo stato finale e fa una unione di essi.
+Nota che lo snapshot punta al commit finale, che è l'ultimo dei commit su cui è stato fatto il rebase per un rebase o il commit finale di fusione dopo un merge, è lo stesso snapshot — è solo la storia che è differente. La rifondazione applica i cambiamenti su una linea di lavoro in un'altra nell'ordine con cui sono stati introdotti, dove la fusione prende lo stato finale e fa un'unione di essi.
-### Rebase più interessante ###
+### Rebase Più Interessanti ###
-Puoi anche avere il tuo rebase su qualcosa che non è il ramo di rebase. Prendi la storia della Figura 3-31, per esempio. Hai un ramo a tema (`server`) per aggiungere delle funzioni lato server al tuo progetto, e fai un commit. Poi, ti sposti su un altro ramo per creare dei cambiamenti sul lato client (`client`) e fai dei commit. Alla fine, torni sul tuo ramo server e fai degli altri commit.
+Puoi anche avere il tuo rebase su qualcosa che non è il ramo di rebase. Prendi la storia della Figura 3-31, per esempio. Hai un ramo a tema (`server`) per aggiungere delle funzioni lato server al tuo progetto, e fai un commit. Poi, ti sposti su un altro ramo per creare dei cambiamenti sul lato client (`client`) e fai dei commit. Alla fine, torni sul tuo ramo server e fai degli altri commit.
Insert 18333fig0331.png
Figura 3-31. Una storia con un ramo a tema ed un altro ramo a tema da questo.
-Supponiamo che hai deciso che vuoi unire i tuoi cambiamenti lato client nella linea principale per un rilascio, ma non vuoi unire le modifiche lato server per testarle ulteriormente. Puoi prendere le modifiche sul client che non sono sul server (C8 e C9) ed applicarle nel ramo master usano l'opzione `--onto` di `git rebase`:
+Supponiamo che tu decida di voler unire i tuoi cambiamenti lato client nella linea principale per un rilascio, ma non vuoi unire le modifiche lato server per testarle ulteriormente. Puoi prendere le modifiche sul client che non sono sul server (C8 e C9) ed applicarle nel ramo master usano l'opzione `--onto` di `git rebase`:
$ git rebase --onto master server client
-Questo dice, “Prendi il ramo client, fai le patch a partire dall'ancora comune dei rami `client` e `server`, ed applicali in `master`.“ E' un po' complesso; ma il risultato, mostrato in Figura 3-32, è davvero interessante.
+Questo dice, “Prendi il ramo client, fai le patch a partire dall'ancora comune dei rami `client` e `server`, ed applicali in `master`.“ É un po' complesso; ma il risultato, mostrato in Figura 3-32, è davvero interessante.
Insert 18333fig0332.png
-Figura 3-32. Rebasing di un ramo a tema con un altro ramo a tema.
+Figura 3-32. Rifondazione di un ramo a tema con un altro ramo a tema.
Ora puoi fare una fusione veloce con il ramo master (vedi Figura 3-33):
@@ -535,7 +535,7 @@ Ora puoi fare una fusione veloce con il ramo master (vedi Figura 3-33):
$ git merge client
Insert 18333fig0333.png
-Figura 3-33. Fusione fast-forward con il ramo master per includere i cambiamenti del ramo client.
+Figura 3-33. Fusione ad avanzamento veloce con il ramo master per includere i cambiamenti del ramo client.
Diciamo che hai deciso di inviare il tutto nel ramo server. Puoi fare un rebase del ramo server in quello master senza dover controllarlo prima lanciando `git rebase [basebranch] [topicbranch]` — che controlla il ramo a tema (in questo caso, `server`) per te e gli applica il ramo base (`master`):
@@ -544,7 +544,7 @@ Diciamo che hai deciso di inviare il tutto nel ramo server. Puoi fare un rebase
Questo applica il tuo lavoro `server` sopra al tuo lavoro `master`, come in Figura 3-34.
Insert 18333fig0334.png
-Figura 3-34. Rebasing del ramo server sopra al ramo master.
+Figura 3-34. Rifondazione del ramo server sopra al ramo master.
Poi, puoi fare una fusione veloce con il ramo base (`master`):
@@ -559,9 +559,9 @@ Puoi rimuovere i rami `client` e `server` perché tutto il lavoro è integrato e
Insert 18333fig0335.png
Figura 3-35. Storia finale dei commit.
-### Il rischio del rebasing ###
+### I Rischio della Rifondazione ###
-Ahh, ma la bellezza del rebasing non è senza macchia, che può essere riassunta in una singola frase:
+Ahh, ma la bellezza della rifondazione non è senza macchia, che può essere riassunta in una singola frase:
**Non fare il rebase dei commit che hai inviato in un repository pubblico.**
@@ -569,7 +569,7 @@ Se segui queste linea guida è ok. Se non lo farai, le persone ti odieranno e sa
Quando fai il rebase di qualcosa, stai abbandonando i commit esistenti per crearne di nuovi che sono simili ma differenti. Se invii i commit da qualche parte e altri li hanno scaricati hanno basato il loro lavoro su questi, e tu riscrivi questi commit con `git rebase` e poi li invii nuovamente, i tuoi collaboratori dovranno fare una nuova fusione del loro lavoro e le cose saranno disordinate quando cercherai di scaricare il loro lavoro nel tuo.
-Vedi l'esempio su come funziona il rebase che hai reso pubblico e cosa può causare. Supponiamo che hai clonato un repository da un server centrale e poi hai fatto dei lavori. La storia dei tuoi commit assomiglierà alla Figura 3-36.
+Vedi l'esempio su come funziona il rebase che hai reso pubblico e cosa può causare. Supponiamo che abbia clonato un repository da un server centrale e poi abbia fatto dei lavori. La storia dei tuoi commit assomiglierà alla Figura 3-36.
Insert 18333fig0336.png
Figura 3-36. Repository clonato e del lavoro basato su questo.
@@ -584,15 +584,15 @@ Poi, la persona che ha inviato il suo lavoro decide di tornare indietro e fa un
Insert 18333fig0338.png
Figura 3-38. Qualcuno ha inviato dei commit su cui è stato fatto il rebase, abbandonando i commit che su cui avevi basato il tuo lavoro.
-A questo punto devi fondere di nuovo il tuo lavoro, e tu lo avevi già fatto. Il rebasing modifica gli hash SHA-1 di questi commit così per Git sono come dei nuovi commit, mentre di fatto hai già il lavoro C4 nel tuo repository (vedi Figura 3-39).
+A questo punto devi fondere di nuovo il tuo lavoro, e tu lo avevi già fatto. La rifondazione modifica gli hash SHA-1 di questi commit così per Git sono come dei nuovi commit, mentre di fatto hai già il lavoro C4 nel tuo repository (vedi Figura 3-39).
Insert 18333fig0339.png
Figura 3-39. Fai la fusione nello stesso lavoro con un nuovo commit di unione.
Devi fondere questo lavoro in ogni punto così puoi rimanere aggiornato con l'altro sviluppatore in futuro. Dopo che hai fatto questo, la storia dei tuoi commit contiene sia i commit C4 e C4', che hanno un hash SHA-1 differente ma introducono lo stesso lavoro e hanno lo stesso messaggio per il commit. Se lanci `git log` quando la tua storia assomiglia a questo, vedrai i due commit che hanno lo stesso autore data e messaggio, e ciò confonde. Inoltre, Se invii questa storia al server, tu reinserisci nel server centrale questi commit che hanno subito un rebase, ciò confonde ulteriormente le persone.
-Se tratti il rebasing com un modo per essere pulito e lavorare con i commit prima di inviarli, e se fai il rebase solamente dei commit che non sono mai diventati pubblici, allora la cosa è ok. Se fai il rebase dei commit che sono già stati inviati e sono pubblici, e le persone hanno basato il loro lavoro su questi commit, allora farai parte delle frustrazioni e dei problemi di questi.
+Se tratti la rifondazione com un modo per essere pulito e lavorare con i commit prima di inviarli, e se fai il rebase solamente dei commit che non sono mai diventati pubblici, allora la cosa è ok. Se fai il rebase dei commit che sono già stati inviati e sono pubblici, e le persone hanno basato il loro lavoro su questi commit, allora potresti creare dei problemi di frustazione.
## Riassunto ##
-Abbiamo visto le basi di ramificazione e di fusione in Git. Dovresti sentirti a tuo agio nel creare e spostarti in nuovi rami, spostarti fra le varie branche e fondere i rami locali insieme. Dovresti essere ingrado anche di condividere i tuoi rami su un server condiviso, lavorare con altri su rami condivisi e fare il rebase delle tue branche prima di condividerle.
+Abbiamo visto le basi di diramazione e di fusione in Git. Dovresti sentirti a tuo agio nel creare e spostarti in nuovi rami, spostarti fra i vari rami e fondere i rami locali insieme. Dovresti essere ingrado anche di condividere i tuoi rami su un server condiviso, lavorare con altri su rami condivisi e fare il rebase dei tuoi rami prima di condividerli.
355 it/04-git-server/01-chapter4.markdown
View
@@ -1,24 +1,24 @@
-# Git sul server #
+# Git sul Server #
-A questo punto, dovresti essere in grado di fare la maggior parte delle operazioni quotidiane che si fanno con Git. Tuttavia, per avere una qualsiasi collaborazione in Git, devi avere un repository remoto Git. Anche se puoi tecnicamente inviare e scaricare modifiche da repository individuali, procedere in questo modo è sconsigliato, perché se non si sta attenti, ci si può confondere abbastanza facilmente riguardo a quello su cui si sta lavorando. Inoltre, se vuoi che i tuoi collaboratori siano in grado di accedere al repository anche se non sei in linea — avere un repository comune più affidabile è spesso utile. Pertanto, il metodo preferito per collaborare con qualcuno, è quello di creare un repository intermedio a cui entrambi avete accesso per inviare e scaricare dati. Faremo riferimento a questo repository come un "server Git"; vedrai che in genere ospitare un repository Git ha bisogno di una piccola quantità di risorse, quindi raramente c'è bisogno di usare un intero server per esso.
+A questo punto, dovresti essere in grado di fare la maggior parte delle operazioni quotidiane che si fanno con Git. Tuttavia, per avere una qualsiasi collaborazione in Git, devi avere un repository remoto Git. Anche se puoi tecnicamente inviare e scaricare modifiche da repository individuali, procedere in questo modo è sconsigliato, perché se non si sta attenti, ci si può confondere abbastanza facilmente riguardo a quello su cui si sta lavorando. Inoltre, se vuoi che i tuoi collaboratori siano in grado di accedere al repository anche se non sei in linea — avere un repository comune più affidabile è spesso utile. Pertanto, il metodo preferito per collaborare con qualcuno, è quello di creare un repository intermedio a cui entrambi avete accesso per inviare e scaricare dati. Faremo riferimento a questo repository come un "server Git"; vedrai che in genere ospitare un repository Git richiede di una piccola quantità di risorse, quindi raramente c'è bisogno di usare un intero server per esso.
Avviare un server Git è semplice. In primo luogo, si sceglie quali protocolli si desidera utilizzare per comunicare con il server. La prima sezione di questo capitolo descriverà i protocolli disponibili con i pro e i contro di ciascuno. La sezione seguente spiegherà alcune impostazioni tipiche nell'utilizzo di questi protocolli e come utilizzarle nel proprio server. Infine, se non si hanno problemi ad ospitare il proprio codice su un server esterno e se non si vuole dedicare del tempo alla creazione e al mantenimento di un proprio server, si prenderà in considerazione qualche opzione per l'hosting.
Se non si ha interesse a gestire il proprio server, è possibile passare all'ultima sezione del capitolo per vedere alcune opzioni per la creazione di un account hosting e poi saltare al capitolo successivo, dove si discutono i flussi in ingresso e uscita in un ambiente distribuito per il controllo del codice sorgente.
-Un repository remoto è in genere un _bare repository_ — cioè un repository Git che non ha la cartella di lavoro. Dato che il repository viene usato solo come un punto di collaborazione, non c'è ragione di avere uno snapshot estratto dal disco; sono solo dati di Git. In termini più semplici, un repository bare è il contenuto della directory `.git` del progetto e nient'altro.
+Un repository remoto è in genere un _bare repository_ — cioè un repository Git che non ha la directory di lavoro. Dato che il repository viene usato solo come un punto di collaborazione, non c'è ragione di avere un'instatanea sul disco; sono solo dati di Git. In termini più semplici, un bare repository è il contenuto della directory `.git` del progetto e nient'altro.
-## I protocolli ##
+## I Protocolli ##
-Git può utilizzare i maggiori quattro protocolli di rete per trasferire i dati: Local, Secure Shell (SSH), Git e HTTP. Qui vedremo cosa sono e in quali circostanze di base si vogliono (o non si vogliono) usare.
+Git può utilizzare i maggiori quattro protocolli di rete per trasferire i dati: Locale, Secure Shell (SSH), Git e HTTP. Qui vedremo cosa sono e in quali circostanze di base si vogliono (o non si vogliono) usare.
-E' importante notare che, ad eccezione dei protocolli HTTP, tutti questi richiedono che Git sia installato e funzionante sul server.
+É importante notare che, ad eccezione dei protocolli HTTP, tutti questi richiedono che Git sia installato e funzionante sul server.
-### Il protocollo Local ###
+### Il Protocollo Locale ###
-Quello più semplice è il _protocollo locale_ (Local protocol), in cui il repository remoto è in un'altra directory sul disco. Questo è spesso utilizzato se ciascuno nel tuo team ha un accesso ad un file system condiviso come NFS, o nel caso meno probabile tutti accedano allo stesso computer. Quest'ultimo caso non è l'ideale, perché tutte le istanze del codice nel repository risiederebbero sullo stesso computer, facendo diventare molto più probabile una perdita catastrofica dei dati.
+Quello più semplice è il _protocollo locale_, in cui il repository remoto è in un'altra directory sul disco. Questo è spesso utilizzato se ciascuno nel tuo team ha un accesso ad un file system condiviso come NFS, o nel caso meno probabile tutti accedano allo stesso computer. Quest'ultimo caso non è l'ideale, perché tutte le istanze del codice nel repository risiederebbero sullo stesso computer, facendo diventare molto più probabile una perdita catastrofica dei dati.
-Se disponi di un filesystem montato in comune, allora si può clonare, fare un push e un pull da un repository locale basato su file. Per clonare un repository come questo o per aggiungerne uno da remoto per un progetto esistente, utilizza il percorso al repository come URL. Ad esempio, per clonare un repository locale, è possibile eseguire qualcosa di simile a questo:
+Se disponi di un filesystem montato in comune, allora si può clonare, inviare e trarre da un repository locale basato su file. Per clonare un repository come questo o per aggiungerne uno da remoto per un progetto esistente, utilizza il percorso al repository come URL. Ad esempio, per clonare un repository locale, è possibile eseguire qualcosa di simile a questo:
$ git clone /opt/git/project.git
@@ -26,13 +26,13 @@ O questo:
$ git clone file:///opt/git/project.git
-Git funziona in modo leggermente diverso se si specifica esplicitamente `file://` all'inizio dell'URL. Se si specifica il percorso, Git tenta di utilizzare gli hardlink o copia direttamente i file necessari. Se specifichi `file://`, Git abilita i processi che normalmente si usano per trasferire i dati su una rete che sono generalmente un metodo molto meno efficace per il trasferimento dei dati. La ragione principale per specificare il prefisso `file://` è quella in cui si desidera una copia pulita del repository senza riferimenti od oggetti estranei — in genere dopo l'importazione da un altro sistema di controllo di versione o qualcosa di simile (vedi il Capitolo 9 relativo ai task per la manutenzione). Qui useremo il percorso normale, perché così facendo è quasi sempre più veloce.
+Git funziona in modo leggermente diverso se si specifica esplicitamente `file://` all'inizio dell'URL. Se si specifica il percorso, Git tenta di utilizzare gli hardlink o copia direttamente i file necessari. Se specifichi `file://`, Git abilita i processi che normalmente si usano per trasferire i dati su una rete che sono generalmente un metodo molto meno efficace per il trasferimento dei dati. La ragione principale per specificare il prefisso `file://` è quella in cui si desidera una copia pulita del repository senza riferimenti od oggetti estranei — in genere dopo l'importazione da un altro sistema di controllo di versione o qualcosa di simile (vedi il Capitolo 9 relativo ai compiti per la manutenzione). Qui useremo il percorso normale, perché così facendo è quasi sempre più veloce.
Per aggiungere un repository locale a un progetto Git esistente, puoi eseguire qualcosa di simile a questo:
$ git remote add local_proj /opt/git/project.git
-Quindi, puoi fare eseguire i push e i pull da remoto come se si stesse lavorando su una rete.
+Quindi, puoi fare inviare e trarre da quel remoto come se si stesse lavorando su una rete.
#### I Pro ####
@@ -44,11 +44,11 @@ Questa è anche una interessante possibilità per recuperare rapidamente il lavo
Il contro di questo metodo è che l'accesso condiviso è generalmente più difficile da impostare e da raggiungere da più postazioni rispetto ad un normale accesso di rete. Se vuoi fare un push dal computer quando sei a casa, devi montare il disco remoto, e può essere difficile e lento rispetto ad un accesso di rete.
-E' anche importante ricordare che questa non è necessariamente l'opzione più veloce, se utilizzi un mount condiviso di qualche tipo. Un repository locale è veloce solo se si dispone di un accesso veloce ai dati. Un repository su NFS è spesso più lento di un repository via SSH sullo stesso server, permettendo a Git di andare con dischi locali su ogni sistema.
+É anche importante ricordare che questa non è necessariamente l'opzione più veloce, se utilizzi un mount condiviso di qualche tipo. Un repository locale è veloce solo se si dispone di un accesso veloce ai dati. Un repository su NFS è spesso più lento di un repository via SSH sullo stesso server, permettendo a Git di andare con dischi locali su ogni sistema.
-### Il protocollo SSH ###
+### Il Protocollo SSH ###
-Probabilmente il protocollo più utilizzato per Git è SSH. Questo perché un accesso via SSH ad un server è già impostato in molti posti — e se non c'è, è facile crearlo. SSH inoltre è l'unico protocollo di rete in cui puoi facilmente leggere e scrivere. Gli altri due protocolli (HTTP e Git) sono generalmente solo di lettura, quindi se li hai a disposizione per la massa, hai comunque bisogno di SSH per i tuoi comandi di scrittura. SSH è inoltre un protocollo di rete con autenticazione; e dato che è dappertutto, è generalmente facile da configurare e usare.
+Probabilmente il protocollo più utilizzato per Git è SSH. Questo perché un accesso via SSH ad un server è già impostato in molti posti — e se non c'è, è facile crearlo. SSH inoltre è l'unico protocollo di rete in cui puoi facilmente leggere e scrivere. Gli altri due protocolli (HTTP e Git) sono generalmente solo di lettura, quindi se li hai a disposizione per la massa generica, hai comunque bisogno di SSH per i tuoi comandi di scrittura. SSH è inoltre un protocollo di rete con autenticazione; e dato che è dappertutto, è generalmente facile da configurare e usare.
Per clonare un repository Git via SSH, puoi specificare un URL ssh:// come questo:
@@ -62,28 +62,28 @@ Puoi anche non specificare l'utente, e Git utilizzerà l'utente con il quale sei
#### I Pro ####
-I pro nell'usare SSH sono tanti. Primo, se vuoi avere un'autenticazione con l'accesso in scrittura al tuo repository su una rete devi usarlo. Secondo, SSH è relativamente semplice da impostare — il demone SSH è ovunque, molti amministratori di rete hanno esperienza con lui e molte distribuzioni di OS sono impostate con lui o hanno dei strumenti per amministrarlo. Poi, l'accesso via SSH è sicuro — tutti i dati trasferiti sono criptati ed autenticati. Infine, come i protocolli Git e Local, SSH è efficiente, rende i dati il più compressi possibili prima di trasferirli.
+I pro nell'usare SSH sono tanti. Primo, se vuoi avere un'autenticazione con l'accesso in scrittura al tuo repository su una rete devi usarlo. Secondo, SSH è relativamente semplice da impostare — il demone SSH è ovunque, molti amministratori di rete hanno esperienza con lui e molte distribuzioni di OS sono impostate con lui o hanno dei strumenti per amministrarlo. Poi, l'accesso via SSH è sicuro — tutti i dati trasferiti sono criptati ed autenticati. Infine, come i protocolli Git e Local, SSH è efficiente, rende i dati il più compressi possibile prima di trasferirli.
-#### I contro ####
+#### I Contro ####
-L'aspetto negativo di SSH è che non puoi dare accesso anonimo al tuo repository tramite lui. Le persone devono avere un accesso alla macchina tramite SSH, anche per la sola lettura, ciò rende SSH poco appetibile per i progetti open source. Se lo stai usando solo con la rete della tua azienda, SSH può essere l'unico protocollo con cui avrai a che fare. Se vuoi fornire un accesso anonimo di sola lettura al tuo progetto, devi impostare un SSH per i tuoi push ma qualcos'altro per per permettere ad altri di fare il pull.
+L'aspetto negativo di SSH è che non puoi dare accesso anonimo al tuo repository tramite lui. Le persone devono avere un accesso alla macchina tramite SSH, anche per la sola lettura, ciò rende SSH poco appetibile per i progetti open source. Se lo stai usando solo con la rete della tua azienda, SSH può essere l'unico protocollo con cui avrai a che fare. Se vuoi fornire un accesso anonimo di sola lettura al tuo progetto, devi impostare un SSH per i tuoi invii ma qualcos'altro per per permettere ad altri di trarre i dati.
-### Il protocollo Git ###
+### Il Protocollo Git ###
-Poi c'è il protocollo Git. Questo è un demone speciale che è incluso nel pacchetto Git; è in ascolto su una porta dedicata (9418) e fornisce un servizio simile al protocollo SSH, ma assolutamente senza autenticazione. Per permettere ad un repository di essere servito tramite il protocollo Git, devi creare un file `git-export-daemon-ok` — il demone non serve il repository senza l'inserimento di questo file — altrimenti non ci sarebbe sicurezza. O il repository Git è disponibile per chiunque voglia copiarlo o altrimenti niente. Questo significa che generalmente non si fa il push tramite questo protocollo. Puoi abilitare l'accesso al push; ma data la mancanza di autenticazione, se abiliti l'accesso di scrittura, chiunque trovi su internet l'URL al progetto può fare il push. E' sufficiente dire che questo è raro.
+Poi c'è il protocollo Git. Questo è un demone speciale che è incluso nel pacchetto Git; è in ascolto su una porta dedicata (9418) e fornisce un servizio simile al protocollo SSH, ma assolutamente senza autenticazione. Per permettere ad un repository di essere servito tramite il protocollo Git, devi creare un file `git-export-daemon-ok` — il demone non serve il repository senza l'inserimento di questo file — altrimenti non ci sarebbe sicurezza. O il repository Git è disponibile per chiunque voglia copiarlo o altrimenti niente. Questo significa che generalmente non si invia tramite questo protocollo. Puoi abilitare l'accesso all'invio; ma data la mancanza di autenticazione, se abiliti l'accesso di scrittura, chiunque trovi su internet l'URL al progetto può inviare dati. Basti dire che questo è raro.
-#### I pro ####
+#### I Pro ####
-Il protocollo Git è il protocollo disponibile più veloce. Se hai un grande traffico per un tuo progetto pubblico o hai un progetto molto grande che non richiede un'autenticazione per l'accesso in lettura, è esattamente quello che ciò che vorrai impostare per un demone Git per fornire il progetto. Usa lo stesso meccanismo di trasferimento dei dati del protocollo SSH ma senza criptazione e autenticazione.
+Il protocollo Git è il protocollo disponibile più veloce. Se hai un grande traffico per un tuo progetto pubblico o hai un progetto molto grande che non richiede un'autenticazione per l'accesso in lettura, è probabile che vorrai impostare per un demone Git per servire il progetto. Usa lo stesso meccanismo di trasferimento dei dati del protocollo SSH ma senza criptazione e autenticazione.
-#### I contro ####
+#### I Contro ####
-Il rovescio della medaglia è che al protocollo Git manca l'autenticazione. E' generalmente non desiderabile avere l'accesso al progetto solo tramite il protocollo Git. Generalmente, si utilizzano insieme un accesso SSH per gli sviluppatori che hanno permessi di scrittura e per tutti gli altri si usa l'accesso in sola lettura `git://`.
-Inoltre è probabilmente il protocollo più difficile da configurare. Deve avviare un proprio demone, che è personale — vedremo le impostazioni nella sezione “Gitosis” di questo capitolo — richiede la configurazione di `xinetd` o simili, che non è una passeggiata. Inoltre richiede un accesso tramite il firewall alla porta 9418, che non è una porta standard che i firewall delle aziende permettono di usare. Un firewall di una grande azienda spesso blocca questa porta.
+Il rovescio della medaglia è che al protocollo Git manca l'autenticazione. É generalmente non desiderabile avere l'accesso al progetto solo tramite il protocollo Git. Generalmente, si utilizzano insieme un accesso SSH per gli sviluppatori che hanno permessi di scrittura e per tutti gli altri si usa l'accesso in sola lettura `git://`.
+Inoltre è probabilmente il protocollo più difficile da configurare. Deve avviare un proprio demone, che è particolare — vedremo le impostazioni nella sezione “Gitosis” di questo capitolo — richiede la configurazione di `xinetd` o simili, il che non è una passeggiata. Inoltre richiede un accesso tramite il firewall alla porta 9418, che non è una porta standard che i firewall delle aziende permettono di usare sempre. Un firewall di una grande azienda spesso blocca questa sconosciuta porta.
-### Il protocollo HTTP/S ###
+### Il Protocollo HTTP/S ###
-Infine abbiamo il protocollo HTTP. Il bello del protocollo HTTP o HTTPS è la semplicità nel configurarlo. Fondamentalmente, tutto quello che devi fare è mettere solo il repository Git sulla document root HTTP ed impostare uno specifico gancio `post-update` ed il gioco è fatto (vedi il Capitolo 7 per i dettagli sugli agganci Git). A questo punto, chiunque in grado di accedere al server web sotto cui hai messo il repository può clonare il repository. Per permettere l'accesso in lettura al repository via HTTP, fai una cosa simile:
+Infine abbiamo il protocollo HTTP. Il bello del protocollo HTTP o HTTPS è la semplicità nel configurarlo. Fondamentalmente, tutto quello che devi fare è mettere solo il repository Git sulla document root HTTP ed impostare uno specifico gancio `post-update` ed il gioco è fatto (vedi il Capitolo 7 per i dettagli sui ganci Git). A questo punto, chiunque in grado di accedere al server web sotto cui hai messo il repository può clonare il repository. Per permettere l'accesso in lettura al repository via HTTP, fai una cosa simile:
$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
@@ -91,15 +91,15 @@ Infine abbiamo il protocollo HTTP. Il bello del protocollo HTTP o HTTPS è la se
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
-Questo è quanto. L'aggancio `post-update` che è messo assieme a Git di default avvia il comando appropriato (`git update-server-info`) per far lavorare correttamente il prelievo e la clonazione HTTP. Questo comando è avviato quando lanci un push al tuo repository via SSH; poi, possono clonarlo con una cosa simile:
+Questo è quanto. L'aggancio `post-update` che è messo assieme a Git di default avvia il comando appropriato (`git update-server-info`) per far lavorare correttamente il prelievo e la clonazione HTTP. Questo comando è avviato quando lanci un invio al tuo repository via SSH; poi, altre persone possono clonarlo con una cosa simile:
$ git clone http://example.com/gitproject.git
-In questo caso particolare, stiamo usando il path `/var/www/htdocs` che è comunemente presente nelle installazioni di Apache, ma puoi usare un qualsiasi altro server web — basta mettere la base del repository nella path. I dati di Git sono forniti come file statici (vedi Capitolo 9 per dettagli su come sono esattamente forniti).
+In questo caso particolare, stiamo usando il percorso `/var/www/htdocs` che è comunemente presente nelle installazioni di Apache, ma puoi usare un qualsiasi altro server web — basta mettere la base del repository nel percorso. I dati di Git sono forniti come file statici (vedi Capitolo 9 per dettagli su come sono esattamente forniti).
-E' anche possibile fare il push con Git via HTTP, la tecnica non è molto utilizzata e richiede di impostare un complesso WebDAV. Dato che è raramente utilizzato, non lo vedremo in questo libro. Se sei interessato nel fare il push tramite protocollo HTTP, puoi leggere qualcosa su come preparare un repository qui `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt`. Una cosa carina per fare il push con Git via HTTP è utilizzare un server WebDAV, senza alcune specifiche funzionalità di Git; così, puoi usare questa funzionalità se il tuo hosting web fornisce un supporto WebDAV per scrivere aggiornamenti al tuo sito web.
+É anche possibile fare l'invio con Git via HTTP, la tecnica non è molto utilizzata e richiede di impostare un complesso WebDAV. Dato che è raramente utilizzato, non lo vedremo in questo libro. Se sei interessato ad usare i protocolli HTTP-push, puoi leggere su come preparare un repository a questo scopo a `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt`. Una cosa carina dell'invio con Git via HTTP è utilizzare un qualsiasi server WebDAV, senza alcune specifiche funzionalità di Git; così, puoi usare questa funzionalità se il tuo hosting web fornisce un supporto WebDAV per scrivere aggiornamenti al tuo sito web.
-#### I pro ####
+#### I Pro ####
Il bello di usare il protocollo HTTP è che è facile da configurare. Con pochi comandi si può dare facilmente al mondo un accesso in lettura al tuo repository Git. Porta via solo pochi minuti. Inoltre il protocollo HTTP non richiede tante risorse al tuo server. Perché in genere è utilizzato un server statico HTTP per fornire i dati, un server Apache in media può servire migliaia di file al secondo — è difficile sovraccaricare anche un piccolo server.
@@ -107,11 +107,11 @@ Puoi anche fornire un accesso in sola lettura via HTTPS, il che significa che pu
Un'altra cosa carina è che l'HTTP è un protocollo comunissimo che i firewall delle aziende in genere configurano per permettere il traffico tramite la sua porta.
-#### I contro ####
+#### I Contro ####
-L'altra faccia della medaglia nel fornire il tuo repository via HTTP è che è relativamente inefficiente per il client. In genere porta via molto tempo per clonare o scaricare dal repository, e si ha spesso un sovraccarico della rete tramite il trasferimento di volumi via HTTP rispetto ad altri protocolli di rete. Non essendo abbastanza intelligente da trasferire solo i dati di cui hai bisogno — non c'è un lavoro dinamico dalla parte del server in questa transazione — il protocollo HTTP viene a volte chiamato protocollo _dumb_. Per maggiori informazioni sulle differenze nell'efficienza tra il protocollo HTTP e gli altri, vedi il Capitolo 9.
+L'altra faccia della medaglia nel fornire il tuo repository via HTTP è che è relativamente inefficiente per il client. In genere porta via molto tempo per clonare o scaricare dal repository, e si ha spesso un sovraccarico della rete tramite il trasferimento di volumi via HTTP rispetto ad altri protocolli di rete. Non essendo abbastanza intelligente da trasferire solo i dati di cui hai bisogno — non c'è un lavoro dinamico dalla parte del server in questa transazione — il protocollo HTTP viene spesso definito un protocollo _stupido_. Per maggiori informazioni sulle differenze nell'efficienza tra il protocollo HTTP e gli altri, vedi il Capitolo 9.
-## Avere Git su un Server ##
+## Ottenere Git su di un Server ##
Per inizializzare un qualsiasi server Git, devi esportare un repository esistente in un nuovo repository di soli dati — cioè un repository che non contiene la directory di lavoro. Questo è generalmente molto semplice da fare.
Per clonare il tuo repository per creare un nuovo repository di soli dati, devi avviare il comando clone con l'opzione `--bare`. Convenzionalmente, un repository di soli dati in finisce in `.git`, ad esempio:
@@ -119,17 +119,17 @@ Per clonare il tuo repository per creare un nuovo repository di soli dati, devi
$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/
-L'output di questo comando confonde un pochino. Fondamentalmente `clone` è un `git init` e non un `git fetch`, abbiamo visto alcuni output nella parte su `git init` nel creare una directory vuota. L'oggetto attuale di trasferimento non da output, ma funziona. Ora dovresti avere una copia della directory dei dati di Git nella directory `my_project.git`.
+L'output di questo comando confonde un pochino. Dato che `clone` è un `git init` quindi un `git fetch`, vediamo parte dell'output dalla parte `git init`, il quale crea una directory vuota. L'effecttivo trasferimento dell'oggetto non fornisce output, ma avviene. Ora dovresti avere una copia della directory dei dati di Git nella directory `my_project.git`.
La stessa cosa la si può ottenere con
$ cp -Rf my_project/.git my_project.git
-Ci sono solo poche differenze nel file di configurazione; ma per tua conoscenza, questo copia le stesse cose. Lui prende il repository Git da solo, senza la directory di lavoro e crea una directory specifica per i soli dati.
+Ci sono solo un paio di differenze minori nel file di configurazione; ma per il tuo scopo, è quasi la stessa cosa. Lui prende il repository Git da solo, senza la directory di lavoro e crea una directory specifica per i soli dati.
-### Mettere il repository di soli dati su un server ###
+### Mettere il Repository Soli Dati su un Server ###
-Ora che hai la copia dei soli dati del tuo repository, tutto quello che devi fare è mettere su un server e configurare il protocollo. Diciamo che hai impostato un server chiamato `git.example.com` su cui hai anche un accesso SSH e vuoi salvare tutti i tuoi repository Git nella directory `/opt/git`. Puoi impostare il tuo nuovo repository copiandoci sopra i dati del repository:
+Ora che hai la copia dei soli dati del tuo repository, tutto quello che devi fare è metterli su un server e configurare il protocollo. Diciamo che hai impostato un server chiamato `git.example.com` su cui hai anche un accesso SSH e vuoi salvare tutti i tuoi repository Git nella directory `/opt/git`. Puoi impostare il tuo nuovo repository copiandoci sopra i dati del repository:
$ scp -r my_project.git user@git.example.com:/opt/git
@@ -137,7 +137,7 @@ A questo punto, gli altri utenti che hanno un accesso SSH allo stesso server con
$ git clone user@git.example.com:/opt/git/my_project.git
-Se gli utenti che entrano in SSH su un server e hanno l'accesso in scrittura alla directory `/opt/git/my_project.git`, avranno automaticamente la possibilità di inviare push. Git automaticamente aggiunge al repository i permessi di scrittura al gruppo se darai il comando `git init` con l'opzione `--shared`.
+Se gli utenti entrano in SSH su di un server ed hanno l'accesso in scrittura alla directory `/opt/git/my_project.git`, avranno automaticamente la possibilità di inviare dati. Git automaticamente aggiunge al repository i permessi di scrittura al gruppo se darai il comando `git init` con l'opzione `--shared`.
$ ssh user@git.example.com
$ cd /opt/git/my_project.git
@@ -145,19 +145,19 @@ Se gli utenti che entrano in SSH su un server e hanno l'accesso in scrittura all
Hai visto quanto è semplice creare un repository Git, creare una versione di soli dati e posizionarlo su un server dove tu e i tuoi collaboratori avete un accesso SSH. Ora siete pronti per collaborare sullo stesso progetto.
-E' importante notare che questo è letteralmente tutto ciò di cui hai bisogno per avviare un server Git dove vari utenti hanno accesso — semplicemente aggiungi un account SSH sul server e metti un repository di dati da qualche parte dove i tuoi utenti hanno un accesso in lettura e anche in scrittura. Sei pronto per procedere — non hai bisogno di niente altro.
+É importante notare che questo è letteralmente tutto ciò di cui hai bisogno per avviare un server Git dove vari utenti hanno accesso — semplicemente aggiungi un account SSH sul server e metti un repository di dati da qualche parte dove i tuoi utenti hanno un accesso in lettura e anche in scrittura. Sei pronto per procedere — non hai bisogno di niente altro.
-Nelle prossime sezioni, vedrai come un'installazione più sofisticata. Questa discussione includerà non solo la creazione di account utenti per ogni utente, l'aggiunta di un accesso in lettura pubblico ai repository, configurare delle interfaccie web, usare Gitosis ma molto altro. Comunque, tieni in mente che per collaborare con altre persone su un progetto privato, tutto quello di cui hai bisogno è un server SSH e i dati del repository.
+Nelle prossime sezioni, vedrai come adattarsi ad un'installazione più sofisticata. Questa discussione includerà non dover creare account utente per ogni utente, l'aggiunta di un accesso in lettura pubblico ai repository, configurare delle interfaccie web, usare Gitosis e molto altro. Comunque, tieni in mente che per collaborare con altre persone su un progetto privato, tutto quello di cui hai bisogno è un server SSH e i dati del repository.
-### Configurazione base ###
+### Piccole Configurazioni ###
-Se hai poche risorse stai provando Git nella tua organizzazione e hai pochi utenti, le cose sono semplici. Una delle cose più complicate di configurazione di un server Git è l'amministrazione degli utenti. Se vuoi alcuni repositori in sola lettura per alcuni utenti e l'accesso in lettura e scrittura per altri, accessi e permessi possono essere un po' complicati da configurare.
+Se hai poche risorse o stai provando Git nella tua organizzazione e hai pochi sviluppatori, le cose possono essere semplici per te. Una delle cose più complicate del configurare un server Git è l'amministrazione degli utenti. Se vuoi alcuni repository in sola lettura per alcuni utenti e l'accesso in lettura e scrittura per altri, accessi e permessi possono essere un po' complicati da configurare.
#### Accesso SSH ####
Se hai già un server dove tutti i tuoi sviluppatori hanno un accesso SSH, è generalmente facile impostare qui il tuo primo repository, perché la gran parte del lavoro è già stato fatto (come abbiamo visto nell'ultima sezione). Se vuoi un controllo più articolato sugli accessi e suoi permessi sul tuo repository, puoi ottenerli con i normali permessi del filesystem del sistema operativo del server che stai utilizzando.
-Se vuoi mettere il tuo repository su un server che non ha account per ciascun utente del tuo team e vuoi l'accesso in scrittura per alcuni, allora devi impostare un accesso SSH. Se assumiamo che già hai un server che fa questo, hai già un server SSH installato, questo diventerà il sistema di accesso.
+Se vuoi mettere i tuoi repository su un server che non ha account per ogni persona del tuo team che tu vuoi abbia l'accesso in scrittura, allora devi impostare un accesso SSH per loro. Noiu supponiamo che se tu hai un server con cui fare questo, tu abbia già un server SSH installato, ed è con esso che stati accedendo al server.
Ci sono vari modi con cui puoi dare accesso a tutto il tuo team. Il primo è impostare degli account per ognuno, è semplice ma porta via molto tempo. Probabilmente non hai voglia di lanciare `adduser` ed impostare una password temporanea per ciascun utente.
@@ -165,7 +165,7 @@ Un secondo metodo è creare un singolo utente 'git' sulla macchina, chiedendo a
Un altro modo è avere un'autenticazione al tuo server SSH via server LDAP o un altro sistema centralizzato di autenticazione che hai già configurato. Così ogni utente può avere un accesso shell sulla macchina, qualsiasi meccanismo di autenticazione SSH a cui puoi pensare dovrebbe funzionare.
-## Generare la propria chiave pubblica SSH ##
+## Generare la Propria Chiave Pubblica SSH ##
Come detto precedentemente, molti server Git usano l'autenticazione con la chiave pubblica SSH. Per poter avere una chiave pubblica, ogni utente del tuo sistema deve generarne una se già non la possiede. Questo processo è simile per tutti i sistemi operativi.
Primo, devi controllare di non avere già una chiave. Di base, le chiavi SSH degli utenti sono salvate nella directory `~/.ssh`. Puoi facilmente controllare spostandoti nella directory e controllandone il contenuto:
@@ -189,7 +189,7 @@ Devi cercare una coppia di chiavi dal nome simile a qualcosa e qualcosa.pub, dov
Prima chiede la conferma dove vuoi salvare la chiave (`.ssh/id_rsa`) e poi chiede due volte la passphrase, che puoi lasciare vuota se non vuoi inserire una password quando usi la chiave.
-Ora, ogni utente che ha fatto questo deve inviare la propria chiave pubblica a te o a chi amministra il server Git (assumiamo che tu stai usando un server SSH impostato in modo da richiedere le chiavi pubbliche). Tutto quello che devono fare è copiare il contenuto del file `.pub` ed inviarlo via e-mail. La chiave pubblica è qualcosa di simile a questo:
+Ora, ogni utente che ha fatto questo deve inviare la propria chiave pubblica a te o a chi amministra il server Git (supponiamo che tu stia usando un server SSH impostato in modo da richiedere le chiavi pubbliche). Tutto quello che devono fare è copiare il contenuto del file `.pub` ed inviarlo via e-mail. La chiave pubblica è qualcosa di simile a questo:
$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
@@ -201,9 +201,9 @@ Ora, ogni utente che ha fatto questo deve inviare la propria chiave pubblica a t
Per una guida più specifica sulla creazione di una chiave SSH su sistemi operativi multipli, vedi la guida GitHub sulle chiavi SSH `http://github.com/guides/providing-your-ssh-key`.
-## Configurare il server ##
+## Configurare il Server ##
-Ora vediamo come configurare un accesso SSH lato server. In questo esempio, utilizzeremo il metodo `authorized_keys` per autenticare gli utenti. Assumiamo anche che stai utilizzando una distribuzione standard di Linux come Ubuntu. Prima, crea un utente 'git' e una directory `.ssh` per questo utente.
+Ora vediamo come configurare un accesso SSH lato server. In questo esempio, utilizzeremo il metodo `authorized_keys` per autenticare gli utenti. Supponiamo anche che stia utilizzando una distribuzione standard di Linux come Ubuntu. Prima, crea un utente 'git' e una directory `.ssh` per questo utente.
$ sudo adduser git
$ su git
@@ -233,7 +233,7 @@ Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bar
$ cd project.git
$ git --bare init
-Poi, John, Josie o Jessica possono inviare la prima versione del loro progetto nel repository aggiungendolo come ramo remoto e di push. Nota che qualcuno deve accedere via shell alla macchina e creare un repository base ogni volta che si vuole aggiungere un progetto. Usiamo il nome `gitserver` per il server dove hai impostato il tuo utente 'git' ed il repository. Se lo stai usando nella rete interna e hai impostato un DNS con il punto `gitserver` per puntare a questo server, allora puoi usare il comando:
+Poi, John, Josie o Jessica possono inviare la prima versione del loro progetto nel repository aggiungendolo come ramo remoto ed inviandolo su di un ramo. Nota che qualcuno deve accedere via shell alla macchina e creare un repository base ogni volta che si vuole aggiungere un progetto. Usiamo il nome `gitserver` per il server dove hai impostato il tuo utente 'git' ed il repository. Se lo stai usando nella rete interna e hai impostato un DNS con il punto `gitserver` per puntare a questo server, allora puoi usare il comando:
# sul computer di Johns
$ cd myproject
@@ -243,9 +243,10 @@ Poi, John, Josie o Jessica possono inviare la prima versione del loro progetto n
$ git remote add origin git@gitserver:/opt/git/project.git
$ git push origin master
-A questo punto, gli altri possono clonare e fare i push dei cambiamenti molto facilmente:
+A questo punto, gli altri possono clonare ed inviare dei cambiamenti molto facilmente:
$ git clone git@gitserver:/opt/git/project.git
+ $ cd project
$ vim README
$ git commit -am 'fix for the README file'
$ git push origin master
@@ -264,35 +265,33 @@ Modifica `/bin/sh` in `/usr/bin/git-shell` (o lancia `which git-shell` per veder
git:x:1000:1000::/home/git:/usr/bin/git-shell
-Ora, l'utente 'git' può solamente usare la connessione SSH per inviare e scaricare i repository Git e non può accedere all shell della macchina. Se provi vedrai il rigetto dell'autenticazione:
+Ora, l'utente 'git' può solamente usare la connessione SSH per inviare e scaricare i repository Git e non può accedere alla shell della macchina. Se provi vedrai il rifiuto dell'autenticazione:
$ ssh git@gitserver
fatal: What do you think I am? A shell?
Connection to gitserver closed.
-## Accesso pubblico ##
+## Accesso Pubblico ##
E se vuoi un accesso in lettura anonimo al tuo progetto? Probabilmente invece di ospitare un progetto privato interno, vuoi ospitare un progetto open source. O magari hai un gruppo di server automatizzati o server in continua integrazione che cambiano, e non vuoi generare chiavi SSH tutte le volte — vuoi solamente dare un semplice accesso anonimo in lettura.
-Probabilmente il modo più semplice per una piccola installazione è avviare un server web statico con il suo document root dove si trovano i repository Git, e poi abilitare l'hook `post-update` che abbiamo visto nella prima sezione di questo capitolo. Partiamo dall'esempio precedente. Diciamo che hai i tuoi repository nella directory `/opt/git`, ed un server Apache sulla macchina. Ancora, puoi usare un qualsiasi server web per questo; ma come esempio, vediamo alcune configurazioni basi di Apache che ti dovrebbero dare una idea di cosa hai bisogno.
+Probabilmente il modo più semplice per una piccola installazione è avviare un server web statico con il suo document root dove si trovano i repository Git, e poi abilitare l'aggancio `post-update` che abbiamo visto nella prima sezione di questo capitolo. Partiamo dall'esempio precedente. Diciamo che hai i tuoi repository nella directory `/opt/git`, ed un server Apache sulla macchina. Ancora, puoi usare un qualsiasi server web per questo; ma come esempio, vediamo alcune configurazioni basi di Apache che ti dovrebbero dare una idea di cosa hai bisogno.
-Prima devi abilitare l'hook:
+Prima devi abilitare l'aggancio:
$ cd project.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
-Se stai usando una versione di Git precedente alla 1.6, il comando `mv` non è necessario — Git ha iniziato a nominare gli esempi di ancore solo recentemente con l'estensione .sample.
-
-Cosa fa quest'ancora (hook) `post-update`? Fondamentalmente una cosa del genere:
+Cosa fa questo aggancio `post-update`? Fondamentalmente una cosa del genere:
$ cat .git/hooks/post-update
#!/bin/sh
exec git-update-server-info
-Questo significa che quando fai un push al server via SSH, Git automaticamente avvia questo comando per aggiornare i file necessari per essere scaricati via HTTP.
+Questo significa che quando invii dati al server via SSH, Git automaticamente avvia questo comando per aggiornare i file necessari per il prelievo via HTTP.
-Poi, hai bisogno di aggiungere una voce VirtualHost alla configurazione del tuo Apache con la document root che è la directory dei tuoi progetti Git. Qui, assumiamo che hai un DNS asteriscato impostato per inviare `*.gitserver` ad ogni box che stai usando:
+Poi, hai bisogno di aggiungere una voce VirtualHost alla configurazione del tuo Apache con la document root che è la directory dei tuoi progetti Git. Qui, supponiamo che abbia un wildcard DNS impostato per inviare `*.gitserver` ad ogni box che stai usando:
<VirtualHost *:80>
ServerName git.gitserver
@@ -303,7 +302,7 @@ Poi, hai bisogno di aggiungere una voce VirtualHost alla configurazione del tuo
</Directory>
</VirtualHost>
-Devi inoltre impostare il gruppo utente Unix alle directory `/opt/git` in `www-data` così il tuo server web può avere un accesso di lettura ai repository, perché l'istanza Apache lancia lo script CGI (di default) quando è eseguito come questo utente:
+Devi inoltre impostare il gruppo utente Unix della directory `/opt/git` in `www-data` così il tuo server web può avere un accesso di lettura ai repository, perché l'istanza Apache lancia lo script CGI (di default) quando è eseguito come questo utente:
$ chgrp -R www-data /opt/git
@@ -326,7 +325,7 @@ Se vuoi verificare come GitWeb presenta il tuo progetto, Git è dotato di un com
[2009-02-21 10:02:21] INFO WEBrick 1.3.1
[2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
-Questo avvia un server HTTPD sulla porta 1234 e automaticamente avvia un browser web che apre questa pagina. E' davvero molto semplice. Quando hai fatto e vuoi chiudere il server, puoi usare lo stesso comando con l'opzione `--stop`:
+Questo avvia un server HTTPD sulla porta 1234 e automaticamente avvia un browser web che apre questa pagina. É davvero molto semplice. Quando hai fatto e vuoi chiudere il server, puoi usare lo stesso comando con l'opzione `--stop`:
$ git instaweb --httpd=webrick --stop
@@ -353,7 +352,7 @@ Nota che devi dire al comando dove trovare i tuoi repository Git con la variabil
</Directory>
</VirtualHost>
-Ancora, GitWeb può essere utilizzato con qualsiasi server web che supporta CGI; se preferisci usare qualcos'altro, non dovresti avere difficoltà nella configurazione. A questo punto, dovresti essere ingrado di vedere in `http://gitserver/` i tui repository online, e puoi usare `http://git.gitserver/` per clonare e controllare i tuoi repository via HTTP.
+Ancora, GitWeb può essere utilizzato con qualsiasi server web che supporta CGI; se preferisci usare qualcos'altro, non dovresti avere difficoltà nella configurazione. A questo punto, dovresti essere ingrado di vedere in `http://gitserver/` i tuoi repository online, e puoi usare `http://git.gitserver/` per clonare e controllare i tuoi repository via HTTP.
## Gitosis ##
@@ -361,9 +360,9 @@ Mantenere tutte le chiavi pubbliche degli utenti nel file `authorized_keys` funz
A questo punto, potresti voler passare ad un software maggiormente utilizzato chiamato Gitosis. Gitosis è fondamentalmente una serie di script che aiutano ad amministrare il file `authorized_keys` esattamente come implementare un sistema di controllo degli accessi. La parte davvero interessante è che l'UI di questo strumento per aggiungere utenti e determinare gli accessi non è un'interfaccia web ma uno speciale repository Git. Puoi impostare le informazioni in questo progetto; e quando le re-invii, Gitosis riconfigura il server basandosi su di esse, è fantastico.
-Installare Gitosis non è un'operazione proprio semplice, ma non è così tanto difficile. E' facilissimo usarlo su un server Linux — questo esempio usa un server Ubuntu 8.10.
+Installare Gitosis non è un'operazione proprio semplice, ma non è così tanto difficile. É facilissimo usarlo su un server Linux — questo esempio usa un server Ubuntu 8.10.
-Gitosis richiede alcuni strumenti Python, così prima devi installare i pacchetti di setup Python, che Ubuntu fornisce tramite python-setuptools:
+Gitosis richiede alcuni strumenti Python, così prima devi installare il pacchetto di Python setuptools, che Ubuntu fornisce tramite python-setuptools:
$ apt-get install python-setuptools
@@ -381,7 +380,7 @@ Gitosis amministrerà le chiavi per te, così dovrai rimuovere il file corrente,
$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
-Poi devi reimpostare la shell del tuo utente 'git', se l'hai cambiato con il comandi `git-shell`. Le persone non sono ora in grado di fare il login, ma Gitosis controllerà questa cosa per te. Così, modifica questa linea nel tuo file `/etc/passwd`
+Poi devi reimpostare la shell del tuo utente 'git', se lo hai cambiato con il comandi `git-shell`. Le persone non sono ora in grado di fare il login, ma Gitosis controllerà questa cosa per te. Così, modifica questa linea nel tuo file `/etc/passwd`
git:x:1000:1000::/home/git:/usr/bin/git-shell
@@ -399,7 +398,7 @@ Questo permetterà all'utente con questa chiave di modificare il repository Git
$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
-Sei pronto per partire. Se hai configurato correttamente, puoi provare ad entrare via SSH nel tuo server come utente che ha aggiunto la chiave pubblica iniziale in Gitosis. Dovresti vedere qualcosa di simile a:
+Sei pronto per partire. Se sei configurato correttamente, puoi provare ad entrare via SSH nel tuo server come utente che ha aggiunto la chiave pubblica iniziale in Gitosis. Dovresti vedere qualcosa di simile a:
$ ssh git@gitserver
PTY allocation request failed on channel 0
@@ -451,7 +450,7 @@ Ogni volta che fai una modifica al progetto `gitosis-admin`, devi fare un commit
To git@gitserver:/opt/git/gitosis-admin.git
fb27aec..8962da8 master -> master
-Puoi ora fare il tuo push al nuovo progetto `iphone_project` aggiungendo il tuo server come sorgente remota alla tua versione locale del progetto. Non hai bisogno di creare manualmente un repository base per nuovi progetti sul server — Gitosis li crea automaticamente quando vede il loro primo push:
+Puoi ora fare il tuo push al nuovo progetto `iphone_project` aggiungendo il tuo server come sorgente remota alla tua versione locale del progetto. Non hai bisogno di creare manualmente un repository base per nuovi progetti sul server — Gitosis li crea automaticamente quando vede il loro primo invio:
$ git remote add origin git@gitserver:iphone_project.git
$ git push origin master
@@ -462,9 +461,9 @@ Puoi ora fare il tuo push al nuovo progetto `iphone_project` aggiungendo il tuo
To git@gitserver:iphone_project.git
* [new branch] master -> master
-Nota che non devi specificare la path (infatti, se lo si fa non funziona), basta solamente la colonna e poi il nome del progetto — Gitosis farà il resto.
+Nota che non devi specificare il percorso (infatti, se lo si fa non funziona), basta solamente la colonna e poi il nome del progetto — Gitosis farà il resto.
-Se vuoi lavorare sul progetto con i tuoi amici, devi ri-aggiungere le chiavi pubbliche. Ma invece di aggiungerle manualmente nel file `~/.ssh/authorized_keys` sul server, le devi aggiungere, un file per volta, nella directory `keydir`. Come nomini queste chiavi determinerà come fai riferimento agli utenti nel file `gitosis.conf`. Ri-aggiungiamo le chiavi pubbliche per John, Josie e Jessica:
+Se vuoi lavorare sul progetto con i tuoi amici, devi riaggiungere le chiavi pubbliche. Ma invece di aggiungerle manualmente nel file `~/.ssh/authorized_keys` sul server, le devi aggiungere, un file per volta, nella directory `keydir`. Come nomini queste chiavi determinerà come fai riferimento agli utenti nel file `gitosis.conf`. Riaggiungiamo le chiavi pubbliche per John, Josie e Jessica:
$ cp /tmp/id_rsa.john.pub keydir/john.pub
$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
@@ -476,7 +475,7 @@ Ora puoi aggiungerli al tuo team 'mobile' così avranno accesso in lettura e scr
writable = iphone_project
members = scott john josie jessica
-Dopo che hai fatto il commit ed il push delle modifiche, tutti e quattro gli utenti saranno in grado di leggere e scrivere nel progetto.
+Dopo che hai fatto il commit ed l'invio delle modifiche, tutti e quattro gli utenti saranno in grado di leggere e scrivere nel progetto.
Gitosis ha un semplice controllo dell'accesso. Se vuoi che John abbia solo un accesso in lettura al progetto, devi fare così:
@@ -501,99 +500,75 @@ Ora John può clonare il progetto ed ottenere gli aggiornamenti, ma Gitosis non
writable = another_iphone_project
members = @mobile_committers john
-Se hai un qualsiasi dubbio, può essere utile aggiungere `loglevel=DEBUG` nell sezione `[gitosis]`. Se hai perso l'accesso alla scrittura perché hai inviato una configurazione sbagliata, puoi risolvere la cosa manualmente sul server `/home/git/.gitosis.conf` — il file da dove Gitosis legge le informazioni. Un push al progetto prende il file `gitosis.conf` che hai appena inviato e lo posiziona li. Se modifichi questo file manualmente, rimarrà come lo hai lasciato fino al prossimo push andato a termine nel progetto `gitosis-admin`.
+Se hai un qualsiasi dubbio, può essere utile aggiungere `loglevel=DEBUG` nell sezione `[gitosis]`. Se hai perso l'accesso alla scrittura perché hai inviato una configurazione sbagliata, puoi risolvere la cosa manualmente sul server `/home/git/.gitosis.conf` — il file da dove Gitosis legge le informazioni. Un invio al progetto prende il file `gitosis.conf` che hai appena inviato e lo posiziona li. Se modifichi questo file manualmente, rimarrà come lo hai lasciato fino al prossimo invio andato a termine nel progetto `gitosis-admin`.
## Gitolite ##
-Nota: l'ultima parte di questa sezione del libro ProGit è sempre disponibile nella [documentazione di gitolite][gldpg]. L'autore inoltre vuole modestamente far sapere che se questa sezione è accurata e *può* (se non *deve*) essere usata per installare gitolite senza leggere altra documentazione, per necessità non è completa e non può sostituire completamente l'enorme quantità di documentazione che è fornita con gitolite.
+Questa sezione serve come veloce introduzione a Gitolite, e fornisce basilari istruzioni di installazione e setup. Non può, tuttavia, sostituire l'enorme quantità di [documentazionee][gltoc] che è fornita con Gitolite. Potrebbero anche esserci occasionali cambiamenti a questa stessa sezione, pertanto potresti volere guardare l'ultima versione [qui][gldpg].
-[gldpg]: http://github.com/sitaramc/gitolite/blob/pu/doc/progit-article.mkd
+[gldpg]: http://sitaramc.github.com/gitolite/progit.html
+[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
-Git ha iniziato a diventare davvero popolare nelle grandi aziende, che tendono ad avere alcune richieste in più in termini di controllo degli accessi. Gitolite è stato inizialmente creato per venire incontro a queste richieste, ma è ugualmente utile nel mondo open source: il controllo degli accessi del Fedora Project al loro repository per la manutenzione dei pacchetti (sono più di 10,000!) usano gitolite e probabilmente è l'installazione più grande di gitolite esistente.
+Gitolite è un livello di autorizzazione sopra Git, affidandosi su `sshd` o `httpd` per l'autenticazione. (Riepilogo: autenticazione significa identificare chi sia l'utente, autorizzazione significa decidere se ad egli è consentito di fare ciò che sta provando a fare).
-Gitolite permette di specificare non solo i permessi per un repository, ma anche per i rami o i tag di ogni repository. Così si può specificare che certe persone (o gruppi di persone) possono fare il push solo su alcune "refs" (rami o tag) ma non su altri.
+Gitolite ti permette di specificare non solo i permessi per un repository, ma anche per i rami o le etichette di ogni repository. Così si può specificare che certe persone (o gruppi di persone) possono solo inviare ad alcuni "refs" (rami o etichette) ma non su altri.
### Installazione ###
-Installare Gitolite è davvero molto semplice, anche se non hai letto tutta la documenta