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.

Families of Revision Control Tools

The principal revision control tools can be divided into two families or generations. First generation tools, which include CVS and SVN, use a single central repository. All of the modifications are under the control of and retrieved from this authoritative repository. Second generation tools such as Git, Mercurial and Bazaar, use local repositories. The advantage of such a system is that development work can be done independent of any remote server. The commit and checkout operations can thus be much faster and perform more complex operations. As an example, Git and Mercurial offer advanced management of branched development. In a branched development model, each new feature corresponds to a branch of the development tree. The production version of the project then corresponds to the principal branch and additional features are developed in parallel until they are sufficiently mature to be fused with the principal branch or else abandoned and the branch left to die. This development model is particularly well-adapted to very large projects involving several programmers.

In exchange for this flexibility, with second generation tools all modifications that need to go to an external repository must do so in two steps: first, they are submitted to the local repository (commit), then they are pushed (push) to the external repository. Equally so, to retrieve the modifications from an external repository, you must first obtain them (pull or get) so they can be imported into the local repository, then update your working version (update or checkout).

Choosing a Tool

If you want to contribute to an existing project, you don't really have any choice - you will have to use the tool that has been chosen by the initial development team. If you are starting your own project, the choice will depend on the breadth of your project. If it's a project with only a few contributors, which will remain private and for which you would simply like to have a history of all the modifications, a first generation tool like SVN can be sufficient. If your project is larger, with external collaborators, you should consider a second generation tool like Git or Mercurial.

This page is derived from [1].