Gestion de code source

Introduction

La gestion de code source est l'une des pierres angulaires du développement d'applications. Lorsque vient le temps de gérer le code source d'un projet sur lequel vous travaillez, deux façons s'offre à vous. Vous pouvez faire des copies de sauvegarde multiples, envoyer le code source à vos collègues par courriel, et vous creuser la tête afin de savoir qui possède ou utilise quelle version du code et comment réconcilier les modifications apportées par chaque collaborateur. Vous pouvez au contraire adopter une approche beaucoup plus saine en utilisant des outils de contrôle des révisions développés dans le but de faciliter ce processus.

Toutes les applications et bibliothèques d'envergure sont développées en utilisant de tels outils. En recherche, ces outils sont encore davantage importants, car la traçabilité est essentielle afin de pouvoir reproduire des résultats donnés. Les outils de gestion de contrôle des révisions sont en quelque sorte le cahier de laboratoire d'un expérimentateur.

Avantages

Les outils de contrôle des révisions vous offrent un grand nombre d'avantages qui surpassent largement leurs inconvénients. Tout d'abord, ils vous permettent de collaborer plus facilement. En effet, ils éliminent le risque qu'un collaborateur écrase vos modifications ou vice-versa sans laisser de traces. Ces outils enregistrent en effet l'historique de toutes les modifications apportées au projet. Ils agissent aussi un peu comme une machine à remonter le temps, en vous permettant de réinitialiser votre projet à une version antérieure, afin de reproduire vos résultats par exemple. Ils permettent aussi de documenter facilement ces modifications, facilitant ainsi la notification des changements à tous les utilisateurs du projet.

Fonctionnement de base

Les gestionnaires de code source fonctionnent sur un principe de séparation entre les modifications locales faites par un utilisateur, dans son répertoire local, et ce que l'on nomme un dépôt ou référentiel. Un dépôt contient, de façon structurée, l'historique de toutes les modifications apportées par tous les contributeurs d'un projet. Le développement d'un projet en utilisant un gestionnaire de code source se voit ainsi modifié par rapport au développement local. Plutôt que simplement enregistrer ses modifications sur le disque dur local, un contributeur doit soumettre (commit) les modifications vers le dépôt afin de les rendre accessibles aux autres développeurs. À l'inverse, les développeurs doivent s'assurer de disposer de la version la plus récente d'un fichier en allant le chercher dans le dépôt (checkout, update) avant d'y apporter ses propres modifications. Si deux développeurs modifient un fichier source en même temps, l'outil de gestion pourra soit afficher un conflit lors de la soumission des deux modifications concurrentes, ou encore résoudre ce conflit automatiquement si possible.

Familles d'outils de contrôle des révisions

Les principaux outils de contrôle des révisions peuvent se répartir en deux familles ou générations. Les outils de première génération, dont font partie CVS et SVN, utilisent un dépôt central unique. Toutes les modifications sont ainsi soumises et récupérées à partir de ce dépôt autoritaire. Les outils de deuxième génération, dont font partie Git, Mercurial et Bazaar, utilisent des dépôts locaux. L'avantage de ces derniers est que le développement peut se faire de façon indépendante de tout serveur distance. Les commit et checkout peuvent ainsi être beaucoup plus rapides et faire des opérations plus complexes. Ainsi, Git et Mercurial offrent une gestion avancée du développement en branches. Dans un modèle de développement en branches, chaque nouvelle fonctionnalité devrait correspondre à une branche de l'arbre de développement. La version production du projet correspond à la branche principale, et les fonctionnalités sont développées en parallèle jusqu'à ce qu'elles soient suffisamment matures pour être fusionnées à la branche principale, ou abandonnées et que leur branche meurt. Ce modèle de développement est particulièrement adapté aux gros projets impliquant plusieurs développeurs.

La contrepartie des outils de deuxième génération est que les modifications qui doivent être poussées vers un dépôt externe doivent l'être en deux étapes : tout d'abord, elles sont soumises dans le dépôt local (commit), puis elles sont poussées (push) vers le dépôt externe ou un autre dépôt. À l'inverse, pour récupérer des modifications d'un dépôt externe, il faut d'abord aller les chercher (pull ou get) pour les importer dans son dépôt local, puis mettre à jour sa version de travail (update ou checkout).

Choix d'un outil

Si vous désirez contribuer à un projet existant, vous n'aurez pas vraiment le choix. Vous devrez utiliser l'outil qui a été choisi par les développeurs initiaux. Si vous démarrez votre propre projet, le choix dépendra de l'envergure que vous envisagez pour votre projet. S'il s'agit d'un projet où il n'y aura que quelques contributeurs, qui demeurera privé, et que vous voulez simplement garder un historique des modifications, un outil de première génération comme SVN peuvent être suffisants. S'il s'agit d'un projet de plus grande envergure, avec des collaborateurs extérieur, vous voudrez probablement envisager les outils de deuxième génération comme Git ou Mercurial.

Cette page est dérivée de [1].