Comprendre comment les commandes Team Foundation Version Control (TFVC) sont mappées aux workflows Git
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Visual Studio 2019 | Visual Studio 2022
Envisagez-vous d’adopter Git, connaissez-vous les actions TFVC et vous demandez-vous comment ils mappent à Git? Les deux sont des systèmes de contrôle de code source puissants et matures. Toutefois, le mappage des actions courantes que vous avez habituées peut être une expérience déroutante.
Cet article ne décrit pas en profondeur les commandes Git, car elles sont bien documentées dans la documentation du produit, mais affichent des exemples pour vous aider à prendre les bonnes décisions, tout en passant par une création classique -> clone -> branche -> modification -> validation ->flux de travail Push.
Commencez au début en créant un dépôt
Chaque projet peut héberger des dépôts TFVC et Git dans le même projet, en créant un TFVC et un ou plusieurs référentiels Git.
Une fois le dépôt créé, vous recevez des instructions pas à pas pour commencer rapidement.
Cliquez sur Créer un fichier ReadMe à la fin de la page d’instructions, pour donner le contexte du dépôt et créer un historique.
Créer un espace de travail et obtenir la dernière version
Lors de la connexion à un dépôt TFVC pour la première fois, vous créez généralement un espace de travail et obtenez le dernier code. Alors, comment commencer dans Git ?
À l’instar d’un espace de travail dans TFVC, vous clone le dépôt Git dans un dossier sur votre ordinateur. Le clonage télécharge tout le contenu et l’historique du référentiel sur votre ordinateur local. Une fois que vous avez le référentiel cloné, presque toutes les opérations sont effectuées localement. Vous pouvez travailler hors connexion avec une sauvegarde complète du référentiel centralisé.
git clone https://dev.azure.com/demo-fabrikam/Fabrikam/_git/Mapping-TFVC-actions-to-Git
Vous ne devez cloner qu’une seule fois par dépôt, mais comme les espaces de travail TFVC, vous pouvez avoir plusieurs clones pour isoler le travail en cours. Toutefois, le branchement est généralement un meilleur moyen d’isoler les modifications.
Créer une branche
Avec Git, vous travaillez toujours dans une branche et par défaut dans la branche main. Nous vous recommandons de créer plusieurs branches locales. Il s’agit d’un processus qui prend quelques secondes et vous permet de basculer en toute transparence entre les branches et de travailler en isolation. Contrairement aux branches TFVC, qui sont délimitées aux chemins d’accès, les branches Git sont délimitées au référentiel. Elles sont légères, peuvent être locales uniquement ou partagées avec d’autres personnes lorsque vous êtes prêt à partager vos modifications.
Envisagez de créer des branches si vous avez besoin de travailler en isolation, de suspendre votre travail, de vous concentrer sur de nouvelles fonctionnalités ou si vous envisagez de mener une demande de tirage Git.
En tant qu’utilisateur TFVC, répétez quelques fois :
- Le branchement est recommandé !
- Les branches Git sont peu coûteuses, rapideset puissantes !
- Git vous encourage à utiliser des branches locales.
- Publiez des branches locales dans votre référentiel centralisé en fonction des besoins.
- Vérifiez toujours votre contexte de branche avant d’apporter des modifications.
- Nommez la branche à l’aide d’une convention commune telle que les utilisateurs/alias/branchname, par exemple : users/doris/newfeature
Créez et basculez vers une branche de rubrique locale, nommée francis/demo-feature. Il est recommandé d’exécuter git status en premier, de vérifier que vous êtes sur la branche droite pour commencer.
git checkout -b francis/demo-feature
Apporter une modification en ajoutant des fichiers
Comme pour l’expérience TFVC, les nouveaux fichiers du dossier de travail ne font pas automatiquement partie du référentiel. Vous placez vos nouveaux fichiers avec la commande git add, synonyme d’une opération add Items to Folder dans TFVC.
git add <file>
or
git add --all
À l’aide de l’exemple prédéfini, vous aurez 13 nouveaux fichiers inclus et intermédiaires dans le référentiel local.
Voir les modifications en attente
Vous vous demandez quels changements se trouvent maintenant dans votre environnement de travail ? Comme précédemment, la commande Git status ou la vue Changes dans l’IDE Visual Studio affiche les modifications apportées à votre arborescence de travail.
git status
Vérifier les modifications et valider localement
Dans TFVC, vous partagez vos modifications avec une archive, qui envoie vos modifications en attente au serveur. Le processus Git est un peu différent. Tout d’abord, vous validez dans le référentiel local, en créant un objet de validation (comme un ensemble de modifications), puis vous envoyez (push) ces modifications au serveur.
Vous validez les modifications apportées à votre référentiel local à l’aide de git commit, similaire à Checkin Pending Changes de TFVC. Une différence clé est que git commit valide vos modifications dans le référentiel local au lieu du référentiel distant.
git commit
Vérifier les modifications avec le dépôt serveur/distant
Tout d’abord, vous devez publier votre branche francis/demo-feature locale sur le serveur distant, qui inclut toutes les modifications validées.
git push --set-upstream origin francis/demo-feature
Pour synchroniser d’autres mises à jour dans votre local avec le référentiel distant, vous devez envoyer (push) vos modifications à l’aide de git push. La pratique recommandée à l’aide de la commande Git ou de l’IDE Visual Studio consiste à :
fetchpour télécharger du contenu et afficher un aperçu des modifications entrantes d’autres utilisateurs.pullpour télécharger, puis fusionner les modifications d’autres utilisateurs.pushpour partager vos modifications locales.
Afficher l’historique
Pour voir la validation, vous venez de créer, vous pouvez passer en revue l’historique local.
Pour un historique compact, utilisez :
git log --oneline
Pour obtenir une vue détaillée, utilisez :
git log
Comme indiqué ci-dessus, git log répertorie l’auteur, l’e-mail, la date écrite et la somme de contrôle SHA-1 de validation. En tant qu’utilisateur TFVC, vous pouvez utiliser l’option --stat pour inclure plus d’informations, telles que le nom de fichier et les statistiques de modification.
Vous pouvez également afficher l’historique du référentiel centralisé à l’aide du portail web Azure DevOps Services.
Dans le portail web Azure DevOps Services, choisissez CODE > Historique ou CODE > Explorer > Historique
À ce stade, vous avez exploré avec succès la création -> clone -> branche >- modification -> validation ->flux de travail Push, en fonction des actions TFVC courantes.
Vous avez également la possibilité d’émettre une demande de tirage (pull request) pour publier et mettre en scène vos modifications sur le référentiel serveur/distant à ce stade.
Autres actions
Passer d’une branche à l’autre
Lorsque vous utilisez Git, vous ne modifiez pas les branches en basculant vers des dossiers et des emplacements distincts sur votre ordinateur. Vous modifiez le contexte en effectuant une opération checkout, en faisant correspondre l’intégralité du répertoire de travail à la branche ou à la validation sélectionnée. Rapide et simple !
Ligne de commande
git checkout <branch>
Si vous avez oublié les branches que vous avez dans votre référentiel local, utilisez git branch pour répertorier les branches par défaut et connues.
Gardez à l’esprit la branche sur laquelle vous travaillez ! Lorsque vous travaillez avec plusieurs branches dans Git, vous changez de branches en place dans le même répertoire de travail. Le basculement entre les branches est une opération rapide et vous permet de vérifier que vous êtes sur la branche appropriée à tout moment est une bonne pratique.
Obtenir la version la plus récente
Il existe de nombreuses raisons de vouloir obtenir des mises à jour. Par exemple, lorsque vous devez basculer le contexte vers un autre projet, actualisez votre ordinateur de développement avec la dernière version du codebase.
Ligne de commande
git pull
or
git fetch
suivi de
git merge FETCH_HEAD
Obtenez toujours la dernière version et résolvez les conflits de fusion localement.
Annuler les modifications locales
Il peut y avoir une raison valide de rétablir toutes les révisions que vous avez apportées dans votre référentiel local et de réinitialiser votre environnement de travail vers la dernière version du référentiel distant.
Ligne de commande
git reset --hard HEAD
suivi de
git pull origin
suivi de
git clean -xdf
Le scénario est synonyme de faire un Get > Latest Version avec les options Overwrite writable files that are not checked out et Overwrite all files if the local version matches the specified version dans TFVC.
Vous pouvez également supprimer manuellement votre dépôt local après avoir effectué une copie validée, puis clone à nouveau le référentiel.
Il existe beaucoup plus d’actions et d’options disponibles pour les utilisateurs Git. Voici quelques sites de référence utiles pour une lecture plus poussée :
- Commandes Git abordées ici, reportez-vous à la documentation git
- Pensez à Git, un Guide pour le Perplexe.
- Comment annuler (presque) quoi que ce soit avec Git, par Joshua Wehner
Q&R
Qu'en est-il de la synchronisation ?
Vous vous demandez peut-être : « L’IDE Commit and Sync Visual Studio ne fait-il pas tout cela comme par magie ? ».
Sélectionnez Git>Commit ou Stash pour ouvrir les modifications Git. Sélectionnez le menu déroulant Valider tout, puis Valider tout et Synchroniser.
Ou, dans Team Explorer, sélectionnez le menu déroulant Validation, puis Commande et synchronisation.
Un grand pouvoir implique de grandes responsabilités ! De nombreux utilisateurs n’aiment pas sync, car il peut parfois mettre en désordre votre historique local et ajouter une validation de fusion au-dessus de votre validation actuelle. Une fois que vous êtes dans un état incorrect, vous devez revenir à la ligne de commande, car il n’existe actuellement aucune prise en charge de réinitialisation dans l’IDE.
Auteurs : Jesse Houwing, Martin Hinshelwood, Mike Fourie et Willy Schaub de l’ALM | DevOps Rangers. Connectez-vous avec eux ici.
(c) 2015 Microsoft Corporation. Tous droits réservés. Ce document est fourni « comme tel ». Les informations et opinions exprimées dans ce document, y compris les URL et autres références à des sites Internet Web, peuvent changer sans préavis. Vous assumez les risques liés à leur utilisation.
Ce document ne vous fournit aucun droit légal de propriété intellectuelle de tout produit Microsoft. Vous pouvez copier et utiliser ce document pour votre information uniquement.