From: Mattia Rigotti Date: Tue, 4 Jun 2013 03:08:49 +0000 (-0400) Subject: Added basic.txt intro.txt preface.txt translate.txt to it version X-Git-Url: https://repo.or.cz/w/gitmagic.git/commitdiff_plain/313642f74a228b21afb18b358afc23c7f5165300 Added basic.txt intro.txt preface.txt translate.txt to it version --- diff --git a/it/basic.txt b/it/basic.txt new file mode 100644 index 0000000..b312ec3 --- /dev/null +++ b/it/basic.txt @@ -0,0 +1,269 @@ +== Trucchi di base == + +Piuttosto che immergerci nel mare di comandi di Git, bagnamoci un po' i +piedi con i seguenti esempi elementari. Nonostance la loro semplicità, +ognuno di loro è utile. In effetti, durante i miei mesi iniziali +d'utilizzazione di Git, non mi sono mai avventurato al di là di del +materiale in questo capitolo. + +=== Salvare lo stato corrente === + +Siete sul punto di fare qualcosa di drastico? Prima di proseguire, +catturate lo stato di tutti i files nella directory corrente: + + $ git init + $ git add . + $ git commit -m "Il mio primo backup" + +Qualora le cose dovessero andare per il peggio, potrete sempre +ripristinare la versione salvatae: + + $ git reset --hard + +Per salvare un nuovo state: + + $ git commit -a -m "Un altro backup" + +=== Aggiungere, rimuovere e rinominare files === + +Le istruzioni che abbiamo appena visto tengono traccia solo dei files + che erano presenti nel momento dell'esecuzione di *git add*. Ma se + aggiungete nuovi files o sottocartelle, dovrete dirlo a Git: + + $ git add readme.txt Documentation + +Analogamente se volete che Git ignori alcuni files: + + $ git rm kludge.h obsolete.c + $ git rm -r incriminating/evidence/ + +Git rimuoverà questi files per voi, se non l'avete ancora fatto. + +Un file può essere rinominato rimuovendo il vecchio nome e aggiungendo +il nuovo nome. È anche possibile usare la scorciatoia *git mv* che segue +la stessa sintassi del comando *mv*. Ad esempio: + + $ git mv bug.c feature.c + +=== Annullare/Ripristino avanzati === + +A volte può capitare che vogliate solamente ritornare indietro e +dimenticare le modifiche effettuate dopo un certo punto, perché sono +tutte sbagliate. In quel caso: + + $ git log + +vi nostra una lista dei commits più recenti, accompagnati dal loro +codice SHA1: + +---------------------------------- +commit 766f9881690d240ba334153047649b8b8f11c664 +Author: Bob +Date: Tue Mar 14 01:59:26 2000 -0800 + + Sostituzione di prinf() con write() + +commit 82f5ea346a2e651544956a8653c0f58dc151275c +Author: Alice +Date: Thu Jan 1 00:00:00 1970 +0000 + + Commit iniziale +---------------------------------- + +I primi caratteri del codice SHA1 sono sufficienti per specificare un +commit; alternativamente copiate e incollate l'intero codice SHA1. +Digitate: + + $ git reset --hard 766f + +per reinstaurare lo stato corrspondente al commit corrente e +permanetemente cancellare i commits più recenti. + +Altre volte potrebbe capitarvi di voler fare solo un breve salto in uno +stato precedente. In questo caso eseguite: + + $ git checkout 82f5 + +Questo vi riporta indietro nel tempo, preservando i commits più recenti. +Bisogna però sapere che, come in ogni viaggio nel tempo in un film di +fantascienza, se ora modificate e sottomettete un commit vi ritroverete +in una realtà alternativa, perché avrete fatto delle azioni differenti +rispetto alla realtà originaria. + +Questa realtà parallela viene chiamata 'ramificazione' o 'branch', et +<>. Per ora è abbastanza +ricordare che + + $ git checkout master + +vi riporta al presente. In oltre, per evitare che Git si lamenti, +ricordatevi di fare un commit o un reset delle vostre modifiche prima di +fare un checkout. + +Per riprendere l'analogia con i videogiochi digitate: + +- *`git reset --hard`* : carica un vecchio salvataggio e cancella + tutte le partite salvate più recenti di quella appena caricata. + +- *`git checkout`* : carica una vecchia partita, ma se ci giocate, lo + stato della partita sarà diverso da quello dei salvataggi successivi + che avete fato inizialmente. Da ora in poi ogni volta che salvate una + partita finirete in un branch separata che rappresenta la realtà + parallela in cui siete entrati. <>. + + +Potete scegliere di ripristinare files e sottocartelle particolari +aggiungendoli alla fine del seguente comando: + + $ git checkout 82f5 un.file un-altro.file + +Fate però attenzione: questa forma di *checkout* può sovrascrivere dei +files senza avvertimenti. Per evitare incidenti, fate un commit prima di +eseguire un comando di checkout, specialmente se siete alle prime armi +con Git. In generale, ogni volta che non siete sicuri delle conseguenze +di comando, che sia di Git o no, eseguite prima *git commit -a*. + +Non vi piace copiare e incollare codice hash? Allora utilizzate: + + $ git checkout :/"Il mio primo b" + +per saltare direttamente al commit che inizia con quel messaggio. Potete +anche chiedere, ad esempio, il quintultimo stato salvato: + + $ git checkout master~5 + +=== Annullare (revert) === + +In una corte di giustizia, certi avvenimenti possono essere stralciati +dal processo verbale. Analogamente, potete selezionare degli specifici +commit da annullare. + + $ git commit -a + $ git revert 1b6d + +annulla solo l'ultimo commit con il dato codice hash. Il revert viene +registrato come un nuovo commit, fatto che potrete verificare eseguendo +un *git log*. + +=== Generare un diario delle modifiche (changelog) === + +Certi progetti richiedono un +http://it.wikipedia.org/wiki/Changelog[changelog]. Createlo digitando: + + $ git log > ChangeLog + +=== Scaricare dei files === + +Fate una copia di un progetto gestito da Git digitando: + + $ git clone git://server/percorso/verso/files + +Ad esempio, per ottenere tutti i files che ho usato per creare questo +sito: + + $ git clone git://git.or.cz/gitmagic.git + +Avremo molto da dire a proposito del comando *clone* tra poco. + +=== L'ultima versione === + +Se avete già scaricato una copia di un progetto usando *git clone*, +potete aggiornarla all'ultima versione con: + + $ git pull + +=== Pubblicazione istantanea === + +Immaginate di aver scritto uno script che volete condividere con altri. +Potreste semplicemente dire loro di scaricarlo dal vostro computer, ma +le fanno mentre state migliorando lo script o sperimentando con delle +modifiche, potrebbero finire nei guai. Naturalmente, questo tipo di +situazioni sono la ragione per cui esistono i cicli di rilascio. Gli +sviluppatori possono lavorare frequentemente ad un progetto, ma +rilasciano il codice solo quando hanno l'impressione che sia +presentabile. + +Per fare questo con Git, nella cartella che contiene lo script eseguite: + + $ git init + $ git add . + $ git commit -m "Prima versione" + +In seguito dite agli utenti di eseguire: + + $ git clone il.vostro.computer:/percorso/verso/lo/script + +per scaricare il vostro script. Questo assume che tutti abbiamo accesso +ssh al vostro computer. Se non fosse il caso, esguite *git daemon* e +dite ai vostri utenti di eseguire invece: + + $ git clone git://il.vostro.computer/percorso/verso/lo/script + +A partire da questo momento, ogni volta che il vostro script è pronto +per essere rilasciato, eseguite: + + $ git commit -a -m "Nuova versione" + +e i vostri utenti potranno aggiornare la loro versione andando +nella cartella che contiene lo script e digitando: + + $ git pull + +I vostri utenti non si ritroveranno mai più con una versione del vostro +script che non volete che vedano. + +=== Che cosa ho fatto? === + +Ritroverete le modifiche fatte dall'ultimo commit con: + + $ git diff + +Oppure quelle a partire da ieri con: + + $ git diff "@{yesterday}" + +O tra una versione specifica e due versioni fa: + + $ git diff 1b6d "master~2" + +In ogni caso il risultato è una patch che può essere applicata con *git +apply*. +Potete anche provare: + + $ git whatchanged --since="2 weeks ago" + +Spesso esamino invece la storia dei commits con +http://sourceforge.net/projects/qgit[qgit], per via della sua +sfolgorante interfaccia, oppure http://jonas.nitro.dk/tig/[tig], +un'interfaccia in modalità testo che funziona bene anche con le +connessioni più lente. Alternativamente, installate un server web, +lanciate *git instaweb* e lanciate il vostro browser. + + +=== Esercizio === + + +Siano A, B, C, D quattro commits successivi, dove B è identico a A, con +l'eccezione che alcuni files sono stati rimossi. Vogliamo rimettere i +files in D. Come possiamo fare? + +Ci sono almeno tre soluzioni. Assumiamo che siao in D: + + 1. La differenza tra A e B sono i files rimossi. Possiamo creare una + patch che rappresenti la differenza e applicarla: + + $ git diff B A | git apply + + 2. Visto che i files in questioni sono presenti in A, possiamo + recuperarli: + + $ git checkout A foo.c bar.h + + 3. Possiamo anche pensare al passo da A a B come ad una modifica che + vogliamo annullare: + + $ git revert B + +Quel è la scelta migliore? Quella che preferite! È facile ottenere +quello che volete con Git, e spesso ci sono diversi modi di ottenerlo. diff --git a/it/intro.txt b/it/intro.txt new file mode 100644 index 0000000..f60743e --- /dev/null +++ b/it/intro.txt @@ -0,0 +1,157 @@ +== Introduzione == + +Farò uso di un'analogia per introdurre il controllo di versione. Fate +riferimento alla http://it.wikipedia.org/wiki/Controllo_versione[pagina +wikipedia sul controllo di versione] per una spiegazione più sobria. + +=== Il lavoro è gioco === + +Ho giocato ai videogiochi quasi tutta la mia vita. Per contro ho +iniziato ad utilizzare sistemi di controllo di versione solo da adulto. +Sospetto di non essere il solo, e il paragone tra i due può rendere +alcuni concetti più facile da spiegare e comprendere. + +Pensate alla scrittura di codice o documenti come ad un videogioco. +Non appena avete fatto progressi sostanziali, è desiderabile salvare il +vostro lavoro. Per fare ciò cliccate sul pulsante 'Salva' del vostro +fidato editor. + +Ma questo sovrascriverà la versione precedente del documento. È come +quei vecchi videogiochi in cui si poteva salvare la partita, ma senza +poter ritornare a uno stato precedente del gioco. Il che era un peccato, +perché il vostro salvataggio precedente avrebbe potuto trovarsi ad un punto +particolarmente divertente del gioco che avreste magari voluto +rivisitare in futuro. O ancora peggio se il vostro salvataggio più +recente si fosse rivelato essere uno stato da cui è impossibile vincere +il gioco, obbligandovi a ricominciare la partita da zero. + +=== Controllo di versione === + +Quando modificate un documento di cui volete conservare le vecchie +versioni, potete 'Salvare come...' sotto un nome di file diverso, oppure +copiare il file in un'altra cartella prima di salvarlo. Potreste anche +comprimere queste copie del file, se volete risparmiare spazio su +disco. Questa è una forma primitiva e inefficiente forma di controllo di +versione. I videogiochi hanno migliorato questo punto molto tempo fa, +provvedendo in molti casi multiple possibilità di salvataggio +automaticamente ordinate temporalmente. + +Rendiamo il problema un po' più complicato. Immaginate di avere un +un gruppo di files che vanno insieme, come il codice sorgente di un +progetto o i files per un sito web. In questo caso se volete conservare +una vecchia versione dovete archiviare una directory intera. Conservare +diverse versioni a mano non è scomodo e diventa rapidamente +impraticabile. + +Nel caso di alcuni videogiochi, il salvataggio di una partita consiste +effettivamente in una directory contenente diversi files. Questi giochi +nascondono questo dettaglio al giocatore e presentano una comoda +interfaccia per gestire le diverse versioni di tale cartella. + +I sistemi di controllo di versione non sono niente più di questo. Hanno +tutti una comoda interfaccia per gestire una directory piena di files. +Potete salvare lo stato della directory di tanto in tanto, e più tardi +potete caricare ognuno degli stati precedentemente salvati. A differenza +della maggioranza di videogiochi, conservano in maniere intelligente lo +spazio. Tipicamente, pochi files alla volta cambiano da una versione +alla successiva. Si può quindi risparmiare spazio salvando le differenze +invece di fare nuove copie complete. + +=== Controllo distribuito === + +Immaginate ora un videogioco difficilissimo. Così difficile da terminare +che molti esperti giocatori da tutto il mondo decidono di collaborare e +condividere le loro partite salvate per cercare di venirne a capo. +Gli http://it.wikipedia.org/wiki/Speedrun[Speedrun] sono un +esempio concreto di questa pratica: dei giocatori si specializzano +ognuno a giocare un livello dello stesso gioco nel miglior modo +possibile, e collaborano così per ottenere dei risultati incredibili. + +Come costruireste un sistema che permetta loro di accedere facilmente ai +salvataggi degli altri? E che permetta di caricarne di nuovi? + +Nel passato ogni progetto usava un sistema di controllo di versione +centralizzato. Un server centrale unico da qualche parte manteneva tutte le partite +salvate. Ogni giocatore conservava al massimo qualche salvataggio sul +proprio computer. Quando un giocatore aveva intenzione di avanzare nel +gioco, scaricava il salvataggio più recente dal server centrale, giocava +per un po', salvava e ricaricava sul server i progressi ottenuti così +che ognuno potesse usufruirne. + +Ma che cosa succedeva se un giocatore per qualche ragione voleva +accedere ad una vecchia partita salvata? Forse perché la versione più +attuale si trovava in uno stato da cui non era più possibile vincere il +gioco perché qualcuno aveva dimenticato di raccogliere un oggetto al +terzo livello, e ora era necessario ritrovare l'ultima partita salvata +in un momento in cui la partita è ancora completabile. O magari si +desiderava paragonare due partite salvate precedentemente per vedere +quanto progresso avesse fatto un giocatore particolare. + +Potrebbero esserci molte ragioni per voler recuperare una vecchia +versione, ma il risultato è sempre lo stesso: era necessario chiederla +al server centrale. E più partite salvate erano necessarie, più dati era +necessario trasmettere. + +La nuova generazione di sistemi di controllo di versione di cui Git fa +parte sono detti sistemi distribuiti e possono essere pensati come una +generalizzazione dei sistemi centralizzati. Quando i giocatori scaricano +dal server centrale ricevono tutti i giochi salvati, non solo l'ultima. +È come se fossero un +http://it.wikipedia.org/wiki/Mirror_(informatica)[mirror] del server +centrale. + +Questa operazione iniziale di clonaggio può essere costosa, soprattutto +se c'è una lunga storia di salvataggi precedenti. Ma a lungo termine è +una strategia che ripaga. Un beneficio immediato è che, quando per +qualche ragione si desidera un salvataggio precedente, non è necessario +comunicare con il server centrale. + +=== Una sciocca superstizione === + +Una credenza popolare vuole che i sistemi distribuiti non siano adatti a +progetti che richiedono un deposito centrale ufficiale. Niente potrebbe +essere più lontano dalla verità. Fotografare qualcuno non ne ruba +l'anima. Similarmente, clonare un deposito principale non ne diminuisce +l'importanza. + +Una buona prima approssimazione è che tutto ciò che può fare un sistema +di controllo di versione centralizzato può essere fatto meglio da un +sistema distribuito ben concepito. Le risorse di rete sono semplicemente +più costose che le risorse locali. Nonostante vedremo più in là che ci +sono alcuni svantaggi associati agli approcci distribuiti, ci sono meno +probabilità di fare paragoni sbagliate con questa approssimazione. + +Un piccolo progetto potrebbe non necessitare di tutte le funzionalità +offerte da un tale sistema, ma il fatto di usare un sistema +difficilmente estensibile per progetti piccoli è come usare il sistema +di numerazione romano per calcoli con numeri piccoli. + +In aggiunta il vostro progetto potrebbe crescere al di là delle vostre +previsioni iniziali. Usare Git dall'inizio è come avere sempre con se un +coltellino svizzero, anche se lo utilizzate primariamente per aprire +delle bottiglie. Quel giorno in cui avrete disperatamente bisogno un +cacciavite sarete felici di avere più di un semplice apribottiglie. + +=== Merge di conflitti === + +Per questo argomento la nostra analogia basata sui videogiochi inizia ad +essere tirata per i capelli. Ritorniamo quindi invece al caso della +formattazione di un documento. + +Immaginiamo che Alice inserisce una linea di codice all'inizio di un +file, e Bob ne aggiunge una alla fine della propria copia. Entrambi +caricano le loro modifiche nel deposito. La maggior parte dei sistemi +decideranno una linea d'azione ragionevole: accettare e fondere (merge) +entrambe le modifiche, così che sia le modifiche di Alice e Bob sono +applicate. + +Ma supponiamo ora che Alice e Bob hanno fatto distinte modifiche alla +stessa linea del documento. È impossibile procedere senza intervento +umano. La seconda persona a caricare il file viene informata di un +_conflitto di merge_, e bisogna scegliere una modifica piuttosto che un +altra, oppure riscrivere interamente la riga. + +Situazioni più complesse possono presentarsi. Sistemi di controllo di +versioni si possono occupare autonomamente dei casi più semplici, et +lasciano i casi difficili all'intervento umano. Generalmente, questo +comportamento è configurabile. diff --git a/it/preface.txt b/it/preface.txt new file mode 100644 index 0000000..1827b62 --- /dev/null +++ b/it/preface.txt @@ -0,0 +1,99 @@ += Git Magic = +Ben Lynn +Agosto 2007 + +== Prefazione == + +http://git.or.cz/[Git] è il coltellino svizzero per il controllo di +versioni. Uno strumento per la gestione di revisioni affidabile, +versatile e multifunzionale, ma la cui flessibilità ne rende difficile +l'apprendimento, e ancora di più la padronanza. + +Come osserva Arthur C. Clarke, qualunque tecnologia sufficientemente +avanzata è indistinguibile dalla magia. Questo è un buon atteggiamento +con cui approcciare Git: i novizi possono ignorare i suoi meccanismi +interni e utilizzare Git come fosse una bacchetta magica con cui +meravigliare gli amici e far infuriare gli avversari. + +Invece di dilungarci nei dettagli, vedremo quali istruzioni vanno usate +per ottenere risultati specifici. In seguito, grazie all'uso ripetuto, +capiremo il funzionamento di ognuno dei trucchi, e come possono essere +combinati per sopperire alle nostre necessità. + +.Traduzioni + + - link:/\~blynn/gitmagic/intl/zh_cn/[Cinese semplificato]: JunJie, Meng + e JiangWei. Conversione in link:/~blynn/gitmagic/intl/zh_tw/[Cinese + traditional] tramite +cconv -f UTF8-CN -t UTF8-TW+. + - link:/~blynn/gitmagic/intl/fr/[Francese]: Alexandre Garel, Paul + Gaborit, e Nicolas Deram. Anche scaricabile da http://tutoriels.itaapy.com/[itaapy]. + - link:/~blynn/gitmagic/intl/de/[Tedesco]: Benjamin Bellee e Armin + Stebich; anche scaricabile dal http://gitmagic.lordofbikes.de/[sito + web di Armin]. + - http://www.slideshare.net/slide_user/magia-git[Portoghese]: Leonardo + Siqueira Rodrigues + [http://www.slideshare.net/slide_user/magia-git-verso-odt[formato ODT]]. + - link:/~blynn/gitmagic/intl/ru/[Russo]: Tikhon Tarnavsky, Mikhail + Dymskov, e altri. + - link:/~blynn/gitmagic/intl/es/[Spagnolo]: Rodrigo Toledo e Ariset Llerena Tapia. + - link:/~blynn/gitmagic/intl/uk/[Ucraino]: Volodymyr Bodenchuk. + - link:/~blynn/gitmagic/intl/vi/[Vietnamita]: Trần Ngọc Quân; anche + scaribabile dal http://vnwildman.users.sourceforge.net/gitmagic/[suo + sito web]. + +.Altre edizioni + + - link:book.html[Pagina web individuale] : simplice documento + HTML, senza CSS ; + - link:book.pdf[File PDF]: versione stampabile. + - http://packages.debian.org/gitmagic[Pacchetto Debian], + http:://packages.ubuntu.com/gitmagic[pacchetto Ubuntu]: ottenete + rapidamente una copia locale. Pratico quando + http://csdcf.stanford.edu/status/[questo server] non è raggiungibile. + - http://www.amazon.com/Git-Magic-Ben-Lynn/dp/1451523343/[Libro vero e + proprio [Amazon.com]]: 64 pagine, 15.24cm x 22.86cm, bianco e nero, + in inglese. Pratico in caso di mancanza di elettricità. + +=== Grazie! === + +Voglio ringraziare le persone che hanno prestato il loro lavoro per +tradurre queste pagine. Sono grato di poter raggiungere un numero più +ampio di lettori grazie agli sforzi delle persone appena citate. + +Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael +Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, +Andy Somerville, Ralf Recker, Øyvind A. Holm, Miklos Vajna, Sébastien Hinderer, +Thomas Miedema, Joe Malin e Tyler Breisacher hanno contribuito con le +loro correzioni e miglioramenti. + +François Marier mantiene il pacchetto Debian, creato originariamente da +Daniel Baumarr. + +John Hinnegan ha acquistato il dominio http://www.gitmagic.com/[gitmagic.com]. + +Sono anche grato a molti altri per i loro sostegno e incoraggiamenti. +Sono tentato di menzionarvi qui, ma rischierei di alzare eccessivamente +le vostre aspettative. + +Se per errore ho dimenticato di menzionare qualcuno, fatemelo per favore +sapere, o mandatemi semplicemente una patch! + +=== Licenza === + +Questo manuale è pubblicato sotto la licenza http://www.gnu.org/licenses/gpl-3.0.html[GNU +General Public License version 3]. Naturalmente il codice sorgente è +disponibile come deposito Git, e si può ottenere digitando: + + $ git clone git://repo.or.cz/gitmagic.git # Crea la cartella + "gitmagic" + +oppure da altri server: + + $ git clone git://github.com/blynn/gitmagic.git + $ git clone git://gitorious.org/gitmagic/mainline.git + $ git clone https://code.google.com/p/gitmagic/ + $ git clone git://git.assembla.com/gitmagic.git + $ git clone git@bitbucket.org:blynn/gitmagic.git + +GitHub, Assembla, e Bitbucket supportano deposito privati, gli ultimi +due sono gratuiti. diff --git a/it/translate.txt b/it/translate.txt new file mode 100644 index 0000000..c8727b5 --- /dev/null +++ b/it/translate.txt @@ -0,0 +1,38 @@ +== Appendice B: Tradurre Questo Manuale == + +La mia raccomandazione è di rispettare la seguente procedura per la +traduzione di questo manuale, in maniera da poter rapidamente generare +le versioni HTML e PDF del documento con gli script forniti, e così che +tutte le traduzioni siano incorporate nello stesso repository. + +Fate un clone della sorgente, poi create una directory il cui nome +corrisponda http://www.iana.org/assignments/language-subtag-registry[al +codice IETF della lingua desiderata] : vedere +http://www.w3.org/International/articles/language-tags/Overview.en.php[l'articolo +del W3C concernente internationalizzazione]. Per esempio la versione in +inglese è nella directory "en", quella in giapponese è in "ja". Nella +nuova directory traducete i file +txt+ della directory originari "en". + +Per esempio, per creare questa guida in +http://it.wikipedia.org/wiki/Lingua_klingon[Klingon], eseguite: + + $ git clone git://repo.or.cz/gitmagic.git + $ cd gitmagic + $ mkdir tlh # "tlh" è il codice IETF della lingua Klingon. + $ cd tlh + $ cp ../en/intro.txt . + $ edit intro.txt # Tradurre il file. + +e così di seguito per tutti i file. + +Modificate il Makefile aggiungendo il codice della lingua alla +variabile `TRANSLATIONS`. In questo modo potete rivedere il vostro +lavoro in modo incrementale: + + $ make tlh + $ firefox book-tlh/index.html + +Fate spesso dei commit per le vostre modifiche e avvertitemi non appena +sono state implementate. Github possiede un'interfaccia che facilita il +lavoro collaborativo: fate un fork del progetto "gitmagic", fate un +push delle vostre modifiche, e chiedetemi di incorporarle.