Mention on it version in de, en, fr versions
[gitmagic.git] / it / branch.txt
blob565152cee468ce561c40d10fcef9a0abf3334392
1 == La stregoneria delle branch ==
3 Le funzioni di merge e di ramificazione (o 'branch') sono le migliori 
4 "killer features" di Git.
6 *Problema*: Fattori esterni conducono inevitabilmente a cambiamenti di
7 contesto. Un grave bug si manifesta inaspettatamente nella versione di
8 release. La scadenza per una particolare funzionalità viene anticipata.
9 Uno sviluppatore che doveva collaborare con voi su una parte delicata
10 di un progetto non è più disponibile. In ogni caso, dovete bruscamente
11 smettere quello che stavate facendo per concentrarvi su un compito
12 completamente diverso.
14 Interrompere il flusso dei vostri pensieri può essere controproducente
15 e, più scomodo è il cambiamento di contesto, più grande è lo svantaggio.
16 Con un sistema di controllo di versione centralizzato bisognerebbe
17 scaricare una nuova copia del lavoro dal server centrale. Un sistema
18 decentralizzato è migliore perché permette di clonare localmente la
19 versione che si vuole.
21 Ma clonare richiede comunque di copiare un'intera cartella di lavoro, in
22 aggiunta all'intera storia fino al punto voluto. Anche se Git riduce i
23 costi tramite la condivisione di file e gli hard link, i file di
24 progetto stessi devono essere ricreati interamente nella nuova cartella
25 di lavoro.
27 *Soluzione*: Git ha un metodo migliore per queste situazioni che è molto
28 migliore ed efficiente in termini di spazio che il clonaggio: il comando 
29 *git branch*.
31 Grazie a questa parola magica i file nella directory si trasformano
32 immediatamente da una versione a un'altra. Questa trasformazione può
33 fare molto di più che portarvi avanti e indietro nella storia del
34 progetto. I vostri file possono trasformarsi dall'ultima release alla
35 versione corrente di sviluppo, alla versione di un vostro collega, ecc.
37 === Boss key ===
39 Avete mai giocato ad uno di quei giochi che possiedono un tasto (il
40 ``boss key``) che nasconde immediatamente la schermata coprendola con
41 qualcosa come una tabella di calcolo? In questo modo, se il vostro capo,
42 entra nel vostro ufficio mentre state giocando potete nasconderlo
43 rapidamente.
45 In una cartella vuota eseguite:
47  $ echo "Sono più intelligente che il mio capo." > myfile.txt
48  $ git init
49  $ git add .
50  $ git commit -m "Commit iniziale"
52 Avete appena creato un deposito Git che gestisce un file di testo che
53 contiene un certo messaggio. Adesso digitate:
55  $ git checkout -b capo  # niente sembra essere cambiato dopo questo
56  $ echo "Il mio capo è più intelligente di me." > myfile.txt
57  $ git commit -a -m "Un altro commit"
59 Tutto sembra come se aveste semplicemente sovrascritto il vostro
60 file e messo in commit le modifiche. Ma questo non è che un'illusione.
61 Ora digitate:
63  $ git checkout master  # Passa alla versione originale del file
65 e voilà! Il file di testo è ritornato alla versione originale. E se il
66 vostro capo si mettesse a curiosare in questa cartella eseguite:
68  $ git checkout capo  # Passa alla versione accettabile dal capo
70 Potete passare da una versione all'altra in qualsiasi momento, e mettere
71 in commit le vostre modifiche per ognuna indipendentemente.
73 === Lavoro temporaneo ===
75 [[branch]] 
76 Diciamo che state lavorando ad una funzionalità e, per qualche ragione,
77 dovete ritornare a tre versioni precedenti e temporaneamente aggiungere
78 qualche istruzione per vedere come funziona qualcosa. Fate: 
80  $ git commit -a
81  $ git checkout HEAD~3
83 Ora potete aggiungere codice temporaneo ovunque vogliate. Potete
84 addirittura fare un commit dei cambiamenti. Quando avete finito
85 eseguite: 
87  $ git checkout master
89 per ritornare al vostro lavoro originario. Ricordatevi che i cambiamenti
90 non sottomessi ad un commit andranno persi.
92 Che fare se nonostante tutto voleste salvare questi cambiamenti
93 temporanei? Facile:
95  $ git checkout -b temporaneo
97 e fate un commit prima di ritornare alla branch master. Qualora voleste
98 ritornare ai cambiamenti temporanei, eseguite semplicemente:
100  $ git checkout temporaneo
102 Abbiamo già parlato del comando _checkout_ in un capitolo precedente, mentre
103 discutevamo il caricamento di vecchi stati. Ne parleremo ancora più
104 avanti. Per ora ci basta sapere questo: i file vengono cambiati allo
105 stato richiesto, ma bisogna lasciare la branch master. A partire da
106 questo momento, tutti i commit porteranno i vostri file su una strada
107 diversa che potrà essere nominata più avanti.
109 In altre parole, dopo un checkout verso uno stato precedente, Git ci
110 posiziona automaticamente in una nuova branch anonima che potrà essere
111 nominata e salvata con *git checkout -b*.
113 === Correzioni rapide ===
115 Diciamo che state lavorando su qualcosa e vi viene improvvisamente
116 richiesto di lasciar perdere tutto per correggere un bug appena scoperto
117 nella versione `1b6d...` :
119  $ git commit -a
120  $ git checkout -b correzioni 1b6d
122 Poi, quando avete corretto il bug, eseguite:
124  $ git commit -a -m "Bug corretto"
125  $ git checkout master
127 per riprendere il lavoro originario. Potete anche fare un 'merge' delle
128 nuove correzioni del bug:
130  $ git merge correzioni
132 === Merge ===
134 Con alcuni sistemi di controllo di versione creare delle branch è
135 molto facile, ma fare un merge è difficile. Com Git, fare un merge è
136 così facile che potreste anche non accorgervi che lo state facendo.
138 Infatti abbiamo già incontrato il merge molto tempo fa. Il comando
139 *pull* recupera, ('fetch') una serie di versioni e le incorpora
140 ('merge') nella branch corrente. Se non ci sono cambiamenti locali, il
141 merge è un semplicemente salto in avanti (un _fast forward_), un caso
142 degenere simile a ottenere la versione più recente in un sistema di
143 controllo di versione centralizzato. Ma se ci sono cambiamenti locali,
144 Git farà automaticamente un merge, riportando tutti i conflitti.
146 Normalmente una versione ha una sola 'versione genitore', vale a dire la
147 versione precedente. Fare un merge di brach produce una versione con
148 almeno due genitori. Questo solleva la seguente domanda: a quale
149 versione corrisponde `HEAD~10`? Visto che una versione può avere
150 parecchi genitori, quali dobbiamo seguire?
152 Si dà il caso che questa notazione si riferisce sempre al primo
153 genitore. Questo è desiderabile perché la versione corrente diventa il
154 primo genitore in un merge; e spesso si è più interessati ai cambiamenti
155 fatti nella branch corrente, piuttosto che ai cambiamenti integrati
156 dalle altre branch.
158 Potete fare riferimento ad un genitore specifico con un accento
159 circonflesso. Ad esempio, per vedere il log del secondo genitore:
161  $ git log HEAD^2
163 Potete omettere il numero per il primo genitore. Ad esempio, per vedere
164 le differenze con il primo genitore:
166  $ git diff HEAD^
168 Potete combinare questa notazione con le altre. Ad esempio:
170  $ git checkout 1b6d^^2~10 -b ancient
172 inizia la nuova branch ``ancient'' nello stato corrispondente a 10
173 versioni precedenti il secondo genitore del primo genitore del commit il
174 cui nome inizia con 1b6d.
176 === Flusso di lavoro ininterrotto ===
178 Spesso in un progetto ``hardware'' la seconda tappa deve aspettare il
179 completamento della prima. Un'automobile in riparazione deve rimanere
180 bloccata in garage fino all'arrivo di una particolare parte di ricambio.
181 Un prototipo deve aspettare la fabbricazione di un processore prima che
182 la costruzione possa continuare.
184 I progetti software possono essere simili. La seconda parte di una nuova
185 funzionalità può dover aspettare fino a che la prima parte venga
186 completata e testata. Alcuni progetti richiedono che il vostro codice
187 sia rivisto prima di essere accettato. Siete quindi obbligati ad
188 aspettare l'approvazione della prima parte prima di iniziare la seconda.
190 Grazie alla facilità con cui si creano delle branch e si effettua un
191 merge, si possono piegare le regole e lavorare sulla parte II prima che la parte I
192 sia ufficialmente pronta. Supponiamo che avete fatto il commit della
193 parte I e l'avete sottomessa per approvazione. Diciamo che siete nella
194 branch `master`. Create allora una nuova branch così:
196  $ git checkout -b part2
198 In seguito, lavorate sulla parte II, fate il commit dei cambiamenti
199 quando necessario. Errare è umano, e spesso vorrete tornare indietro e
200 aggiustare qualcosa nella parte I. Se siete fortunati, o molto bravi,
201 potete saltare questo passaggio.
203  $ git checkout master  # Ritorno alla parte 1
204  $ correzione_problemi
205  $ git commit -a        # Commit delle correzioni. 
206  $ git checkout part2   # Ritorno alla parte 2.
207  $ git merge master     # Merge delle correzioni.
209 Finalmente la parte I è approvata.
211  $ git checkout master    # Ritorno alla parte I. 
212  $ distribuzione files    # Distribuzione in tutto il mondo! 
213  $ git merge part2        # Merge della parte II
214  $ git branch -d part2    # Eliminazione della branch "part2"
216 In questo momento siete di nuovo nella branch `master`, con la parte II
217 nella vostra cartella di lavoro.
219 È facile estendere questo trucco a qualsiasi numero di parti. È anche
220 facile creare delle branch retroattivamente: supponiamo che ad un certo
221 punto vi accorgete che avreste dovuto creare una branch 7 commit fa.
222 Digitate allora:
224  $ git branch -m master part2  # Rinomina la branch "master" con il nome "part2".
225  $ git branch master HEAD~7    # Crea una nuova branch "master" 7 commits nel passato.
227 La branch `master` contiene ora solo la parte I, e la branch `part2`
228 contiene il resto. Noi siamo in questa seconda branch; abbiamo creato
229 `master` senza spostarvici perché vogliamo continuare a lavorare su
230 `part2`. Questo è inusuale. Fino ad ora spostavamo in una branch non
231 appena la creavamo, come in:
233  $ git checkout HEAD~7 -b master  # Crea una branch, e vi si sposta.
235 === Riorganizzare un pasticcio ===
237 Magari vi piace lavorare su tutti gli aspetti di un progetto nella
238 stessa branch. Volete che i vostri lavori in corso siano accessibili
239 solo a voi stessi e volete che altri possano vedere le vostre versioni
240 solo quando sono ben organizzate. Cominciamo creando due branch:
242   $ git branch ordine           # Crea una branch per commit organizzati.
243   $ git checkout -b pasticcio   # Crea e si sposta in una branch in cui lavorare 
245 In seguito lavorate su tutto quello che volete: correggere bugs,
246 aggiungere funzionalità, aggiungere codice temporaneo, e così via,
247 facendo commit quando necessario. Poi:
249   $ git checkout ordine
250   $ git cherry-pick pasticcio^^
252 applica le modifiche della versione progenitore della corrente versione
253 ``pasticcio'' alla versione ``ordine''. Con i cherry-pick appropriati
254 potete costruire una branch che contiene solo il codice permanente e
255 che raggruppa tutti i commit collegati. 
257 === Gestione di branch ===
259 Per ottenere una lista di tutte le branch, digitate:
261  $ git branch
263 Per default iniziate nella branch chiamata ``master''. Alcuni
264 raccomandano di lasciare la branch ``master'' intatta e di creare nuove
265 branch per le proprie modifiche.
267 Le opzioni *-d* e *-m* permettono di cancellare e spostare (rinominare)
268 le branch. Per più informazioni vedete *git help branch*.
270 La branch ``master'' è una convenzione utile. Gli altri possono assumere
271 che il vostro deposito ha una branch con quel nome, e che questa
272 contiene la versione ufficiale del vostro progetto. Nonostante sia
273 possibile rinominare o cancellare la branch ``master'', può essere utile
274 rispettare le tradizioni.
276 === Branch temporanee ===
278 Dopo un certo tempo d'utilizzo potreste accorgervi che create
279 frequentemente branch temporanee per ragioni simili: vi servono
280 solamente per salvare lo stato corrente così da rapidamente saltare ad
281 uno stato precedente per correggere un bug prioritario o qualcosa di
282 simile.
284 È analogo a cambiare temporaneamente canale televisivo per vedere
285 cos'altro c'è alla TV. Ma invece di premere un paio di bottoni, dovete
286 creare, spostarvi, fare merge e cancellare branch temporanee.
287 Fortunatamente Git possiede una scorciatoia che è altrettanto pratica
288 che il telecomando del vostro televisore:
290  $ git stash
292 Questo salva lo stato corrente in un posto temporaneo (uno 'stash') e
293 ristabilisce lo stato precedente. La vostra cartella di lavoro appare
294 esattamente com'era prima di fare le modifiche e potete correggere bugs,
295 incorporare cambiamenti del deposito centrale (pull), e così via. Quando
296 volete ritornare allo stato corrispondente al vostro 'stash', eseguite:
298  $ git stash apply  # Potreste dover risolvere qualche conflitto.
300 Potete avere stash multipli, e manipolarli in modi diversi. Vedere *git
301 help stash* per avere più informazioni. Come avrete indovinato, Git
302 mantiene delle branch dietro le quinte per realizzare questi trucchi
303 magici.
305 === Lavorate come volete ===
307 Potreste chiedervi se vale la pena usare delle branch. Dopotutto creare
308 dei cloni è un processo altrettanto rapido e potete passare da uno
309 all'altro con un semplice *cd*, invece che gli esoterici comandi di Git. 
311 Consideriamo un browser web. Perché supportare tabs multiple oltre a
312 finestre multiple? Perché permettere entrambi accomoda una gamma
313 d'utilizzazione più ampia. Ad alcuni utenti piace avere una sola
314 finestra e usare tabs per multiple pagine web. Altri insistono con
315 l'estremo opposto: multiple finestre senza tabs. Altri ancora
316 preferiscono qualcosa a metà.
318 Le branch sono come delle tabs per la vostra cartella di lavoro, e i
319 cloni sono come nuove finestre del vostro browser. Queste operazioni
320 sono tutte veloci e locali. Quindi perché non sperimentare per trovare
321 la combinazione che più vi si addice? Con Git potete lavorare
322 esattamente come volete.