Valider les fichiers et afficher l’historique
Maintenant que vous avez initialisé votre référentiel Git, vous êtes prêt à commencer à ajouter des fichiers. Dans cette unité, vous allez apprendre à demander à Git de suivre les modifications apportées aux fichiers de votre référentiel.
Notes
Les commandes de cette unité sont présentées pour illustrer les concepts. N’exécutez pas encore les commandes. Vous allez bientôt mettre en pratique ce que vous apprenez ici.
Structure de dossiers de votre référentiel
Lorsque vous travaillez avec un système de contrôle de version tel que Git, il est important de planifier la manière dont vous stockez vos fichiers. Il est judicieux de disposer d’une structure de dossiers claire.
Si vous générez du code Bicep pour déployer une application ou une autre solution, il est également judicieux de stocker vos fichiers Bicep dans le même référentiel que le code d’application et autres fichiers. De cette façon, chaque fois qu’un utilisateur a besoin d’ajouter une nouvelle fonctionnalité qui modifie à la fois le code Bicep et l’application, ils seront suivis ensemble.
La planification de votre structure de dossiers facilite également le déploiement de votre solution à partir d’un pipeline. Vous en apprendrez plus sur les pipelines dans un module ultérieur.
Différentes équipes ont des conventions différentes quant à la façon dont elles configurent leurs dossiers et fichiers de référentiel. Même si vous ne travaillez pas avec une équipe, il est toujours judicieux de choisir une convention à suivre. Une bonne structure de fichiers et de dossiers aide tous ceux qui utilisent votre code par la suite.
Si votre équipe n’a pas encore de préférence, voici une suggestion sur la façon dont vous pouvez le faire :
- À la racine de votre référentiel, créez un fichier Readme.md . Ce fichier texte, écrit en Markdown, décrit le contenu du dépôt et fournit des instructions pour aider les membres d’équipe à l’utiliser.
- À la racine de votre référentiel, créez un fichier Readme.md . Dans le dossier :
- Stockez votre modèle Bicep principal, nommé main.bicep.
- Créez un sous-dossier modules pour stocker vos modules Bicep.
- Si vous avez d’autres scripts ou fichiers utilisés lors des déploiements, stockez-les dans le dossier Deploy.
- À la racine de votre dépôt, créez un dossier src pour le code source. Utilisez-le pour stocker le code de l’application.
- À la racine de votre référentiel, créez un fichier docs. Utilisez-le pour stocker la documentation relative à votre solution.
Voici une illustration de la façon dont cette structure peut se présenter sur le site Web de votre société de jouets :
Indexer vos modifications
Une fois que vous avez apporté des modifications à un fichier ou à des fichiers, vous devez les indexer. La mise en lots indique à Git que les modifications sont suffisamment importantes pour être conservées. Cette étape peut paraître inutile, mais l’indexation vous offre une grande flexibilité de travail. Par exemple, vous pouvez apporter des modifications à plusieurs fichiers, mais vous ne souhaitez en conserver qu’une seule. Ou bien, vous souhaiterez peut-être conserver uniquement certaines des modifications que vous avez apportées à un fichier.
Pour indexer un fichier, utilisez la git add commande et spécifiez le nom de fichier ou de dossier que vous souhaitez indexer. Après l’indexation d’un fichier, Git sait que vous pouvez éventuellement commiter les changements. Lorsque vous interrogez l’état du référentiel à l’aide de git status, vous voyez les modifications indexées.
Important
Une fois que vous avez indexé un fichier, si vous y apportez d’autres modifications avant de valider, Git n’enregistre pas ces modifications. Vous devez réindexer le fichier pour que Git ajoute les changements les plus récents.
Par exemple, imaginez que vous avez créé un module Bicep pour définir un compte Azure Cosmos DB. Il est nommé Cosmos-DB.bicep, et vous l’avez enregistré dans le dossier Deploy/modules . Voici comment vous pouvez indexer le fichier :
git add deploy/modules/cosmos-db.bicep
Vous pouvez également indexer toutes les modifications apportées à votre référentiel en exécutant cette commande à partir du dossier racine de votre référentiel :
git add .
Valider les modifications indexées
Une validation représente un ensemble de modifications apportées à un ou plusieurs fichiers de votre référentiel. Lorsque vous êtes prêt à valider les modifications que vous avez indexées, vous utilisez la git commit commande. Votre validation comprend un message de validation, qui est une description explicite des modifications.
Voici un exemple qui montre comment valider les modifications indexées indiquées précédemment :
git commit --message "Add Cosmos DB account definition"
Notes
Visual Studio Code peut également effectuer une validation dans votre référentiel Git. Lorsque vous utilisez l’intégration Git dans Visual Studio Code, si vous n’avez pas déjà indexé les fichiers, Visual Studio Code vous demande si vous souhaitez qu’il indexe tous les fichiers modifiés pour vous. Vous pouvez même définir ce comportement comme comportement par défaut. Ou, si vous préférez, vous pouvez effectuer l’indexation et la suppression de l’indexation des fichiers manuellement à l’aide du Contrôle de code source dans Visual Studio Code.
Rendez vos messages de validation courts, mais sous forme de texte descriptif. Lorsque vous ou un membre de l’équipe examinerez plus tard l’historique des validations, chaque message de validation devra expliquer la nature de la modification et la raison pour laquelle vous l’avez effectuée.
Il n’existe aucune règle concernant le contenu ou la mise en forme des messages de validation. Mais, de manière conventionnelle, ils sont rédigés au présent et sous la forme d’une phrase complète, comme si vous donniez des ordres à votre code base.
Conseil
Il est recommandé d’écrire des messages de validation descriptifs même lorsque vous travaillez par vous-même. Quelqu’un d’autre devra peut-être consulter votre code à l’avenir. Même si ce n’est pas le cas, vous devrez peut-être passer en revue votre propre historique et vous souhaiterez faciliter votre vie !
Voici quelques exemples de messages de validation corrects :
- Mettez à jour la configuration de App Service pour ajouter une configuration réseau.
- Supprimez le compte de stockage, car il a été remplacé par une base de données Cosmos DB.
- Ajoutez la définition de ressource Application Insights et intégrez-la à l’application de fonction.
Afficher l’historique d’un fichier
Une fois que vous avez validé des fichiers dans votre référentiel Git, vous pouvez utiliser la git log commande CLI pour afficher l’historique d’un fichier ou même toutes les validations dans le référentiel.
Pour visualiser une liste des validations, exécutez la commande suivante :
git log --pretty=oneline
La sortie de cette commande affiche une liste des validations, avec les validations les plus récentes en premier. Chaque ligne comprend le hachage de validation, qui est un identificateur que Git utilise en interne pour effectuer le suivi de chaque validation. Elle comprend également le message de validation, raison pour laquelle il est si important de rédiger des messages de validation corrects.
Il est également courant d’afficher les validations dans un fichier spécifique. Vous pouvez spécifier le nom du fichier lorsque vous exécutez la git log commande, comme suit :
git log deploy/main.bicep
L’interface CLI Git et la commande git log fournissent de nombreux arguments que vous pouvez utiliser pour afficher des informations sur vos validations et vos fichiers. Toutefois, il est souvent plus facile d’utiliser Visual Studio Code pour afficher l’historique de validation d’un fichier.
Dans le volet de l'Explorateur de Visual Studio Code, vous pouvez sélectionner un fichier dans votre référentiel et le maintenir enfoncé (ou cliquer dessus avec le bouton droit), puis sélectionner Afficher la chronologie. Le volet Chronologie s’ouvre et affiche une liste de chaque validation qui a affecté ce fichier. Lorsque vous sélectionnez une validation, vous voyez les modifications exactes apportées au fichier. Vous verrez comment utiliser ces informations dans l’exercice suivant.