FAQ sur Git

Tout d’abord, assurez-vous d’avoir un référentiel origin configuré. Vous devriez avoir cela si vous avez cloné votre référentiel en utilisant git clone. Lorsque vous consultez une branche qui n’existe pas localement, Git vérifie s’il existe une branche distante portant le même nom. Si c’est le cas, Git crée une branche locale qui fait référence à la branche distante. Utilisez git pull pour télécharger les commits et mettre à jour l’historique de la branche localement.

Exécutez git branch sans arguments pour afficher les branches locales et mettre en évidence celle que vous avez consultée. Dans Visual Studio, la barre d’état affiche également la branche actuelle lorsque vous travaillez sur un projet stocké dans un référentiel Git local.

Il est recommandé de faire des commits séparés pour des modifications logiquement distinctes. Considérez les commits comme des entrées dans un journal. Chaque fois que vous apportez une modification digne d’être notée, enregistrez-la dans un commit. Une approche populaire consiste à permettre des commits locaux fréquents, mais à les compresser par rebasage avant de pousser. Cela offre de la flexibilité tout en gardant l’historique des commits épuré.

Les grands projets avec de nombreux commits et contributeurs peuvent entraîner un historique de branche main qui reflète davantage le développement des branches thématiques que celui du projet global. Git vous permet de condenser les commits sur les branches via la compression des commits et le rebasage. La compression des commits rend l’historique de la branche moins verbeux, simplifiant ainsi l’historique des commits sur la branche principale une fois fusionnée.

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 Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 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 complet des commits pour ce fichier sur la branche actuelle.

Passer à 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.

Ce problème est lié aux conflits de fusion dans les fichiers binaires volumineux. La limite actuelle pour les fichiers est de 100 Mo. La solution de contournement consiste à résoudre les conflits de fusion localement en fusionnant la cible dans la source localement, en résolvant les conflits, puis en poussant les modifications.

Git LFS (Large File Storage) est recommandé pour stocker de gros fichiers binaires, non seulement pour éviter les conflits mais aussi pour gérer la taille globale du référentiel, ce qui affecte les temps de clonage et de poussée.

Si vous souhaitez enregistrer vos modifications sans les valider, utilisez Git stash. Stash enregistre les modifications en cours (staged et unstaged) dans votre branche et rétablit votre branche à l’état du dernier commit. Vous pouvez ensuite passer à une autre branche, faire votre travail, puis exécuter 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 récemment remisées (stash) sont appliquées à votre branche actuelle. S’il y a un conflit, [stash] restaure les modifications pour les fichiers qui ne sont pas en conflit et crée des marqueurs de conflit dans les fichiers qui le sont. Vous devez fusionner manuellement les modifications dans ce cas.

Une fois que vous avez terminé avec le stash, supprimez-le avec [git stash drop]. Cette commande supprime le dernier ensemble de modifications remisées (stash).

Vous pouvez avoir plusieurs stashes, mais leur gestion nécessite plus de manipulation manuelle, car vous devez explicitement appliquer et supprimer les stashes. En savoir plus dans la documentation Git Stash.

Par défaut, Git en ligne de commande utilise un éditeur de ligne de commande lorsqu’il demande des messages de commit, effectue des rebasages, et d’autres travaux nécessitant des informations supplémentaires pour être terminés. 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 "example-user@example-site.com"
> git config --global user.name "Example User"

L’option --global définit l’email et le nom inclus dans les commits 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.