it/intro.txt

   1 == Introduzione ==
   2
   3 Farò uso di un'analogia per introdurre il controllo di versione. Fate
   4 riferimento alla http://it.wikipedia.org/wiki/Controllo_versione[pagina
   5 wikipedia sul controllo di versione] per una spiegazione più sobria.
   6
   7 === Il lavoro è gioco ===
   8
   9 Ho giocato ai videogiochi quasi tutta la mia vita. Per contro ho
  10 iniziato ad utilizzare sistemi di controllo di versione solo da adulto.
  11 Sospetto di non essere il solo, e il paragone tra i due può rendere
  12 alcuni concetti più facile da spiegare e comprendere.
  13
  14 Pensate alla scrittura di codice o documenti come ad un videogioco.
  15 Non appena avete fatto progressi sostanziali, è desiderabile salvare il
  16 vostro lavoro. Per fare ciò cliccate sul pulsante 'Salva' del vostro
  17 fidato editor.
  18
  19 Ma questo sovrascriverà la versione precedente del documento. È come
  20 quei vecchi videogiochi in cui si poteva salvare la partita, ma senza
  21 poter ritornare a uno stato precedente del gioco. Il che era un peccato,
  22 perché il vostro salvataggio precedente avrebbe potuto trovarsi ad un punto
  23 particolarmente divertente del gioco che avreste magari voluto
  24 rivisitare in futuro. O ancora peggio se il vostro salvataggio più
  25 recente si fosse rivelato essere uno stato da cui è impossibile vincere
  26 il gioco, obbligandovi a ricominciare la partita da zero.
  27
  28 === Controllo di versione ===
  29
  30 Quando modificate un documento di cui volete conservare le vecchie
  31 versioni, potete 'Salvare come...' sotto un nome di file diverso, oppure
  32 copiare il file in un'altra cartella prima di salvarlo. Potreste anche
  33 comprimere  queste copie del file, se volete risparmiare spazio su
  34 disco. Questa è una forma primitiva e inefficiente forma di controllo di
  35 versione. I videogiochi hanno migliorato questo punto molto tempo fa,
  36 provvedendo in molti casi multiple possibilità di salvataggio
  37 automaticamente ordinate temporalmente.
  38
  39 Rendiamo il problema un po' più complicato. Immaginate di avere un
  40 un gruppo di files che vanno insieme, come il codice sorgente di un
  41 progetto o i files per un sito web. In questo caso se volete conservare
  42 una vecchia versione dovete archiviare una directory intera. Conservare
  43 diverse versioni a mano non è scomodo e diventa rapidamente
  44 impraticabile.
  45
  46 Nel caso di alcuni videogiochi, il salvataggio di una partita consiste
  47 effettivamente in una directory contenente diversi files. Questi giochi
  48 nascondono questo dettaglio al giocatore e presentano una comoda
  49 interfaccia per gestire le diverse versioni di tale cartella.
  50
  51 I sistemi di controllo di versione non sono niente più di questo. Hanno
  52 tutti una comoda interfaccia per gestire una directory piena di files.
  53 Potete salvare lo stato della directory di tanto in tanto, e più tardi
  54 potete caricare ognuno degli stati precedentemente salvati. A differenza
  55 della maggioranza di videogiochi, conservano in maniere intelligente lo
  56 spazio. Tipicamente, pochi files alla volta cambiano da una versione
  57 alla successiva. Si può quindi risparmiare spazio salvando le differenze
  58 invece di fare nuove copie complete.
  59
  60 === Controllo distribuito ===
  61
  62 Immaginate ora un videogioco difficilissimo. Così difficile da terminare
  63 che molti esperti giocatori da tutto il mondo decidono di collaborare e
  64 condividere le loro partite salvate per cercare di venirne a capo.
  65 Gli http://it.wikipedia.org/wiki/Speedrun[Speedrun] sono un
  66 esempio concreto di questa pratica: dei giocatori si specializzano
  67 ognuno a giocare un livello dello stesso gioco nel miglior modo
  68 possibile, e collaborano così per ottenere dei risultati incredibili.
  69
  70 Come costruireste un sistema che permetta loro di accedere facilmente ai
  71 salvataggi degli altri? E che permetta di caricarne di nuovi?
  72
  73 Nel passato ogni progetto usava un sistema di controllo di versione
  74 centralizzato. Un server centrale unico da qualche parte manteneva tutte le partite
  75 salvate. Ogni giocatore conservava al massimo qualche salvataggio sul
  76 proprio computer. Quando un giocatore aveva intenzione di avanzare nel
  77 gioco, scaricava il salvataggio più recente dal server centrale, giocava
  78 per un po', salvava e ricaricava sul server i progressi ottenuti così
  79 che ognuno potesse usufruirne.
  80
  81 Ma che cosa succedeva se un giocatore per qualche ragione voleva
  82 accedere ad una vecchia partita salvata? Forse perché la versione più
  83 attuale si trovava in uno stato da cui non era più possibile vincere il
  84 gioco perché qualcuno aveva dimenticato di raccogliere un oggetto al
  85 terzo livello, e ora era necessario ritrovare l'ultima partita salvata
  86 in un momento in cui la partita è ancora completabile. O magari si
  87 desiderava paragonare due partite salvate precedentemente per vedere
  88 quanto progresso avesse fatto un giocatore particolare.
  89
  90 Potrebbero esserci molte ragioni per voler recuperare una vecchia
  91 versione, ma il risultato è sempre lo stesso: era necessario chiederla
  92 al server centrale. E più partite salvate erano necessarie, più dati era
  93 necessario trasmettere.
  94
  95 La nuova generazione di sistemi di controllo di versione di cui Git fa
  96 parte sono detti sistemi distribuiti e possono essere pensati come una
  97 generalizzazione dei sistemi centralizzati. Quando i giocatori scaricano
  98 dal server centrale ricevono tutti i giochi salvati, non solo l'ultima.
  99 È come se fossero un
 100 http://it.wikipedia.org/wiki/Mirror_(informatica)[mirror] del server
 101 centrale.
 102
 103 Questa operazione iniziale di clonaggio può essere costosa, soprattutto
 104 se c'è una lunga storia di salvataggi precedenti. Ma a lungo termine è
 105 una strategia che ripaga. Un beneficio immediato è che, quando per
 106 qualche ragione si desidera un salvataggio precedente, non è necessario
 107 comunicare con il server centrale.
 108
 109 === Una sciocca superstizione  ===
 110
 111 Una credenza popolare vuole che i sistemi distribuiti non siano adatti a
 112 progetti che richiedono un deposito centrale ufficiale. Niente potrebbe
 113 essere più lontano dalla verità. Fotografare qualcuno non ne ruba
 114 l'anima. Similarmente, clonare un deposito principale non ne diminuisce
 115 l'importanza.
 116
 117 Una buona prima approssimazione è che tutto ciò che può fare un sistema
 118 di controllo di versione centralizzato può essere fatto meglio da un
 119 sistema distribuito ben concepito. Le risorse di rete sono semplicemente
 120 più costose che le risorse locali. Nonostante vedremo più in là che ci
 121 sono alcuni svantaggi associati agli approcci distribuiti, ci sono meno
 122 probabilità di fare paragoni sbagliate con questa approssimazione.
 123
 124 Un piccolo progetto potrebbe non necessitare di tutte le funzionalità
 125 offerte da un tale sistema, ma il fatto di usare un sistema
 126 difficilmente estensibile per progetti piccoli è come usare il sistema
 127 di numerazione romano per calcoli con numeri piccoli.
 128
 129 In aggiunta il vostro progetto potrebbe crescere al di là delle vostre
 130 previsioni iniziali. Usare Git dall'inizio è come avere sempre con se un
 131 coltellino svizzero, anche se lo utilizzate primariamente per aprire
 132 delle bottiglie. Quel giorno in cui avrete disperatamente bisogno un
 133 cacciavite sarete felici di avere più di un semplice apribottiglie.
 134
 135 === Merge di conflitti ===
 136
 137 Per questo argomento la nostra analogia basata sui videogiochi inizia ad
 138 essere tirata per i capelli. Ritorniamo quindi invece al caso della
 139 formattazione di un documento.
 140
 141 Immaginiamo che Alice inserisce una linea di codice all'inizio di un
 142 file, e Bob ne aggiunge una alla fine della propria copia. Entrambi
 143 caricano le loro modifiche nel deposito. La maggior parte dei sistemi
 144 decideranno una linea d'azione ragionevole: accettare e fondere (merge)
 145 entrambe le modifiche, così che sia le modifiche di Alice e Bob sono
 146 applicate.
 147
 148 Ma supponiamo ora che Alice e Bob hanno fatto distinte modifiche alla
 149 stessa linea del documento. È impossibile procedere senza intervento
 150 umano. La seconda persona a caricare il file viene informata di un
 151 _conflitto di merge_, e bisogna scegliere una modifica piuttosto che un
 152 altra, oppure riscrivere interamente la riga.
 153
 154 Situazioni più complesse possono presentarsi. Sistemi di controllo di
 155 versioni si possono occupare autonomamente dei casi più semplici, et
 156 lasciano i casi difficili all'intervento umano. Generalmente, questo
 157 comportamento è configurabile.