Un système de contrôle de versions est simplement une façon de suivre les modifications effectuées dans un fichier au fil du temps. Je parie que vous utilisez déjà un système de contrôle de versions sans même le savoir!

Lorsque vous faites une copie d’un script avant de le modifier et que vous le renommez v2 par exemple, vous utilisez un système de contrôle de versions. Quoique fonctionnel, votre système manuel peut bien vite s’avérer pénible à gérer. C’est pourquoi ça vaut la peine d’investir un peu de temps tôt dans un projet pour utiliser un sytème un peu plus structuré.

Comme l’a bien résumé un utilisateur de stackoverflow (un lien vers ce texte existe même sur la page de RStudio), un système de contrôle de versions nous facilite la vie dans plusieurs situations, en particulier s’il vous est déjà arrivé de :

  • Modifier du code, réaliser que ce n’était pas une bonne idée et vouloir revenir à une ancienne version
  • Perdre du code sans avoir de copie de secours
  • Vouloir voir la différence entre deux (ou plusieurs) versions de votre code
  • Vouloir prouver que telle modification a brisé ou réparé un bout de code
  • Vouloir réviser l’historique des modifications apportées à votre code
  • Vouloir partager votre code ou permettre à d’autres de travailler sur votre code

Si vous vous êtes dans l’une de ces situations, vous serez heureux d’apprendre que l’on retrouve deux systèmes (ouverts ou open-source) de contrôle de version dans RStudio :

Je ne révèlerai pas lequel je préfère! Je vais m’attarder sur Git plutôt que sur SVN parce qu’il a été le premier système supporté dans RStudio et qu’il est la seule option offerte lorsque l’on crée un nouveau projet dans la version 0.98.

Les fonctionnalités de contrôle de versions dans RStudio ne sont disponibles qu’à l’intérieur d’un projet. La première étape est donc, bien évidemment, de créer un projet RStudio. Une fois le projet créé, les fonctionnalités sont disponibles dans le panneau du haut à droite. Dans ce panneau, vous verrez les différents fichiers de votre projet et vous serez capable de sélectionner les fichiers à suivre (pour un nouveau projet) ou de voir les fichiers déjà suivis (dans un project existant).

Pour la soumission (« commit ») initiale (pour un nouveau projet), on doit sélectionner les fichiers à suivre. Ces derniers se verront attribuer un petit A vert (« added ») à côté de leur nom. Avant de compléter la soumission, Git nous demande d’écrire une description des modifications à soumettre. L’idée est d’écrire le message le plus informatif possible pour nous permettre (et à nos collaborateurs si l’on décide de partager notre projet) de bien suivre les modifications effectuées.

Git nous indiquera ensuite ce qu’il a fait et si tout s’est bien passé. Si quelque chose est allé de travers, nous le saurons!

Première soumission réussie.

Par la suite, un petit M bleu (« modified ») apparaitra à côté du nom d’un fichier suivi par Git chaque fois que l’on sauvegardera une modification dans ce fichier. Lors de la soumission, il est possible de voir la différence entre notre fichier et la version précédente. Une fois la soumission complétée, le petit M disparait.

Avant la soumission, une description des modifications effectuées est demandée

Et voilà! Un usage de base n’est pas plus compliqué que ça! Des modifications, un message, une soumission et le tour est joué!