Publié le 22 novembre 2018

GIT COMMENT ÇA MARCHE ? TUTO POUR DÉBUTANT

Pour comprendre GIT, il est nécessaire de connaitre les éléments de base. Cette documentation n’est pas exhaustive et recommande des bonnes pratiques surtout adaptées aux débutants. Les informations présentes dans ce document s’étendent parfois au-delà de l’outil GIT pour donner des contextes d’utilisation.
Pré-requis : l’utilisation d’un terminal (aussi appelé « console » ou « shell ») est nécessaire à l’exécution des commandes listées dans ce document.

QUELLES SONT LES DÉFINITIONS À CONNAITRE SUR GIT ?

Il existe des termes de base à connaitre pour utiliser GIT correctement. En voici une liste :

  • COMMIT

    Contribution dans un projet GIT. Regroupement d’une ou plusieurs modifications, identifié par une série unique de caractères alphanumériques (SHA). Ce commit représentera une « version » du projet.

  • BRANCH

    Par commodité, c’est le nom donné à une série de commits. C’est aussi et surtout une référence pour positionner le projet sur le dernier commit d’une série. La branche GIT par défaut s’appelle « master » et devrait correspondre à l’état de la production.

  • MASTER

    C’est le nom donné à la branche par défaut par GIT. Elle fait généralement office de référence pour l’ensemble des contributeurs, et peut donc aussi correspondre à l’état du projet en production.

  • REPOSITORY (OU « DÉPÔT »)

    C’est le nom d’un projet GIT. Il peut être local (sur son poste), ou distant (sur un serveur) et référencé par une remote.

  • REMOTE

    Référence à un projet GIT distant. Ce projet distant doit être hébergé sur un serveur accessible par l’ensemble des contributeurs. La remote par défaut est appelée « origin ».

  • INDEX (HEAD)

    C’est le nom donné à l’état courant du projet et qui constituera le prochain commit. On parle « d’ajouter des fichiers dans l’index » lorsqu’on souhaite créer un commit avec ceux-ci.

  • MERGE/PULL REQUEST

    Ce n’est pas une opération propre à GIT à proprement parler, mais cette opération enrichit fortement l’aspect collaboratif de l’outil. Il s’agit de la procédure par laquelle une nouvelle branche sera soumise à vérification et acceptation de la part de l’équipe, et donc mergée dans le tron commun du projet. Elle cible la branche master, ou toute autre branche commune à l’ensemble des contributeurs. Le terme « Merge » est utilisé par l’outil interne Gitlab, alors que le terme « Pull » vient des collaborations publiques sur Github (équivalent public de Gitlab).

LES SCHÉMAS DES OPÉRATIONS GIT

Ces schémas sont des représentations des opérations menées avec GIT. Ils servent d’illustration aux commandes et principes expliqués dans le reste de ce document. Il convient donc de s’y référer chaque fois que nécessaire, pour faciliter la compréhension des textes.
À noter qu’un historique GIT se lit de bas en haut.

Les commits A, B et C font partie d’une seule et même branche. L’état HEAD contient les modifications en cours. Si on réalise un commit sur la base de ces modifications, cela deviendra un commit supplémentaire, le dernier de la branche courante.

Les 3 commits de la branche A ont été mergés dans la branche B. Ils font désormais partie de la branche B.

QUELLES SONT LES COMMANDES ESSENTIELLES SUR GIT ?

QUELLES SONT LES COMMANDES DE BASES SUR GIT ?

Les commandes ci-dessous permettent de réaliser des opérations simples sur un projet et satisfont donc l’essentiel des besoins de versioning et de collaboration.

  • GIT STATUS

    Donne l’état du projet : quels sont les fichiers ajoutés dans l’index, ceux qui sont modifiés mais pas encore ajoutés, et ceux qui n’ont encore jamais été ajoutés dans le projet (« untracked files »). Permet également de savoir si la branche courante est en avance ou en retard par rapport à l’état connu de la branche distante (cf « GIT fetch »). Donne aussi d’autres informations en cas de situation « anormale » (conflits lors d’un merge par exemple). A utiliser autant que nécessaire !

  • GIT ADD {/path/to/file(s)}

    C’est l’ajout d’un fichier ou dossier dans l’index. En d’autres termes, il s’agit d’ajouter ce qui sera contenu dans le prochain commit.

  • GIT COMMIT

    Valide l’ensemble des modifications contenues dans l’index pour en faire un commit. Cette commande ouvre un éditeur de texte pour renseigner le commentaire du commit. Dans cet éditeur, des informations en commentaire (préfixées par un #) permettent de voir ce qui sera contenu dans le commit. Ces commentaires n’apparaîtront pas dans le message du commit.

  • GIT CHECKOUT {ref/to/commit}

    Permet de basculer d’un commit à un autre. La référence d’un commit peut être son SHA (identifiant), le nom d’une branche ou un tag (« étiquette » marquant un commit en particulier).

  • GIT FETCH {origin}

    Prend connaissance des modifications opérées sur le dépôt distant (référencé par le nom de la remote correspondante).

  • GIT MERGE {branche à merger} {branche de destination}

    Consiste à récupérer les commits d’une branche pour les ajouter sur une autre. Deux cas d’usage :

    • le merge d’une branch d’évolutions vers prod ou preprod (à faire sur Gitlab par l’intermédiaire d’une Merge Request)
    • le merge de la branche distante dans la branche courante (eg : GIT merge origin/master) permet de mettre à jour la
      branche locale (celle du poste) avec les développements réalisés par d’autres collaborateurs.
  • GIT PUSH {origin} {branche}

    Envoie les derniers commits de la branche mentionnée sur le dépôt distant.

  • GIT BRANCH {nom branche}

    Crée une nouvelle branche à partir du commit courant.

  • GIT BRANCH –d {nom branche}

    Permet de supprimer la branche spécifiée, pour peu que celle-ci ait déjà été mergée complètement dans une autre branche. GIT empêche la suppression si ça n’est pas le cas.

QUELLES SONT LES COMMANDES COMPLÉMENTAIRES SUR GIT ?

En complément des commandes ci-dessus, quelques raccourcis peuvent être utilisés sans risques :

  • GIT CHECKOUT –b {branch}

    Permet de basculer sur une nouvelle branche sans avoir à la créer au préalable. C’est la combinaison des commandes suivantes : git branch [branch] + git checkout [branch]

  • GIT PULL {origin} {branch}

    Permet de prendre connaissance des modifications distantes sur une branche et les merger sur la branche courante. C’est la combinaison des commandes suivantes : git fetch [origin] + git merge [origin/branch]. À noter qu’ici, il est implicitement prévu que la branche à merger est la branche distante correspondant à la branche courante.

  • GIT FETCH {origin} –prune

    Oublie les branches qui ont été supprimées sur le dépôt distant. Cela permet de « nettoyer » le projet GIT et d’éviter la suggestion de branches obsolètes lors de l’autocomplétion des commandes dans le terminal.Valide l’ensemble des modifications contenues dans l’index pour en faire un commit. Cette commande ouvre un éditeur de texte pour renseigner le commentaire du commit. Dans cet éditeur, des informations en commentaire (préfixées par un #) permettent de voir ce qui sera contenu dans le commit. Ces commentaires n’apparaîtront pas dans le message du commit.

Les commandes suivantes sont à connaître, mais peuvent comporter des risques. Attention à les utiliser en toute connaissance de cause :

  • GIT BRANCH –D {branch}

    La mise en majuscule de l’option « d » permet de supprimer une branche même si celle-ci n’a pas été mergée dans une autre branche (master par exemple). Cela veut dire que les commits de cette branche qui ne sont pas dans une autre branche ne seront plus référencés simplement. Attention donc, il est ainsi possible de perdre tout son travail.

  • GIT ADD .

    Plutôt que de cibler un fichier ou un dossier, cette commande cible le répertoire courant et ajoutera tous les fichiers du projets dans l’index. Attention aux fichiers de tests ou produits par le code (exports, css générés, sprites, js générés…) et qui n’étaient pas encore connu de GIT : ils seront ajoutés également à l’index.

  • GIT COMMIT –a

    Ajoute tous les fichiers modifiés et déjà connus par GIT dans l’index, pour le prochain commit. Attention aux fichiers de code qui n’ont pas été au moins une fois explicitement ajoutés par git add.

Il existe encore beaucoup d’autres commandes, mais ces dernières nécessitent une compréhension plus fine de GIT, et ne sont surtout pas nécessaires pour tenir correctement un projet GIT. Pour s’assurer de justement tenir un projet correctement, il faut se pencher sur un workflow de travail avec GIT. Et quoi qu’il arrive, il faut toujours faire attention à ce que GIT indique dans ses retours de commande ! GIT donne beaucoup d’informations sur l’état du projet et apporte son aide dans l’apprentissage de ses commandes : lisez-le 😉

QUELLE MÉTHODOLOGIE DE TRAVAIL ADOPTER SUR GIT ? (WORKFLOW)

GIT n’impose aucune méthodologie de travail. Pour assurer une certaine cohérence dans un projet, il est important de se mettre d’accord sur une méthodologie de travail commune. Il existe des workflows répandus, GIT flow est l’un d’entre eux. Voici les grands principes de travail adoptés chez JETPULP, et notamment basés sur GIT flow :

  • UNE BRANCHE PAR FEATURE

    Sur une branche, on ne développe qu’un aspect fonctionnel du site, et le plus restreint possible. Cela permet de limiter les dépendances entre fonctionnalités en cas de roll-back (retour à une version précédente du projet) ou non validation. Cela facilite également la relecture de code lors d’une merge request. La convention de nommage de la branche sera la suivante : feature/nom-feature (sans majuscules)

  • UNE BRANCHE PAR FIX

    Pour les mêmes raisons. A défaut, lors d’une recette, il faudra au minimum un fix par commit. Autrement, ce sont plus généralement des branches comportant un commit unique. La convention de nommage de la branche sera la suivante : fix/nom-bug (sans majuscules).

  • UNE BRANCHE COMMUNE DE DEV/RECETTE

    Chaque branche feature/fix est d’abord mergée sur une branche commune qui n’est pas master (dev, develop, integration/preprod…). Ce merge permet de faire une recette globale de l’ensemble des features mergées au fur et à mesure. Pour des raisons pratiques, on l’appellera « dev ».

  • MASTER, ISO, PROD

    La branche « dev » est régulièrement mergée dans master après recette/validation. Cette opération donnera lieu à une « release », i.e. une mise en production. Le merge dans master ne se fait que dans l’intention de déployer en production. Autrement, la branche master ne représentera plus la production.

  • HOTFLIX

    Occasionnellement, un correctif urgent peut être nécessaire. Dans ce cas, on crée une branche depuis master, et on la mergera directement dans master. La convention de nommage de la branche sera la suivante : hotfix/nom-bug (sans majuscules).

  • MERGE REQUEST

    Chaque branche mergée dans dev ou dans master doit faire l’objet d’une relecture par un autre collaborateur du projet.

Victor A.

La-qualité-une-responsabilité-collective
0 Commentaires
Répondre
Se joindre à la discussion ?
Vous êtes libre de contribuer !
Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *