-
Notifications
You must be signed in to change notification settings - Fork 12
/
Copy path03s-using-github.md.erb
141 lines (83 loc) · 8.28 KB
/
03s-using-github.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
---
title: Utilizzare Git & GitHub
slug: github
date: 0003/01/02
number: 3.5
sidebar: true
contents: Come utilizzare GitHub per seguire passo passo il codice del libro.
paragraphs: 32
---
[GitHub](https://github.com/) è un deposito di stampo social per progetti open-source che si basa sul sistema di controllo versione [Git](http://git-scm.com/), il cui obiettivo principale è quello di rendere semplice il condividere codice e collaborare su progetti. È anche un gran strumento per l'apprendimento. In questo approfondimento, daremo un rapido sguardo su alcuni modi in cui potete utilizzare GitHub per seguire *Discover Meteor*.
Questo approfondimento presume che non conosciate molto Git e GitHub. Se invece li utilizzate già entrambi, sentitevi liberi di passare direttamente al prossimo capitolo!
### I Commit
La componente di base dell'uso di un repository Git è un *commit*. Si può pensare ad un commit come a un'istantanea che fotografa lo stato del vostro codice in un dato momento nel tempo.
Invece di dare semplicemente il codice completo di Microscope, abbiamo preso queste istantanee ad ogni passaggio della lavorazione, e le abbiamo rese tutte disponibili su GitHub.
Per esempio, questo è quello che si può vedere nell'[ultimo commit dello scorso capitolo](https://github.com/DiscoverMeteor/Microscope/commit/chapter3-2):
<%= screenshot "s3-1", "A Git commit as shown on GitHub." %>
Quello che si vede qui sotto è un “diff” (sta per “differenza”) del file `post_item.js`, in altre parole i cambiamenti inseriti in questo commit. In questo caso abbiamo creato il file `post_item.js` da zero, perciò tutti i suoi contenuti sono evidenziati in verde.
Facciamo un confronto con un esempio preso [un po' più avanti nel libro](https://github.com/DiscoverMeteor/Microscope/commit/chapter13-1):
<%= screenshot "s3-2", "Modifying code." %>
Questa volta solo le righe che sono state modificate sono evidenziate in verde.
Ovviamente, qualche volts non vengono aggiunte o modificate delle righe di codice, ma [vengono eliminate](https://github.com/DiscoverMeteor/Microscope/commit/chapter12-2):
<%= screenshot "s3-3", "Deleting code." %>
Questo è il principale utilizzo di GitHub: poter vedere cosa è cambiato con una sola occhiata.
### Come curiosare il codice di un Commit
La visualizzazione di un commit di Git mostra i cambiamenti inclusi in quel commit, ma a volte si ha bisogno di controllare file che *non* hanno subito cambiamenti, per sincerarsi che il loro contenuto sia esattamente quello che ci si aspetta.
Ancora una volta ci si può avvalere dell'aiuto di GitHub. Quando ci si trova sulla pagina di un commit, cliccare il bottone **Browse code**:
<%= screenshot "s3-5", "The Browse code button." %>
Si ha ora accesso alla repository *così come è in quel commit*:
<%= screenshot "s3-6", "The repository at commit 3-2." %>
GitHub non offre indicazioni chiare a livello visivo che si sta guardando un commit, ma si può impostare una comparazione con il master “normale”, e vedere a colpo d'occhio che la struttura dei file è differente:
<%= screenshot "s3-7", "The repository at commit 14-2." %>
### Accedere ad un Commit in locale
Si è appena visto come curiosare nell'intero codice di un commit direttamente su GitHub. Come si può fare la stessa cosa sulla propria macchina? Ad esempio potrebbe essere utile visualizzare la situazione dell'applicazione in un determinato commit sulla propria macchina, per poter verificare il funzionamento a quel punto della lavorazione.
Per poterlo fare, si deve procedere all'utilizzo dell'interfaccia di `git` a linea di comando dal terminale. Per chi non ha mai utilizzato questo strumento [bisogna prima installare Git](http://git-scm.com/downloads). In seguito bisogna **clonare** (cioè, scaricare una copia locale) il repository di Microscope con questo comando:
~~~bash
$ git clone [email protected]:DiscoverMeteor/Microscope.git github_microscope
~~~
La dicitura `github_microscope` in fondo al comando serve a dare il nome della cartella locale dove si vuole copiare l'applicazione. Assumendo che sia già presente una cartella `microscope`, si può scegliere un qualsiasi altro nome (non è necessario che sia lo stesso della repository presente su GitHub).
Una volta entrati nel repository (con il comando `cd`), si può iniziare ad utilizzare l'interfaccia a linea di comando:
~~~bash
$ cd github_microscope
~~~
Clonando il repository da GitHub, si è scaricato *tutto* il codice dell'applicazione, il che significa che quello che si vede è il codice del commit finale.
Fortunatamente c'è un modo per tornare indietro nel tempo e fare “checkout” di uno specifico commit senza che ciò abbia ripercursioni sugli altri. Nel terminale digitare:
~~~bash
$ git checkout chapter3-1
Note: checking out 'chapter3-1'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at a004b56... Added basic posts list template and static data.
~~~
Git informa che si è ora in uno stato denominato “detached HEAD”, che significa che fino a che Git rimane in questo stato è possibile osservare i vecchi commit ma non modificarli. Si può pensare a un mago che guarda il passato da una sfera di cristallo.
(Si noti che Git ha anche un comandi che permettono di *cambiare* commit precedenti. Questo è più paragonabile a un viaggiatore nel tempo che per caso calpesta una farfalla, ma è al di là di quello che vogliamo trattare in questo libro.)
Il motivo per il quale è bastato digitare `chapter3-1` è perché abbiamo nominato in precedenza tutti i commit di Microscope con un corretto indicatore (tag) del capitolo. Se non l'avessimo fatto si sarebbe dovuto prima trovare l'**hash** del commit, cioè il suò identificatore univoco.
Ancora una volta GitHub rende la vita più semplice. È possibile recuperare l'hash del commit nell'angolo in basso a destra dell'header box blu del commit come mostrato di seguito:
<%= screenshot "s3-4", "Finding a commit hash." %>
Si usi ora un hash al posto di un tag:
~~~bash
$ git checkout c7af59e425cd4e17c20cf99e51c8cd78f82c9932
Previous HEAD position was a004b56... Added basic posts list template and static data.
HEAD is now at c7af59e... Augmented the postsList route to take a limit
~~~
Infine, come smettere di guardare nella sfera di cristallo e tornare al presente? Si dice a Git di fare checkout del branch **master**:
~~~bash
$ git checkout master
~~~
Notate che potete anche lanciare l'applicazione con il comando `meteor` in qualsiasi momento del processo, anche se siente nello stato “detached HEAD”. Poterbbe essere che sia necessario lanciare prima `mrt update` se Meteor si lamenta di alcuni pacchetti mancanti, questo perché il codice dei pacchetti non è incluso nel repository Git di Microscope.
### Modalità History
Un altro scenario comune in Git è questo: guardando un file si notano alcuni cambiamenti mai visti prima. Il problema è quello di capire *quando* il file è stato modificato. Si potrebbe scorrere ad uno ad uno tutti i commit fino a trovare quello giusto, ma c'è un modo più semplice grazie alla modalità **History** di GitHub.
Da uno dei file del repository di GitHub, si cerchi il bottone “History”:
<%= screenshot "s3-8", "GitHub's History button." %>
Si può vedere un lista completa dei commit in cui è stato modificato il file in questione:
<%= screenshot "s3-9", "Displaying a file's history." %>
### Modalità Blame
Per concludere, si veda la modalità **Blame**:
<%= screenshot "s3-10", "GitHub's Blame button." %>
Questa visualizzazione mostra linea per linea chi ha modificato il file e in quale commit (in altre parole, chi bisogna redarguire - blame - quando le cose non funzionano come ci si aspetta):
<%= screenshot "s3-11", "GitHub's Blame view." %>
Git è uno strumento abbastanza complesso - così come GitHub -, non possiamo sperare di poter spiegare tutti in un solo capitolo. Infatti, abbiamo solo visto molto in superficie cosa sia possibile fare con questi strumenti. Speriamo che anche queste poche nozioni si rivelino utili mentre si prosegue nel resto del libro.