-
Notifications
You must be signed in to change notification settings - Fork 32
/
03s-using-github.md.erb
144 lines (86 loc) · 8.34 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
142
143
144
---
title: Utiliser Git & GitHub
slug: github
date: 0003/01/02
number: 3.5
points: 5
sidebar: true
photoUrl: http://www.flickr.com/photos/ikewinski/7170807209/
photoAuthor: Mike Lewinski
contents: Découvrir comment utiliser GitHub pour suivre avec le livre.
paragraphs: 32
---
[GitHub](https://github.com/) est un dépôt social pour les projets open-source basé sur le système de contrôle de version [Git](http://git-scm.com/), et sa fonction première est de partager du code facilement et de collaborer sur des projets. Mais c'est aussi un merveilleux outil d'apprentissage. Dans cette sidebar, nous allons rapidement discuter de quelques moyens pour que vous puissiez utiliser GitHub afin de suivre avec *Discover Meteor*.
Cet aparté suppose que vous n'êtes pas familier avec Git et GitHub. Si vous êtes déjà à l'aise avec les deux, vous êtes libres de passer au chapitre suivant !
### Être committed
Le bloc de travail de base d'un dépôt git est le *commit*. Vous pouvez imaginer le commit comme une image de l'état de votre code à un moment donné dans le temps.
Au lieu de vous donner simplement le code fini pour Microscope, nous avons pris ces images à chaque étape du développement, et vous pouvez toutes les voir en ligne sur GitHub.
Par exemple, c'est ce à quoi [le dernier commit du chapitre précédent](https://github.com/DiscoverMeteor/Microscope/commit/chapter3-2) ressemble :
<%= screenshot "s3-1", "Un commit Git vu sur GitHub." %>
Ce que vous voyez ici est le "diff" (pour "difference") du fichier `post_item.js`, en d'autres termes les changements introduits par ce commit. Dans ce cas, nous avons créé le fichier `post_item.js` à partir de rien, et donc tout son contenu est surligné en vert.
Comparons avec un exemple [plus loin dans le livre](https://github.com/DiscoverMeteor/Microscope/commit/chapter13-1) :
<%= screenshot "s3-2", "Modifier du code." %>
Cette fois, seuls les fichiers modifiés sont surlignés en vert.
Et bien sur, parfois nous n'avons pas ajouté ou modifié de lignes de code, mais nous en [avons supprimées](https://github.com/DiscoverMeteor/Microscope/commit/chapter12-2) :
<%= screenshot "s3-3", "Supprimer du code." %>
Bien, nous venons de voir la première utilisation de GitHub : avoir une vue d'ensemble de ce qui a changé.
### Explorer le code d'un Commit
La vue d'un commit de Git nous montre les changements inclus dans ce commit, mais parfois vous voudriez voir les fichiers qui *n'ont pas* changés, juste pour s'assurer de ce à quoi leur code doit ressembler à une étape du processus.
Une fois encore, GitHub a quelque chose à nous proposer. Quand vous êtes sur une page de commit, cliquez sur le bouton **Browse code** :
<%= screenshot "s3-5", "Le bouton Browse code." %>
Vous allez maintenant avoir accès au dépôt *tel qu'il est à ce moment spécifique du commit*
<%= screenshot "s3-6", "Le dépôt au commit 3-2." %>
GitHub ne nous donne pas d'indices visuels que vous êtes en train de regarder un commit, mais vous pouvez comparer avec la vue master "normale" et voir d'un coup d'oeil que la structure de fichiers est différente :
<%= screenshot "s3-7", "Le dépôt au commit 14-2." %>
### Accéder à un commit localement
Nous venons de voir comment explorer le code entier d'un commit en ligne sur GitHub. Mais comment faire si vous voulez faire la même chose localement ? Par exemple, vous pourriez vouloir exécuter une application localement à un commit spécifique pour voir comment elle se comportait à ce moment du processus.
Pour faire ça il y a plusieurs étapes (bien, dans ce livre du moins) avec l'utilitaire en ligne de commande `git`. Pour les débutants, [assurez vous d'avoir Git installé](http://git-scm.com/downloads). Ensuite **clone** (en d'autres termes, télécharger une copie localement) le dépôt de Microscope avec :
~~~bash
git clone https://github.com/DiscoverMeteor/Microscope.git github_microscope
~~~
Ce `github_microscope` à la fin est simplement le nom du répertoire local dans lequel vous allez cloner l'application. Dans le cas où vous avez déjà un répertoire `microscope`, prenez juste un nom différent (il n'y a pas besoin d'avoir le même nom que le dépôt GitHub).
Allez dans le répertoire avec la commande `cd` afin de pouvoir utiliser l'utilitaire en ligne de commande `git` :
~~~bash
cd github_microscope
~~~
Quand nous avons cloné le dépôt de GitHub, nous avons téléchargé *tout* le code de l'application, ce qui veut dire que nous avons le code du dernier commit.
Heureusement, il y a un moyen de revenir dans le temps et de "consulter" un commit spécifique sans affecter les autres. Essayons :
~~~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 vous informe que vous êtes dans un état “detached HEAD”, ce qui signifie qu'aussi loin que Git a été utilisé, vous pouvez observer les commits passés mais vous ne pouvez les modifier. Vous pouvez imaginer ça comme un sorcier en train de consulter le passé dans sa boule de cristal.
(Notez que Git a également des commandes qui vous laisse *modifier* des commits passés. Ça serait plus comme un voyageur du temps qui revient dans le passé et peut potentiellement écraser un papillon, mais c'est hors du champ de cette brève introduction.)
La raison pour laquelle vous avez pu simplement taper `chapter3-1` est que nous avons pre-taggé tous les commits de Microscope avec le marqueur de chapitre correcte. Si ça n'était pas le cas, vous auriez besoin de trouver le **hash** du commit, ou un identifiant unique.
Une fois encore, GitHub nous simplifie la vie. Vous pouvez trouver un hash de commit dans le coin en bas à droite du champ d'entête de commit bleu, comme ci-dessous :
<%= screenshot "s3-4", "Trouver un hash de commit." %>
Testons avec un hash au lieu d'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
~~~
Et finalement, si nous voulons arrêter de regarder dans notre boule de cristal et que nous voulons revenir dans le présent ? Nous demandons à Git de consulter la branche **master** :
~~~bash
git checkout master
~~~
Notez que vous pouvez lancer l'application avec la commande `meteor` à tout moment, même lorsque vous êtes dans l'état "detached HEAD". Vous aurez peut-être besoin de lancer d'abord `meteor update` si Meteor se plaint de paquets manquant, puisque le code des packages n'est pas inclus dans le repo Git de Microscope.
### Perspective historique
Voici un autre scénario commun : vous regardez un fichier et remarquez des changements que vous n'aviez pas vu avant. Le fait est, que vous ne vous souvenez plus **quand** le fichier a été changé. Vous pourriez juste regarder les commits un par un jusqu'à que vous trouviez le bon, mais il y a un moyen plus facile grâce à la fonctionnalité d'**historique** de GitHub.
Premièrement, accédez à l'un des fichiers de votre dépôt sur GitHub, puis localisez le bouton "History" :
<%= screenshot "s3-8", "Bouton History de GitHub." %>
Vous avez maintenant une liste claire de tous les commits qui ont affectés ce fichier en particulier :
<%= screenshot "s3-9", "Afficher l'historique d'un fichier." %>
### Le jeu du blâme
Pour développer, regardons **Blame** de plus près :
<%= screenshot "s3-10", "Bouton Blame de GitHub." %>
Cette vue claire nous montre ligne par ligne qui a modifié le fichier, et dans quel commit (en d'autres termes, qui est à blâmer quand les choses ne fonctionnent plus) :
<%= screenshot "s3-11", "Vue Blame de GitHub." %>
Git est un outil assez complexe - et GitHub aussi -, donc nous ne pouvons pas espérer couvrir tout dans un seul chapitre. En fait, nous avons à peine effleuré la surface de ce qui est possible avec ces outils. Mais heureusement, même ce petit échantillon prouvera son utilité au fur et à mesure du livre.