Les deux modes de gestion

Lorsque vous créez votre premier projet, par défaut Azure DevOps présélectionne le gestionnaire de code source Git. Bien que Git soit aujourd’hui le gestionnaire de code source le plus utilisé, Azure DevOps propose tout de même la possibilité d’utiliser TFVC (Team Foundation Version Control).

Avant d’étudier concrètement l’aspect pratique de ces deux modes de gestion du code source, il convient d’expliquer la différence fondamentale entre leurs deux fonctionnements.

1. Centralisé vs décentralisé

Ce qui distingue majoritairement Git de TFVC est la notion de centralisation.

a. Contrôle de code source centralisé

Un code source centralisé dépend d’une autorité unique, généralement un serveur. En conséquence, le gestionnaire de code source dialogue systématiquement avec le serveur à chaque action que l’on souhaite réaliser (envoyer du code, travailler sur un fichier, etc.).

Cette centralisation impose des contraintes majeures :

Le lien avec le serveur doit être permanent, car c’est lui qui autorise ou refuse les demandes. Certains contrôles de code source permettent de travailler en mode déconnecté de façon temporaire, mais in fine, le lien avec le serveur doit être effectué.
Toutes les actions réalisées par le développeur sont tracées en temps réel. Ainsi, chaque extraction de fichier pour une modification est notée, et chaque événement important est historisé.

Bien qu’il soit compliqué de travailler de façon déconnectée avec un contrôle de source centralisé, la centralisation offre des possibilités non négligeables :

Du fait que le serveur est l’autorité principale, il existe un point unique de configuration pour gérer la façon dont l’équipe travaille avec le code source. Il est possible, par exemple, de définir les modes d’accès à un fichier (concurrent ou exclusif).
La centralisation permet une sécurité allant jusqu’aux fichiers. Il est ainsi possible de définir, sur le serveur, des droits spécifiques à chaque utilisateur, de façon...

Initialiser le dépôt de code source

Lorsque vous créez un projet avec Azure DevOps, il vous est demandé de choisir le contrôle de code source associé. Git est sélectionné par défaut. Pour faire un éventuel changement vers TFVC, dépliez la partie Advanced, et dans le champ Version control, choisissez TFVC :

Fenêtre de création de projet avec le choix du contrôle de code source

Choisir Git à la création du projet indique simplement que le contrôle de code source sera Git, sans pour autant créer d’éléments.

Si vous ouvrez le projet MonPremierProjet et cliquez sur l’élément de menu Files dans la section Repos, une page d’assistant s’affiche, vous permettant d’initialiser votre dépôt Git. Il y a ici plusieurs options pour initialiser le dépôt :

Cloner le dépôt vide sur votre ordinateur local pour l’initialiser. L’avantage de cette approche est que le lien avec le serveur distant, ici Azure DevOps, est déjà initialisé.
Créer et initialiser un dépôt Git sur votre ordinateur, puis l’envoyer vers Azure DevOps afin de l’utiliser.
Importer un dépôt Git depuis un autre projet Azure DevOps.
Demander à Azure DevOps d’initialiser le dépôt Git avec un fichier readme, et éventuellement un fichier gitignore, puis le cloner sur votre ordinateur local.

Dans la section suivante, nous allons voir les quelques concepts de base autour de Git. Si vous êtes utilisateur de Git et connaissez les commandes essentielles, passez à la section Git-flow.

1. Les commandes de base de Git

Pour pouvoir travailler avec Git, il est nécessaire d’installer l’outil localement. Le site officiel de Git (https://git-scm.com) indique les étapes à suivre afin d’installer Git sur votre ordinateur. Sur la partie droite du site, dans une image représentant un écran, un bouton permet de télécharger Git selon votre système d’exploitation. Selon le cas, vous pourrez télécharger l’installeur ou avoir accès aux lignes de commandes permettant d’installer l’outil.

Suivez la procédure proposée par votre environnement. Une fois Git installé...

Mise en place du git-flow sur Azure DevOps

Maintenant que vous avez acquis les fondamentaux, il est temps de voir comment mettre tous ces concepts en pratique sur l’interface Azure DevOps. Tout d’abord, commençons par découvrir comment gérer les branches sur Azure DevOps.

1. Gestion des branches

Pour rappel, l’onglet Files affiche la liste des fichiers et des dossiers qui se trouvent dans votre dépôt Git. Une liste déroulante en haut de cette vue permet de changer de branche.

Azure DevOps implémente une notion de propriété de branche. Plus précisément, dans cette liste figurent les branches communes à l’équipe (créées depuis l’interface). Au-dessous, un regroupement Mine contient les branches que vous avez créées sur votre poste local et que vous avez ensuite envoyées sur le serveur distant.

Lorsque vous choisissez un élément dans cette liste, l’affichage des fichiers et des dossiers est actualisé pour afficher ce que contient la branche sélectionnée.

Si vous choisissez par exemple la branche mabranche, vous pouvez constater que le fichier test2.txt est bien présent dans la zone inférieure.

Étant donné que la quasi-totalité des fichiers de code est aujourd’hui du texte brut, il est possible de cliquer directement sur un fichier dans cette zone pour l’afficher sur Azure DevOps. L’onglet qui s’affiche par défaut, lorsque vous cliquez sur un fichier, est Contents, mais il en existe d’autres :

History permet de voir tout l’historique d’un fichier, à savoir les différents commits qui ont provoqué une modification de ce fichier en particulier.
Compare propose une vue comparative permettant de voir les changements apportés par différents commits, notamment pour faire la différence entre deux versions.
Blame précise, pour chaque ligne du fichier actuel, qui est l’auteur et à quelle date a été réalisée la modification. Il n’est pas rare, pour des fichiers de code ayant une longue durée de vie, de retrouver un très grand nombre de modifications et d’auteurs pour un grand ensemble de lignes.

Azure DevOps offre la possibilité de modifier directement le fichier...

Repos : gestion du code source