Comprendre un Gestionnaire de Sources :

 L’inscription pour authentification

Un simple mail suffit pour valider une inscription qui se traduit par un mot de passe ((par diffusion automatique ou par choix utilisateur) ; en général vous pourrez récupérer un mot de passe oublié par mail (comme avec SPIP), voire le modifier...
Ce code utilisateur reçoit alors des droits d’usage, en lecture (souvent anonyme) ou en écriture sur tout ou partie(s) des dépots concernés, pour avoir accès aux fichers.

La démarche consiste pour l’utilisateur à importerextraire une version de fichiers sur un dossier en local, puis à renvoyer (commiter) une version modifiée au serveur pour fusion, avec commentaires explicatifs : mais vu du serveur, les sens des mots s’inversent...
En plus le système de gestion doit traiter les conflits de révisions concourantes -souvent sous forme d’un arbre historisant chacune des révisions- enregistrant les modifications concomitantes de plusieurs utilisateurs sur les mêmes fichiers en quasi-simultanné.

 Les opérations de base

Un excellent résumé des opérations classiques :
 le trunk : la branche principale des sources
 un checkout  : récupérer des sources à modifier
 un commit  : renvoyer des sources modifiées
 précéder d’un update : ré-intégrer à ses propres sources les autres modifications (à faire systématiquement avant lecommit !)
 poser un tag  : à un état utile à gérer (stable)
 brancher : pour gérer une branche secondaire de développement
 merger :pour ré-injecter les modifications effectuées dans une autre branche

 La notion de dépot-repository

Pour partager des fichiers source (c’est-à-dire d’abord récupérer une version des fichiers sur un poste de travail local), un peu de collaboratif est nécessaire, géré informatiquement autour d’une base centrale en charge du contrôle-suvi des versions.
Chaque dossier-projet en développement est en général structuré autour d’un tronc commun de développement actif, avec des branches autonomes pour certaines orientations de développement ; enfin la notion de tag permet d’étiqueter un état des divers sources du projet, pour garder cette situation rapidement accessible parmi l’arbre des révisions successifs.
Les derniers systèmes privilégient désormais un mode de contrôle décentralisé, donnant plus d’autonomie à chaque dépôt-utilisateur (à se créer en local) en cas de panne ou d’indisponibilité du serveur d’origine distant : c’est une raison du passage du serveur SVN au serveur Git...
Au cours du workflow de révision des fichiers sources selon les interventions des ’commiters’ on passe par quatre étapes :
 checkout : récupération/clonage d’un depot source à l’état actualisé des dernières révisions,
 modification(s) individuelle(s) autonome en local
 stabilisation du source par le modifieur en état stage
 commit de synchronisation de la version individuelle en stage,
avant validation synchronisée en global entre les dépots utilisateurs

 Une organisation des dossiers

Les sources sont gérés sur le serveur comme sur votre disque dur, donc par dossiers de répertoires et arborescence de sous-répertoires : la première étape est de prendre connaissance de celle-ci, pour savoir où chercher et/ou déposer du code.

Une fois trouvé le dossier de base contenant le projet qui vous intéresse, reste à gérer le partage des sources, et des commits de révisions successives.

 Le fonctionnement en branches d’un sous-projet

Lors de la vie d’un projet, les développements ne sont pas toujours linéaires, soient par divergence ou fork du projet initial, et plus souvent par avancement à des niveaux différents de plusieurs branches du projet, pour des raisons de différentiation technique (compatibilité avec une ancienne release) et/ou fonctionnelle, par exemple pour étudier la faisabilité de plusieurs solutions nouvelles.
Il peut s’avérer nécessaire de fusionner (merge) les développements portés sur deux branches, et dans certains cas de gérer les conflits dus à des commits indépendants portant sur des mêmes lignes des fichiers concernés...

 D’autres services rendus

Le gestionnaire de sources permet de suivre, et donc de retracer la succession des versions des sources par consultation de l’historique, et -les révisions étant normalement toujours accompagnées d’un message de commit- d’identifier leurs motivations.
En particulier, des commandes facilitent la mise en évidence des différences entre versions.
Enfin, le gestionnaire permet la délivrance facile d’archive compacte des sources à un état final ou étiqueté à un stade précis.

 Quelques bonnes pratiques

 penser à faire des update fréquents, et toujours avant commit
 toujours commiter une version stable testée (sans bugs, ni régression)
 commenter les commits (avec indication de la branche concernée)
 toujours repartir du trunk pour créer une branche
 ne jamais commiter sur un tag
 limiter le nombre de branches
 normaliser la typologie destags (en X.Y.Z avec Y pair pour stables,toujours à partir du trunk)