Forum aux questions Git

Tout d’abord, vérifiez que vous disposez d’un référentiel origin configuré. Vous devez disposer d’un tel référentiel si vous avez cloné (git clone) votre dépôt. Lorsque vous consultez une branche qui n’existe pas localement, Git détermine s’il existe une branche distante portant le même nom. S’il en existe, Git crée une branche locale avec une référence à la branche distante de ce nom. Utilisez git pull pour télécharger les validations et de rattraper Git sur l’historique des branches localement.

git branch sans arguments affiche les branches locales et met en surbrillance celles que vous avez extraites. Dans Visual Studio, la barre d’état affiche également la branche actuelle lorsque vous travaillez avec un projet stocké dans un référentiel Git local.

La pratique acceptée consiste à effectuer des validations distinctes pour les modifications logiquement distinctes. Considérez les commits comme des entrées dans un journal. Chaque fois que vous apportez une modification qui vaut la peine de le noter, enregistrez-le dans une validation. Une option populaire consiste à permettre à tous de s’engager localement autant qu’ils le souhaitent, mais avant de pousser les commits locaux, ils les écrasent d’abord par le rebasage. Cette option offre aux utilisateurs la flexibilité nécessaire pour effectuer des validations fréquentes, tout en conservant l’historique des validations rationalisé.

De grands projets avec de nombreuses validations et un large éventail de contributeurs peuvent entraîner des historiques de validation pour la branche main qui représente l’historique de développement des branches de rubriques fusionnées en main plutôt que l’historique de développement du projet global. Git fournit une fonctionnalité permettant de condenser les validations sur les branches par le biais de validations de squashing et de rebasage. Lorsque vous effectuez un squash sur des validations, l’historique des validations sur une branche devient moins détaillé, ce qui simplifie l’historique des validations sur la branche principale une fois fusionné.

Utilisez la commande git blame pour savoir qui a apporté une modification particulière à un fichier. À partir de votre référentiel local, vous pouvez exécuter git blame avec le paramètre -L, en spécifiant les lignes d’intérêt. Blame produit une sortie mise en forme montrant la validation qui a mis à jour la ligne et le nom de la personne qui a effectué la validation.

> git blame foo.js -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame recherche l’historique de validation pour vous. Vous pouvez également consulter l’historique d’un fichier dans le portail web pour déterminer qui a apporté une modification et quand. Ouvrez l’Explorateur de code pour votre référentiel et votre branche, puis sélectionnez le fichier d’intérêt. Azure Repos affiche un historique de validation complet pour ce fichier sur la branche actuelle.

L’extraction d’une autre branche dans Git affecte l’état des fichiers sur votre système de fichiers. Git utilise l’historique de validation pour vous assurer que vous travaillez avec les fichiers qui représentent l’état de votre branche. Si vous essayez de modifier des branches pendant que vous avez des modifications non validées, ces modifications seront remplacées lors de l’extraction. Étant donné que Git ne souhaite pas que vous perdiez accidentellement vos modifications, cela empêche l’extraction de se produire. Deux options s'offrent à vous :

• Abandonnez les modifications et revenez à la validation la plus récente. Consultez Annuler les modifications apportées à Git pour obtenir des instructions sur la restauration vers la validation la plus récente.
• Validez les modifications : Consultez Enregistrement de votre travail dans Git avec des validations.
• Conserver votre travail actuel, enregistrer les modifications pour plus tard et nettoyer l’espace de travail jusqu’au dernier commit.

Parfois, vous souhaitez conserver les modifications, mais pas les valider, car elles ne sont pas à un moment où vous êtes à l’aise. Utiliser Git stash. La conservation prend les modifications intermédiaires et non modifiées actuelles dans votre branche et enregistre le travail, puis retourne votre branche à l’état de la dernière validation. Vous pouvez passer à l’autre branche, effectuer votre travail, puis lorsque vous revenez à cette branche, exécutez stash apply pour restaurer vos modifications.

> git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

Lorsque vous exécutez git stash apply, les modifications les plus récentes sont appliquées à votre branche actuelle. S’il existe un conflit en appliquant les modifications conservées, stash restaure les modifications pour les fichiers qui ne sont pas en conflit et créent des marqueurs de conflit dans les fichiers qui sont en conflit pour vous permettre de résoudre. Vous devez fusionner manuellement les modifications dans ce cas.

Une fois que vous avez terminé avec la conservation, supprimez-la avec git stash drop. Cette commande supprime le dernier ensemble de modifications conservé.

Vous pouvez avoir plusieurs conservations, mais cela nécessite plus de manipulation manuelle, car vous devez appliquer explicitement et déposer des conservations. Pour en savoir plus, consultez la documentation Git Stash.

Par défaut, la ligne de commande Git utilise un éditeur de ligne de commande lors de la demande de messages de validation, d’exécution de bases et d’autres tâches qui nécessitent des informations supplémentaires pour terminer. L’éditeur par défaut est configuré à l’aide de git config :

> git config core.editor _path_to_editor_ _options_to_editor_

Git pour Windows facilite la définition du Bloc-notes en tant qu’éditeur :

> git config core.editor notepad

Cette commande configure le Bloc-notes Windows pour modifier les informations Git en fonction des besoins et passer correctement le texte de Git vers le Bloc-notes. Vous pouvez également spécifier

> git config format.commitMessageColumns 72 

Pour conserver les colonnes de texte dans les messages de validation sur la ligne 72 et la ligne préférées après avoir atteint cette limite de caractères sur une ligne.

Git place un nom d’utilisateur et des informations d’adresse e-mail à l’intérieur de chaque validation, et Azure Repos utilise ces informations lors de l’affichage des validations et lors de l’utilisation des demandes de tirage. Si vous travaillez sur la ligne de commande, vous pouvez mettre à jour les informations de nom et d’e-mail affichées à l’aide de la commande git config :

> git config --global user.email "frank@fabrikam.com"
> git config --global user.name "Francis Totten"

L’option --global définit l’e-mail et le nom inclus dans les validations pour tous les référentiels Git sur ce système. Si vous souhaitez modifier les paramètres d’un référentiel unique, vous devez passer au répertoire où se trouve le référentiel Git et exécuter les commandes ci-dessus sans l’indicateur --global.

Vous pouvez également modifier les paramètres de nom et d’e-mail de Visual Studio. Dans le menu Git , sélectionnez Paramètres dans la boîte de dialogue Options, sélectionnez Paramètres globaux Git ou Paramètres du dépôt Git>Général.

Visual Studio 2019 version 16.8 et versions ultérieures fournit une expérience de contrôle de version Git tout en conservant l’interface utilisateur Team Explorer Git. Pour utiliser Team Explorer, décochez Outils>Options>Fonctionnalités en préversion>Nouvelle expérience utilisateur Git dans la barre de menu. Vous pouvez exercer les fonctionnalités Git à partir de l’une ou l’autre interface de manière interchangeable.

Dans Team Explorer, choisissez Paramètres et sous Git, sélectionnez le lien Paramètres globaux ou Paramètre du référentiels.