Concepts Généraux

Définition

Git a été créé par Linus Torvald début 2005 sous la licence GNU GPL version 2 et la première version stable est sortie en Décembre 2005, soit moins d'un an après le début du développement.

Une intention particulière a été plaçée sur l'optimisation de son fonctionnement sur un noyau Linux.

A bien des égards, Git peut être considéré comme un système de fichiers à part entière, possédant son propre système de versionnement. Avec le temps et la participation active de la communauté, Git se trouve doté de toutes les fonctionnalités d'un logiciel de gestion de versions.

Notion de Snapshots

On peut affirmer que Git est au développement logiciel ce que sont les sauvegardes/save points au jeu vidéo. En effet, dans une situation vidéo-ludique, les sauvegardes nous permettent de ne pas avoir peur du futur, et d'avoir la possibilité de revenir en arrière à un point précis, et ce, n'importe quand.

Dans le cadre d'un développement logiciel, Git fonctionne de la même façon. En effet, il intègre la notion de Snapshot

Un Snapshot ou Commit représente l'état au complet d'un projet à un instant t. Au cours du déroulement normal d'un projet, les fichiers sont, bien sûr, amenés à être modifiés, ajoutés ou supprimés, le projet a donc une vie. Les snapshot permettent donc de figer l'état d'un dossier à un moment précis dans le temps afin de pouvoir effectuer différentes opérations dessus. En effet on pourrait vouloir comparer les fichiers à deux moments différents dans le temps, ou bien même vouloir revenir en arrière. C'est à cela que servent les commits.

Sur le schéma ci-dessus, représentant le même projet Git à deux moments différents (C1 et C2, pour Commit 1 et Commit 2), le fichier GoodBye.txt a été modifié, ce qui a entraîné la création d'un autre point d'ancrage, d'un autre snapshot dans notre projet. Ce sont bien deux états différents à deux instants différents.

La compréhension de la notion de Snapshot est primordiale pour assimiler le fonctionnement de Git, c'est le squelette du système.

Le DAG

Le DAG représente l'historique complet d'un projet versionné par Git, chaque noeud représentant un commit donc un snapshot du projet.

Ce graphe représente les liens de parentés entre les différents noeuds et donne des informations sur le déroulement du projet. Les liens entre les noeuds sont unidirectionnels et ne forment pas de boucles.

Note :

A partir du moment où l'axe du temps est clair, le sens des flèches n'a pas d'importance. C'est à dire que l'on pointe le parent, ou le fils ne change rien tant que l'on sait dans quel sens avance le projet.

Il est important de souligner, que contrairement à d'autres systèmes de versionnement, Git ne stocke pas les différences entre les fichiers, mais bel et bien l'intégralité de celui-ci.

Comme dit précedemment, chaque noeud étant un commit ou snapshot, et représentant l'état au complet du projet à un instant donné, il est très facile de revenir en arrière ou de récupérer des vieilles versions de certains fichiers.

Le schéma ci-dessus nous montre qu'il existe deux types de liens de parenté. En effet :

• A partir d'un noeud, nous avons la création de deux fils sur des branches distinctes. On a donc une création de branche ( cf C1)
• A partir de deux noeuds sur des branches séparées, on n'en retrouve ensuite qu'un seul. C'est donc la fusion de deux branches, action de merge, qui produit un commit en tant que résultat( cf C6)

Ces deux procédés représentent l'essence même de Git et du Git branching.

Git Branching

Le Git Branching symbolise avant tout la bonne conduite à appliquer pour tirer profit de la puissance de Git. C'est comme cela que Git a été pensé et créé.

Les branches décrivent un développement en parallèle de votre projet, une dérivation qui va résulter à l'ajout de nouvelles fonctionnalités. La branche principale et par défaut d'un projet, est la branche appelée master.

La bonne façon de procéder, comme schématisé ci-dessous, est d'effectuer les releases sur la branche principale/master, et de développer des fonctionnalités sur une branche à part, que l'on peut nommer Develop

pour l'exemple.

Outil de versionnement distribué

Le vrai intérêt de Git réside dans son fonctionnement entièrement distribué et décentralisé. En effet, l'utilisation d'un serveur canonique de connaissance comme utilisé par SVN en l'occurence n'est pas obligatoire. Pourquoi ? Car le dossier Git contient à lui seul tout l'historique du projet, et peut donc être transféré à un collègue qui bénéficiera alors de tout votre travail et de toute l'histoire du projet.

A noter que l'utilisation d'un serveur est néanmoins souvent pronée dans un soucis de centralisation des données, mais cela est juste pour un côté pratique, en rien obligatoire.

Ainsi on obtient un réseau de collaborateurs qui échangent entre eux des versions différentes du projet, et qui mettent à jour leur travail sur un serveur distant appelé par convention origin.
Ces utilisateurs n'ont pas forcemment tous au même moment, les même versions sur leur disque, ils peuvent récupérer du serveur ou de leurs autre collègues uniquement les parties / branches qui les intéressent, et travailler uniquement sur ces parties.