Developpef: Des outils pour repenser la gestion du code…

J’ai récemment commencé à m’intéresser à Git ainsi qu’aux quelques outils courants qui lui sont liés (Gerrit, EGit...). Au vu du peu de documentation à leur sujet disponible sur le net (quasi nulle en français), j’ai décidé de me lancer dans une série d’articles pour les présenter et expliquer leur fonctionnement. Au travers de ces articles, je vais donc peaufiner mes propres connaissances en essayant de partager ce que j’ai appris et de les compléter au fur et à mesure de mes progrès. Toute information supplémentaire et/ou complétude seront les bienvenues.

Grands principes de Git

Une gestion décentralisée

Qu’est-ce que Git ? Initialement développé par Linus Torvald (le père de Linux) en 2005 puis adopté par la communauté Eclipse en 2009, c’est un outil de gestion de configuration (version) décentralisée (ou DVCS – Distributed Version Control System). Concrètement, à l’inverse de CVS ou SVN dont le fonctionnement est basé sur un serveur central gérant le référentiel (repository) et manipulé par plusieurs clients, Git crée une copie complète du référentiel sur chaque client. Ainsi, toutes les opérations habituelles (Add, Commit, Merge...) sont effectuées en local. Seul le partage final est publié.

Seules donc les opérations "pull"/"fetch" et "push" permettront au référentiel local d’interagir avec l’extérieur, respectivement pour se synchroniser ou publier les changements.

Une surveillance des états plutôt que des changements

Les outils tels CVS ou SVN sont basés sur la gestion des changements dans les ressources : chaque modification entraine une nouvelle version du contenu. Une version porte donc l’information du changement.

Git propose plutôt de gérer les états des fichiers à des instants précis : avant chaque commit, Git crée une image du système fichier de façon à maintenir son historique. Les fichiers sont représentés par leur SHA-1 (algorithme de hashage unique pour chaque contenu).

Ainsi, le système est beaucoup plus rapide et léger puisque cet index des fichiers est simplement constitué d’ "identifiants" SHA-1 pointant sur des versions de fichiers précises. L’index représente donc une couche intermédiaire entre l’espace de travail (workspace) et le référentiel local. Voici une autre illustration décrivant un workflow classique :

Chaque nouvelle itération de fichier porte l’information du SHA-1 de l’état précédent. Voici un extrait de ce que l’on peut trouver dans un diff simple :

previous: 48b2179994d494485b79504e8b5a6b23ce24a026
--- a/README.txt
+++ b/README.txt
@@ -1 +1 @@
-SVN  is great
+Git  is great
previous: 6ff60e964245816221414736d7e5fe6972246ead
--- a/README.txt
+++ b/README.txt
@@ -1 +1 @@
-Git  is great
+SVN  is great

Ceci mène donc à une utilisation simplifiée du concept de branches : la création d’une branche consiste juste à pointer sur un index différent du fichier (un SHA-1 différent). Chaque branche elle-même est identifiée par le SHA-1 de son contenu. La navigation dans l’arbre du référentiel devient alors beaucoup plus rapide et simple à gérer pour le système.

La branche par défaut du référentiel est appelée "master" (l’équivalent du "trunk" SVN). La révision la plus récente (dernier SHA-1 connu) s’appelle "HEAD".

Bénéfices de la gestion décentralisée

Pas de dépendance envers un serveur central

Les développeurs peuvent collaborer sans avoir à transiter par une autorité centrale, ce qui simplifie les échanges et diminue les coûts d’administration.

Un système déconnecté

Toutes les opérations classiques de gestion du code source sont effectuées en local, sans avoir à se soucier de la disponibilité du serveur de partage. Un développeur peut donc effectuer des ajouts, commits, merges sur son propre référentiel et être productif même s’il est déconnecté du réseau.

Une utilisation des versions et branches simplifiée

Par l’utilisation de l’index des fichiers (le catalogue des SHA-1), il est simple de créer ou supprimer des branches dans le système, en réduisant les risques d’erreur et d’impact sur leur contenu même.

Des workflow personnalisés

Par l’indépendance créée entre les développeurs, il devient alors possible à chacun de mettre en place son propre flux de travail pour ses besoins :

Promouvoir une utilisation communautaire

Puisque le référentiel est copié sur chaque poste client, il n’y a rien à craindre à permettre à quiconque de se joindre aux développements et participer au renforcement de l’équipe.

Comme vous le voyez, Git propose donc une vision radicalement différente des outils de gestion de version classiques. Je vous laisse le soin de parcourir plus en détails la documentation.

Mon prochain article présentera Gerrit, un outil de revue de code lié à Git.

Sources

Fichier(s) joint(s) :

3 commentaires:

Mickael BARON a dit…: Merci beaucoup pour cet intéressant billet. Il va falloir que j'y pense à m'y mettre.; 23 juin 2011 à 10:00
Anonyme a dit…: Un outil complètement null, je préfère de loin svn. Pas du tout confortable pour la gestion des conflits, surtout s'agissant d'un projet avec une grande équipe. Une résolution de conflit me prends des fois 45 min, entre commit, add, push ... alors que le même traitement avec svn ne dépasse pas les 5 min ..; 4 novembre 2011 à 12:28
Paul-Emmanuel Faidherbe a dit…: Un exemple peut-être de ce type de conflit?
Car généralement SVN va obliger à modifier/écraser une des deux versions pour le résoudre AVANT de commiter, alors que GIT possède notamment un outil de merge interactif qui permet de passer en revue chaque conflit, de le résoudre et de créer UN COMMIT PAR RESOLUTION, même au sein d'un unique fichier. Qui plus est, le conflit n'empêchera pas le commit mais créera deux parents pour le fichier en question, d'où le graph non linéaire (directed acyclic graph - DAG). Il existe même d'autres outils comme le "rebase" qui résolvent pas mal de cas particuliers.
Mais comme le disent les utilisateurs de git, et votre citation en est l'exemple, il ne faut pas essayer de faire "comme avec svn", mais il faut totalement revoir sa façon de gérer le code...; 4 novembre 2011 à 15:51