Une introduction à Git et à Github

Depuis plusieurs années, Git s’est imposé comme le gestionnaire de versions de référence. Il est utilisé par de nombreux projets Open Source (hébergés par Github) et hormis quelques résistants (comme Facebook, qui utilise Mercurial), la plupart des sociétés l’ont désormais adoptés en remplacement des ancêtres CVS et SVN.

Il nous semblait intéressant de revenir sur les bases de Git pour les non-initiés, qui voudraient bien comprendre ce qui se cache derrière les termes mystérieux de “commit”, “push”, …

Nous avons donc proposé un “15 minutes pour comprendre” à la Tech Amiénoise.

L’histoire de Git en version (très) courte

L’équipe de développement du noyau Linux travaillait avec le gestionnaire de versions Bitkeeper. Mais elle fut confronté à divers problèmes avec cet outil. Le code n’étant pas open source, ils n’étaient pas en mesure de corriger eux-même les problèmes.

La solution de Linus Torvalds à ce problème ? Développer son propre outil open source pour remplacer Bitkeeper.

Git était né.

C’est quoi un gestionnaire de version ?

Imaginons que vous disposiez d’une recette de boeuf bourguignon. Au fur et à mesure de vos essais, vous la modifiez pour y mettre un peu plus de ceci ou un peu moins de cela.

Mais toutes ces modifications ne sont pas forcément une réussite.

  • Peut-être voulez-vous revenir à la recette précédente ?
  • Ou encore à celle que vous aviez utilisé lors du dernier repas de famille ?

C’est ça que propose un gestionnaire de version. Vous pouvez stocker certaines “versions” de votre recette pour y revenir plus tard.

A la différence, d’un Google Docs qui tracent toutes vos modifications, ici c’est vous qui décidez quand une version présente un intérêt. Cet enregistrement d’une version s’appelle un “commit”.

Anatomie d’un commit

Un commit se compose de trois parties :

  • Identifiant : Un identifiant unique généré à partir de l’algorithme SHA-1
  • Message : Un texte décrivant la modification ou ses raisons.
  • Contenu : Les modifications apportées (ajouts, suppressions, …)

Encore un nouveau concept : le repository

Lorsque l’on “commit”, la modification est stockée dans un “repository”.

L’originalité de Git vient dans l’emplacement de ce repository.

Pour CVS et SVN, le repository était sur un serveur distant. Ce qui revenait à confondre deux notions :

  • Mon travail est bien avancé, il est intéressant que je trace cette avancée.
  • Mon travail peut-être partagé avec mes collègues.

Git va tout d’abord stocker vos commits dans repository “local”, qui se trouve donc sur votre machine. Ce “repo” local est une copie d’un autre repository, distant celui-ci, se trouvant sur un serveur (ex. Github).

Synchroniser les repositories

En effet, après avoir fait nos commits en local, on voudra les partager avec nos collègues et donc les envoyés sur le serveur distant.

Pour cela, on parle de l’action “push” qui envoie le contenu de notre repository sur le serveur.

S’il existe une commande pour donner ses modifications, il en existe aussi une pour récupérer les modifications de nos collègues. Ici, on fera appel à “pull”.

Introduction à Github

Github permet de stocker gratuitement vos projets, tant que ceux-ci restent publiques.

Github s’est donc imposé comme LA plateforme pour les projets Open Source.

Si ces projets sont open source, c’est que l’on peut tous y participer. Mais pour cela, il convient de comprendre le fonctionnement de Github.

Cloner un projet

Cette commande permet de récupérer en local n’importe quel projet de Github.

Attention ! Vous ne serez pas autorisés à effectuer des “push” sur un repository ne vous appartenant pas. Si vous souhaitez partager vos modifications avec la communauté, il faut utiliser une autre méthode.

Forker un projet

Cette commande va créer votre propre copie du projet sur Github.

Ce nouveau repository est à vous, vous pouvez donc y pousser toutes les modifications que vous voulez.

Mais comment prévenir le projet d’origine que vous avez des modifications à lui donner ?

Proposer une pull-request

Lors d’une pull-request, vous allez indiquer à un projet qu’il peut se synchroniser avec votre repository pour récupérer des modifications.

Si le responsable du repository accepte, votre pull-request sera intégrée au projet et vous serez devenu un contributeur du projet.

Cette présentation visait un public de non-initiés et se voulait une introduction simple et rapide. Si vous êtes un utilisateur régulier de Git, il est probable que vous ayez trouver cela “trop facile”.

C’est pour cela, que nous ferons par la suite une présentation plus longue sur des aspects avancés de Git.

Les slides

En savoir plus

Comment rédiger un rapport de bug ?

Pour chaque projet que nous développons, nous traitons des bugs remontés par le client. Problème, ils ne sont pas tout le temps facile à identifier. L'objectif d'un rapport de bug est de faciliter la compréhension du problème pour le faire corriger au plus vite par...

Signature d’application Android, éviter les erreurs !

Dans le monde du développement et de la signature d'application, il y a deux types de personnes. Ceux qui ne commettent jamais d'erreur et ceux qui doivent s'appuyer sur des outils pour limiter, compenser ou corriger leurs erreurs.Personnellement, je me range plutôt...