Utiliser Git & GitHub

Aparté 3.5

Traduction complétée à

Au programme de ce chapitre :

  • Découvrir comment utiliser GitHub pour suivre avec le livre.
  • GitHub est un dépôt social pour les projets open-source basé sur le système de contrôle de version Git, 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 ressemble :

    Un commit Git vu sur GitHub.
    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 :

    Modifier du code.
    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 :

    Supprimer du code.
    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 :

    Le bouton Browse code.
    Le bouton Browse code.

    Vous allez maintenant avoir accès au dépôt tel qu'il est à ce moment spécifique du commit

    Le dépôt au commit 3-2.
    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 :

    Le dépôt au commit 14-2.
    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é. Ensuite clone (en d'autres termes, télécharger une copie localement) le dépôt de Microscope avec :

    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 :

    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 :

    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 :

    Trouver un hash de commit.
    Trouver un hash de commit.

    Testons avec un hash au lieu d'un tag :

    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 :

    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" :

    Bouton History de GitHub.
    Bouton History de GitHub.

    Vous avez maintenant une liste claire de tous les commits qui ont affectés ce fichier en particulier :

    Afficher l'historique d'un fichier.
    Afficher l'historique d'un fichier.

    Le jeu du blâme

    Pour développer, regardons Blame de plus près :

    Bouton Blame de GitHub.
    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) :

    Vue Blame de GitHub.
    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.