Version control/fr: Difference between revisions

Latest revision as of 20:59, 22 November 2023

Other languages:

English
français

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'offrent à 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 plus 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 du programmeur.

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; 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.

Principe de base

Les outils de gestion 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 référentiel 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 de simplement enregistrer ses modifications sur le disque dur local, un contributeur doit soumettre (commit) les modifications vers le référentiel 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 référentiel (checkout, update) avant d'y apporter leurs 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 référentiel central unique. Toutes les modifications sont ainsi soumises et récupérées à partir du référentiel. 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 exécuter des opérations plus complexes. Aussi, 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 sont abandonnées et que leur branche meurt. Ce modèle de développement est particulièrement adapté aux gros projets comptant plusieurs développeurs.

En contrepartie, les modifications qui doivent être poussées vers un dépôt externe doivent l'être en deux étapes : elles sont d'abord 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 trouver (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 le choix d'utiliser l'outil qui a été choisi au départ par les développeurs. Si vous démarrez votre propre projet, le choix dépendra de l'envergure de votre projet. S'il s'agit d'un projet où il n'y aura que quelques contributeurs, qui demeurera privé, et pour lequel vous voulez simplement garder un historique des modifications, un outil de première génération comme SVN peut être suffisant. S'il s'agit d'un projet de plus grande envergure avec des collaborateurs externes, vous devrez probablement envisager les outils de deuxième génération comme Git ou Mercurial.

Où situer le référentiel

Un point à bien considérer est l'endroit où sera situé le référentiel. Si vous et vos collaborateurs travaillez toujours sur le même ordinateur, le référentiel peut n'être visible que sur cet ordinateur. Par contre, si vous ou vos collaborateurs utilisez plusieurs ordinateurs, un accès via l'internet serait souhaitable; le code peut ainsi être facilement synchronisé et le fait que le code soit distribué ajoute à sa sécurité. Pour des détails sur comment configurer un référentiel, vous pouvez consulter svn,git,gitlab, gitbucket. Pour connaitre certains services disponibles en ligne qui ne nécessitent pas que votre serveur soit toujours accessible, consultez bitbucket, github, gitlab, sourceforge

Référence

Cette courte vidéo traite des notions de base avec Git.

@@ Line 1: / Line 1: @@
 <languages />
 ==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.
+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'offrent à 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.
-All significant applications and libraries are developed using such tools. For academic research, these tools are even more important because traceability is essential for ensuring that a given set of results can be reproduced. A good metaphor is that revision control management tools are the programmer's equivalent to the experimentalist's lab notebook.
+Toutes les applications et bibliothèques d'envergure sont développées en utilisant de tels outils. En recherche, ces outils sont encore plus 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 du programmeur.
-== Advantages ==
+== Avantages ==
-Revision control tools offer you a great many advantages and these more than compensate for the occasional inconvenience. Firstly, they permit you to collaborate more easily. They eliminate the risk that a collaborator might delete your modifications or vice-versa without leaving a trace. These tools save the history of all the modifications made to a project and in that way function somewhat like a time machine, allowing you to re-initialize your project to an earlier version, in order to reproduce your results for example. They also make it easier to document these changes, so that all of the users of a project are notified of the changes made and the reasons they were made.
+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; 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.
-== Basic Functionality ==
+== Principe de base ==
-Source code management tools function using a basic principle of separating local modifications made by a user, in his or her local directory, and what is called the repository. The repository contains, in a structured manner, the history of all of the modifications made by all of a project's contributors. The development of a software project using a source code management tool is thus modified in comparison to the development of a purely ''local'' project. Rather than simply saving your modifications to the local disk drive, you as a contributor have to submit (''commit'') your modifications to the repository in order to make them available to other developers. Inversely, developers need to make sure they are using the latest version of a file by retrieving it from the repository (''checkout'', ''update'') before making their own modifications. If two programmers modify the same source code file at the same time, the source code management tool may report a conflict during the submission of the two rival modifications or automatically resolve the conflict if possible.
+Les outils de gestion 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 référentiel 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 de simplement enregistrer ses modifications sur le disque dur local, un contributeur doit soumettre (<i>commit</i>) les modifications vers le référentiel 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 référentiel (<i>checkout</i>, <i>update</i>) avant d'y apporter leurs 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 ==
+== Familles d'outils de contrôle des révisions ==
-The principal revision control tools can be divided into two ''families'' or ''generations''. First generation tools, which include [https://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [https://en.wikipedia.org/wiki/Apache_Subversion 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 [https://en.wikipedia.org/wiki/Git_%28software%29 Git], [https://en.wikipedia.org/wiki/Mercurial Mercurial] and [https://en.wikipedia.org/wiki/GNU_Bazaar 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.
+Les principaux outils de contrôle des révisions peuvent se répartir en deux familles ou <i>générations</i>. Les outils de première génération, dont font partie [https://fr.wikipedia.org/wiki/Concurrent_versions_system CVS] et [https://fr.wikipedia.org/wiki/Apache_Subversion SVN], utilisent un référentiel central unique. Toutes les modifications sont ainsi soumises et récupérées à partir du référentiel.
+Les outils de deuxième génération, dont font partie [https://fr.wikipedia.org/wiki/Git Git], [https://fr.wikipedia.org/wiki/Mercurial Mercurial] et [https://fr.wikipedia.org/wiki/Bazaar_%28logiciel%29 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 <i>commit</i> et <i>checkout</i> peuvent ainsi être beaucoup plus rapides et exécuter des opérations plus complexes. Aussi, 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 sont abandonnées et que leur branche <i>meurt</i>. Ce modèle de développement est particulièrement adapté aux gros projets comptant plusieurs développeurs.
-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'').
+En contrepartie, les modifications qui doivent être poussées vers un dépôt externe doivent l'être en deux étapes&nbsp;: elles sont d'abord soumises dans le dépôt local (<i>commit</i>), puis elles sont <i>poussées</i> (<i>push</i>) 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 trouver (<i>pull</i> ou <i>get</i>) pour les importer dans son dépôt local, puis mettre à jour sa version de travail (<i>update</i> ou <i>checkout</i>).
-== Choosing a Tool ==
+== Choix d'un outil ==
-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 [https://en.wikipedia.org/wiki/Apache_Subversion SVN] can be sufficient. If your project is larger, with external collaborators, you should consider a second generation tool like [https://en.wikipedia.org/wiki/Git_%28software%29 Git] or [https://en.wikipedia.org/wiki/Mercurial Mercurial].
+Si vous désirez contribuer à un projet existant, vous n'aurez pas le choix d'utiliser l'outil qui a été choisi au départ par les développeurs. Si vous démarrez votre propre projet, le choix dépendra de l'envergure de votre projet. S'il s'agit d'un projet où il n'y aura que quelques contributeurs, qui demeurera privé, et pour lequel vous voulez simplement garder un historique des modifications, un outil de première génération comme [https://fr.wikipedia.org/wiki/Apache_Subversion SVN] peut être suffisant. S'il s'agit d'un projet de plus grande envergure avec des collaborateurs externes, vous devrez probablement envisager les outils de deuxième génération comme [https://fr.wikipedia.org/wiki/Git Git] ou [https://fr.wikipedia.org/wiki/Mercurial Mercurial].
-<small>This page is derived from [https://wiki.calculquebec.ca/w/Gestion_de_code_source].</small>
+=== Où situer le référentiel ===
+Un point à bien considérer est l'endroit où sera situé le référentiel. Si vous et vos collaborateurs travaillez toujours sur le même ordinateur, le référentiel peut n'être visible que sur cet ordinateur. Par contre, si vous ou vos collaborateurs utilisez plusieurs ordinateurs, un accès via l'internet serait souhaitable; le code peut ainsi être facilement synchronisé et le fait que le code soit distribué ajoute à sa sécurité.
+Pour des détails sur comment configurer un référentiel, vous pouvez consulter [https://civicactions.com/blog/how-to-set-up-an-svn-repository-in-7-simple-steps/ svn],[https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols git],[https://about.gitlab.com/?utm_source=google&utm_medium=cpc&utm_campaign=Search%20-%20Brand&utm_content=GitLab%20-%20Open%20Source%20Git&utm_term=gitlab&gclid=CPWslub9vtACFZSEaQodwzoAew gitlab], [https://github.com/gitbucket/gitbucket gitbucket]. Pour connaitre certains services disponibles en ligne qui ne nécessitent pas que votre serveur soit toujours accessible, consultez [https://bitbucket.org/product bitbucket], [https://github.com/ github], [https://about.gitlab.com/ gitlab], [https://sourceforge.net/ sourceforge]
+== Référence ==
+[https://www.youtube.com/watch?v=EmMNIMDl9hM Cette courte vidéo]  traite des notions de base avec Git.
+[[Category:Pages with video links]]