Git, de zéro à un peu plus loin en quelques paragraphes

L’utilisation d’un logiciel responsable de versionner votre code source est à la base de la pyramide des besoins d’un développeur. Si vous n’en avez pas, vous êtes en danger. Il faut agir rapidement, car votre code source pourrait se trouver en péril.

Une fois que vous en avez un, vous avez tendance à le tenir pour acquis et être confortable avec le fonctionnement de celui-ci. Si vous êtes comme moi, il y a de bonnes chances que vous ayez grandi avec l’utilisation d’un gestionnaire de code source centralisé comme Subversion.

Dernièrement, j’ai entrepris le projet de présenter Git à certaines personnes n’ayant aucune expérience à ce sujet. Sachant que le fonctionnement de Git est sensiblement différent de Subversion, il  s’agit de quelque chose qui n’est pas à prendre à la légère. Cependant, une fois les concepts de base bien assimilés, la transition se fait comme un couteau chaud dans du beurre mou.

Il suffit de bien s’y prendre.

Distribué

Git est un gestionnaire de version décentralisé (decentralized version control system (DVCS) pour les anglophiles). Dans le contexte de Git, ceci veut dire que chacun des développeurs ayant accès au repository détient la totalité de l’historique de développement sur son poste de développement.

Le principal avantage de ceci est que vous travaillerez avant tout localement sur votre propre base de données de changements avant de publier ceux-ci sur un serveur distant.

La contrepartie est que vous allez être dorénavant maîtres du maintien de l’historique de développement vis-à-vis vos pairs ainsi que le serveur commun sur lequel vous allez y déposer vos changements.

Qu’est-ce qu’un commit

Il faut savoir que, pour git, un commit est un lot de changements que nous soumettons à l’historique de développements. Chaque commit est associé à un identifiant unique et contient un certain nombre de documents modifiés.

Un commit agit comme une prise instantanée représentant votre dossier de travail au moment d’être fait. Pour chacun des commits, Git va y enregistrer le contenu des fichiers identifiés par un checksum. Le checksum sera l’identifiant unique représentant votre commit dans l’historique de développement.

Les fichiers seront ensuite enregistrés dans la base de données locale en texte brut. Puisque les changements sont enregistrés en brut, les changements au contenu des fichiers sont identifiés en comparant le contenu de ceux-ci entre chacune des révisions. L’avantage de ceci est que c’est excessivement rapide puisque tout est fait localement.

Entre deux commits, un fichier qui n’est pas mis à jour ne sera pas ajouté à l’index. Cela veut dire qu’un fichier qui ne bouge pas ne sera téléchargé qu’une seule fois. C’est avec ce concept qu’une économie de temps et d’espace s’opère.

Distant et local

Le secret derrière la rapidité de Git est que la majorité de ses opérations se font localement. Puisque vous avez l’entièreté du dépôt sur votre ordinateur, créer une branche ou soumettre une nouvelle version de votre code revient à une simple opération d’écriture sur votre disque dur.

Cet avantage apporte, cependant, une complexité à votre gestion des sources. Vous aurez à faire la gestion des serveurs distants et établir, avec vos camarades développeurs, qui est la source de référence pour votre code.

Basé sur la théorie des graphes

Qu’est-ce que la théorie des graphes? Il s’agit de la théorie permettant de résoudre certaines problématiques associées à la liaison entre un ou plusieurs points. Dans le contexte de Git, il s’agit que l’historique des révisions de votre développement soit toujours traçable à partir du commit d’origine.

Branches

Le concept de branches est le même que vous l’avez peut-être vécu avec Subversion. Il s’agit de prendre votre code source à un état donné et d’y appliquer des changements parallèlement.

Dans presque tous les guides, vous allez voir des graphiques de ce genre. Ils permettent de visualiser l’évolution des changements dans un repository Git. Un phénomène intéressant. Les flèches signifient « provient de » dans le sens que le commit a son origine à partir de celui où la flèche pointe.

Les éléments suivants sont présents dans ce graphique :

• A : le commit initial du repository
• H : le plus récent commit de sa branche
• B : le commit liant la branche du commit H et du commit E
• E : le plus récent commit de la branche E
• C : le commit liant la branche du commit K et du commit E
• K : le plus récent commit de sa branche

Scénario d’utilisation typique

Assumant que des modifications été faites aux fichiers du répertoire local et que vous partez de la branche master.

1. Les fichiers modifiés seront ajoutés au prochain commit. (git add)
2. Vous procéderez à un commit des changements à votre historique local. (git commit)
3. répéter, si nécessaire
4. Il vous faut récupérer une mise à jour de l’historique de développement sur un serveur distant (remote) (git fetch)
5. Il se peut qu’il y ait eu des changements depuis votre dernier fetch, votre branche copie de la branche master sera détachée. Vous aurez à la réintégrer à l’aide d’un pull.
6. Une fois les changements intégrés à Master, vous pourrez soumettre vos changements au serveur distant. (git push).

Certaines définitions de commandes à apprendre

• clone : met en place une copie d’un repository sur votre ordinateur
• init : initialise un repository vierge
• add : ajoute des fichiers au commit
• commit : permet l’ajout de commit à la branche courante
• status : donne le statut du repository courant
• fetch : télécharge les changements d’une branche située sur une serveur distant
• push : soumet les changements d’une branche locale à serveur distant
• merge : fusionne l’historique de développement de deux branches.
• pull : télécharge une branche distante et la fusionne avec sa branche locale
• branch : permet la gestion des branches
• origin : le repository distant vers lequel origine le clone initial
• head : le plus récent commit de la branche courante

Logiciels à utiliser

• SourceTree : il est raisonnablement bien conçu et fonctionne autant sur Mac et PC.
• Tortoisegit : agis comme un plan B si votre logiciel principal abandonne en plein combat. Vous permet d’avoir la coloration des fichiers dans l’explorateur Windows.
• Visual Studio Tools for Git  : pour les développeurs .NET, comme moi.

Si jamais vous êtes vraiment motivé, vous pouvez utiliser git, en ligne de commande, directement au métal. Tout est une question de préférence.

Sources intéressantes

• Le livre Progit, dans sa traduction française : https://github.com/progit/progit/blob/master/fr/
• Une introduction à Git Scott Chacon de Github (attention, il parle vite) : https://www.youtube.com/watch?v=ZDR433b0HJY
• Git cheat sheet : http://rogerdudler.github.io/git-guide/files/git_cheat_sheet.pdf
• Une introduction plus avancée à certains concepts avancés des branches dans Git : http://think-like-a-git.net
• Des idées de modèle de développement pour Git. http://nvie.com/posts/a-successful-git-branching-model/
• Atlassian a son mot à dire sur les modèles de développement. https://www.atlassian.com/git/workflows
• Les ressources Git d’Atlassian. https://www.atlassian.com/git/resources