Les premiers pas

Cette page portera sur la prise en main de Git. Nous commencerons par expliquer quelques notions de base sur les outils de contrôle de version, puis nous verrons comment faire fonctionner Git sur votre système et enfin comment le configurer pour commencer à fonctionner. À la fin de cette page, vous devriez comprendre pourquoi Git existe, pourquoi vous devriez l'utiliser et vous devriez être prêt à le faire.

À propos du contrôle de version

Qu'est-ce que le «contrôle de version» et pourquoi devriez-vous vous en soucier ? Le contrôle de version est un système enregistrant les modifications apportées à un fichier ou à un ensemble de fichiers au fil du temps afin que vous puissiez rappeler des versions spécifiques ultérieurement.

Si vous êtes graphiste ou concepteur Web et que vous souhaitez conserver chaque version d'une image ou d'une mise en page (ce que vous souhaiteriez très certainement), un système de contrôle de version (VCS) est une solution très judicieuse à utiliser. Il vous permet de rétablir les fichiers sélectionnés à un état antérieur, de rétablir l'ensemble du projet à un état antérieur, de comparer les modifications au fil du temps, de voir ayant modifié en dernier quelque chose pouvant causer un problème, ayant introduit un problème et quand, et bien plus encore. L'utilisation d'un VCS signifie également généralement que si vous faites une erreur ou perdez des fichiers, vous pouvez facilement les récupérer. De plus, vous obtenez tout cela pour très peu d'effort.

Systèmes de contrôle de version locaux

La méthode de contrôle de version préférée de nombreuses personnes consiste à copier les fichiers dans un autre répertoire (peut-être un répertoire horodaté, s'ils sont malins). Cette approche est très courante car elle est très simple, mais elle est également extrêmement sujette aux erreurs. Il est facile d'oublier dans quel répertoire on se trouve et d'écrire accidentellement dans le mauvais fichier ou de copier des fichiers que l'on ne voulait pas copier.

Pour résoudre ce problème, les programmeurs ont développé il y a longtemps des VCS locaux dotés d'une base de données simple gardant toutes les modifications apportées aux fichiers sous contrôle de révision.

L'un des outils VCS les plus populaires était un système appelé RCS, étant encore distribué sur de nombreux ordinateurs aujourd'hui. Le RCS fonctionne en conservant les ensembles de correctifs (c'est-à-dire les différences entre les fichiers) dans un format spécial sur le disque; il peut ensuite recréer l'apparence de n'importe quel fichier à tout moment en additionnant tous les correctifs.

Systèmes de contrôle de version centralisés

Le deuxième problème majeur auquel les utilisateurs sont confrontés est la nécessité de collaborer avec des développeurs sur d'autres systèmes. Pour résoudre ce problème, des systèmes de contrôle de version centralisés (CVCS) ont été développés. Ces systèmes (tels que CVS, Subversion et Perforce) disposent d'un serveur unique contenant tous les fichiers versionnés et d'un certain nombre de clients extrayant les fichiers à partir de cet emplacement central. Depuis de nombreuses années, il s'agit de la norme en matière de contrôle de version.

Cette configuration offre de nombreux avantages, notamment par rapport aux VCS locaux. Par exemple, tout le monde sait dans une certaine mesure ce que font les autres membres du projet. Les administrateurs ont un contrôle précis sur qui peut faire quoi, et il est beaucoup plus facile d'administrer un CVCS que de gérer des bases de données locales sur chaque client.

Cependant, cette configuration présente également de sérieux inconvénients. Le plus évident est le point de défaillance unique que représente le serveur centralisé. Si ce serveur tombe en panne pendant une heure, personne ne peut collaborer ni enregistrer les modifications de version sur quoi que ce soit sur lequel il travaille. Si le disque dur sur lequel se trouve la base de données centrale est corrompu et que des sauvegardes appropriées n'ont pas été conservées, vous perdez absolument tout, c'est-à-dire l'historique complet du projet, à l'exception des instantanés individuels que les utilisateurs ont sur leurs machines locales. Les VCS locaux souffrent du même problème : chaque fois que vous avez l'historique complet du projet au même endroit, vous risquez de tout perdre.

Systèmes de contrôle de version distribués

C'est là qu'interviennent les systèmes de contrôle de version distribués (DVCS). Dans un DVCS (comme Git, Mercurial ou Darcs), les clients ne se contentent pas d'extraire le dernier instantané des fichiers; ils reproduisent plutôt entièrement le dépôt, y compris son historique complet. Ainsi, si un serveur tombe en panne et que ces systèmes collaboraient via ce serveur, n'importe lequel des dépôts clients peut être copié sur le serveur pour le restaurer. Chaque clone est en réalité une sauvegarde complète de toutes les données.

De plus, la plupart de ces systèmes gèrent assez bien la présence de plusieurs dépôt à distances avec lesquels ils peuvent travailler, ce qui vous permet de collaborer avec différents groupes de personnes de différentes manières simultanément au sein du même projet. Cela vous permet de configurer plusieurs types de flux de travail n'étant pas possibles dans les systèmes centralisés, tels que les modèles hiérarchiques.

Une brève histoire de Git

Comme beaucoup de choses importantes dans la vie, Git a commencé avec un peu de destruction créatrice et de controverses enflammées.

Le noyau Linux est un projet de logiciel open source d'une portée assez large. Au cours des premières années de maintenance du noyau Linux (1991 à 2002), les modifications apportées au logiciel ont été transmises sous forme de correctifs et de fichiers archivés. En 2002, le projet de noyau Linux a commencé à utiliser un DVCS propriétaire appelé BitKeeper.

En 2005, la relation entre la communauté ayant développé le noyau Linux et la société commerciale ayant développé BitKeeper s'est rompue, et l'état gratuit de l'outil a été révoqué. Cela a incité la communauté de développement Linux (et en particulier Linus Torvalds, le créateur de Linux) à développer son propre outil basé sur certaines des leçons apprises en utilisant BitKeeper. Certains des objectifs du nouveau système étaient les suivants :

• Rapidité
• Conception simple
• Prise en charge solide du développement non linéaire (des milliers de branches parallèles)
• Entièrement distribué
• Capable de gérer efficacement de grands projets comme le noyau Linux (vitesse et taille des données)

Depuis sa naissance en 2005, Git a évolué et mûri pour être facile à utiliser tout en conservant ces qualités initiales. Il est incroyablement rapide, très efficace avec les grands projets et dispose d'un système de ramification incroyable pour le développement non linéaire.

Qu'est-ce que Git ?

En résumé, qu'est-ce que Git ? Il s'agit d'une section importante à assimiler, car si vous comprenez ce qu'est Git et les principes fondamentaux de son fonctionnement, il vous sera probablement beaucoup plus facile d'utiliser Git de manière efficace. Au fur et à mesure que vous apprenez à utiliser Git, essayez de vider votre esprit des choses que vous connaissez peut-être sur d'autres VCS, tels que CVS, Subversion ou Perforce. Cela vous aidera à éviter toute confusion subtile lors de l'utilisation de l'outil. Même si l'interface utilisateur de Git est assez similaire à celle de ces autres VCS, Git entrepose et réfléchit aux informations d'une manière très différente, et la compréhension de ces différences vous aidera à éviter toute confusion lors de son utilisation.

Des instantanés, pas des différences

La principale différence entre Git et tout autre VCS (Subversion et ses amis inclus) est la façon dont Git considère ses données. Conceptuellement, la plupart des autres systèmes entreposent les informations sous forme de liste de modifications basées sur des fichiers. Ces autres systèmes (CVS, Subversion, Perforce,...) considèrent les informations qu'ils entreposent comme un ensemble de fichiers et les modifications apportées à chaque fichier au fil du temps (cela est communément décrit comme un contrôle de version basé sur le delta).

Le Git ne considère pas ses données de cette façon, ni ne les entrepose. Il les considère plutôt comme une série d'instantanés d'un système de fichiers miniature. Avec Git, chaque fois que vous validez ou enregistrez l'état de votre projet, Git prend une photo de ce à quoi ressemblent tous vos fichiers à ce moment-là et entrepose une référence à cet instantané. Pour être efficace, si les fichiers n'ont pas changé, Git n'entrepose pas à nouveau le fichier, mais simplement un lien vers le fichier identique précédent qu'il a déjà entreposé. Git considère ses données plutôt comme un flux d'instantanés.

Il s'agit d'une distinction importante entre Git et presque tous les autres VCS. Cela oblige Git à reconsidérer presque tous les aspects du contrôle de version que la plupart des autres systèmes ont copiés de la génération précédente. Cela fait de Git un mini-système de fichiers avec des outils incroyablement puissants intégrés, plutôt qu'un simple VCS.

Presque toutes les opérations sont locales

La plupart des opérations dans Git n'ont besoin que de fichiers et de ressources locaux pour fonctionner - généralement aucune information n'est nécessaire à partir d'un autre ordinateur de votre réseau. Si vous êtes habitué à un CVCS où la plupart des opérations ont cette surcharge de latence réseau, cet aspect de Git vous fera penser que les dieux de la vitesse ont béni Git avec des pouvoirs surnaturels. Comme vous avez l'historique complet du projet directement sur votre disque local, la plupart des opérations semblent presque instantanées.

Par exemple, pour parcourir l'historique du projet, Git n'a pas besoin d'aller sur le serveur pour obtenir l'historique et l'afficher pour vous - il le lit simplement directement à partir de votre base de données locale. Cela signifie que vous voyez l'historique du projet presque instantanément. Si vous souhaitez voir les modifications introduites entre la version actuelle d'un fichier et le fichier d'il y a un mois, Git peut rechercher le fichier d'il y a un mois et effectuer un calcul de différence local, au lieu de devoir demander à un serveur distant de le faire ou d'extraire une version plus ancienne du fichier du serveur à distance pour le faire localement.

Cela signifie également qu'il y a très peu de choses que vous ne pouvez pas faire si vous êtes hors ligne ou sans VPN. Si vous montez dans un avion ou un train et que vous voulez faire un peu de travail, vous pouvez vous engager sur votre copie locale jusqu'à ce que vous obteniez une connexion réseau pour télécharger. Si vous rentrez chez vous et que vous ne parvenez pas à faire fonctionner correctement votre client VPN, vous pouvez toujours travailler. Dans de nombreux autres systèmes, cela est soit impossible, soit pénible. Dans Perforce, par exemple, vous ne pouvez pas faire grand-chose lorsque vous n'êtes pas connecté au serveur ; dans Subversion et CVS, vous pouvez modifier des fichiers, mais vous ne pouvez pas valider les modifications apportées à votre base de données (car votre base de données est hors ligne). Cela peut ne pas sembler être un problème majeur, mais vous pourriez être surpris de la grande différence que cela peut faire.

Git est intègre

Tout dans Git est contrôlé avant d'être entreposé et est ensuite référencé par cette somme de contrôle. Cela signifie qu'il est impossible de modifier le contenu d'un fichier ou d'un répertoire sans que Git ne le sache. Cette fonctionnalité est intégrée à Git aux niveaux les plus bas et fait partie intégrante de sa philosophie. Vous ne pouvez pas perdre d'informations en transit ou obtenir une corruption de fichier sans que Git ne puisse le détecter.

Le mécanisme que Git utilise pour ce contrôle est appelé hachage SHA-1. Il s'agit d'une chaîne de 40 caractères composée de caractères hexadécimaux (0 à 9 et a à f) et calculée en fonction du contenu d'une structure de fichier ou de répertoire dans Git. Un hachage SHA-1 ressemble à ceci :

Vous verrez ces valeurs de hachage partout dans Git car il les utilise beaucoup. En fait, Git entrepose tout dans sa base de données non pas par nom de fichier mais par valeur de hachage de son contenu.

Git ajoute généralement uniquement des données

Lorsque vous effectuez des actions dans Git, presque toutes ne font qu'ajouter des données à la base de données Git. Il est difficile de faire en sorte que le système fasse quelque chose n'étant pas annulable ou de lui faire effacer des données de quelque manière que ce soit. Comme avec n'importe quel VCS, vous pouvez perdre ou gâcher des modifications que vous n'avez pas encore validées, mais après avoir validé un instantané dans Git, il est très difficile de les perdre, surtout si vous poussez régulièrement votre base de données vers un autre dépôt.

Cela rend l'utilisation de Git agréable car nous savons que nous pouvons expérimenter sans risquer de tout gâcher.

Les trois états

Faites attention maintenant - voici la principale chose à retenir à propos de Git si vous voulez que le reste de votre processus d'apprentissage se déroule sans problème. Git a trois états principaux dans lesquels vos fichiers peuvent résider : modifié, mis en scène et validé :

• Modifié signifie que vous avez modifié le fichier mais que vous ne l'avez pas encore validé dans votre base de données.
• Mis en scène signifie que vous avez marqué un fichier modifié dans sa version actuelle pour l'insérer dans votre prochain instantané de validation.
• Validé signifie que les données sont stockées en toute sécurité dans votre base de données locale.

Cela nous amène aux trois sections principales d'un projet Git : l'arborescence de travail, la zone de préparation et le répertoire Git.

L'arbre de travail est une extraction unique d'une version du projet. Ces fichiers sont extraits de la base de données compressée dans le répertoire Git et placés sur le disque pour que vous puissiez les utiliser ou les modifier.

La zone de préparation est un fichier, généralement contenu dans votre répertoire Git, entreposant des informations sur ce qui sera inclus dans votre prochain commit. Son nom technique dans le jargon Git est «index», mais l'expression «zone de préparation» fonctionne tout aussi bien.

Le répertoire Git est l'endroit où Git entrepose les métadonnées et la base de données d'objets de votre projet. C'est la partie la plus importante de Git, et c'est ce qui est copié lorsque vous clonez un dépôt à partir d'un autre ordinateur.

Le flux de travail de base de Git se présente comme suit :

• Vous modifiez les fichiers dans votre arbre de travail.
• Vous préparez de manière sélective uniquement les modifications que vous souhaitez inclure dans votre prochain commit, ce qui ajoute uniquement ces modifications à la zone de préparation.
• Vous effectuez un commit, qui prend les fichiers tels qu'ils se trouvent dans la zone de préparation et stocke cet instantané de manière permanente dans votre répertoire Git.

Si une version particulière d'un fichier se trouve dans le répertoire Git, elle est considérée comme validée. Si elle a été modifiée et ajoutée à la zone de préparation, elle est préparée. Et si elle a été modifiée depuis son extraction mais n'a pas été préparée, elle est modifiée. Dans les bases de Git, vous en apprendrez plus sur ces états et sur la façon dont vous pouvez en tirer parti ou ignorer complètement la partie préparée.

La ligne de commande

Il existe de nombreuses façons d'utiliser Git. Il existe les outils de ligne de commande originaux et de nombreuses interfaces utilisateur graphiques aux capacités variées. D'une part, la ligne de commande est le seul endroit où vous pouvez exécuter toutes les commandes Git. La plupart des interfaces graphiques implémentent uniquement un sous-ensemble partiel des fonctionnalités de Git pour plus de simplicité. Si vous savez comment exécuter la version en ligne de commande, vous pouvez probablement aussi comprendre comment exécuter la version GUI, même si l'inverse n'est pas nécessairement vrai. De plus, bien que votre choix de client graphique soit une question de goût personnel, tous les utilisateurs auront les outils de ligne de commande installés et disponibles.

Nous nous attendons donc à ce que vous sachiez comment ouvrir Terminal sous macOS ou le prompt de commande ou PowerShell sous Windows.

Installer Git

Avant de commencer à utiliser Git, vous devez le rendre disponible sur votre ordinateur. Même s'il est déjà installé, il est probablement judicieux de le mettre à jour vers la dernière version. Vous pouvez l'installer sous forme de paquet ou via un autre installateur, ou télécharger le code source et le compiler vous-même.

Installation sur Linux

Si vous souhaitez installer les outils Git de base sur Linux via un installateur binaire, vous pouvez généralement le faire via l'outil de gestion de paquets fourni avec votre distribution. Si vous utilisez Fedora (ou toute autre distribution basée sur RPM, telle que RHEL ou CentOS), vous pouvez utiliser dnf :

Si vous utilisez une distribution basée sur Debian, telle qu'Ubuntu, essayez apt :

Pour plus d'options, vous trouverez des instructions d'installation sur plusieurs distributions de style Unix différentes sur le site Web de Git, à l'adresse https://git-scm.com/download/linux.

Installation sur macOS

Il existe plusieurs façons d'installer Git sur macOS. La plus simple est probablement d'installer les outils de ligne de commande Xcode. Sur Mavericks (10.9) ou supérieur, vous pouvez le faire simplement en essayant d'exécuter git à partir du terminal la toute première fois.

Si vous ne l'avez pas déjà installé, il vous sera demandé de l'installer.

Si vous souhaitez une version plus récente, vous pouvez également l'installer via un installateur binaire. Un installateur Git pour macOS est maintenu et disponible en téléchargement sur le site Web de Git, à l'adresse https://git-scm.com/download/mac.

Installation sur Windows

Il existe également plusieurs façons d'installer Git sur Windows. La version la plus officielle est disponible en téléchargement sur le site Web de Git. Rendez-vous simplement sur https://git-scm.com/download/win et le téléchargement démarrera automatiquement. Notez qu'il s'agit d'un projet appelé Git pour Windows, étant distinct de Git lui-même ; pour plus d'informations à ce sujet, rendez-vous sur https://gitforwindows.org.

Pour obtenir une installation automatisée, vous pouvez utiliser le paquet Git Chocolatey. Notez que le paquet Chocolatey est maintenu par la communauté.

Installation depuis la source

Certaines personnes trouveront peut-être utile d'installer Git depuis la source, car elles obtiendront la version la plus récente. Les installateurs binaires ont tendance à être un peu en retard, mais comme Git a mûri ces dernières années, cela a fait moins de différence.

Si vous souhaitez installer Git depuis la source, vous devez disposer des bibliothèques suivantes dont Git dépend : autotools, curl, zlib, openssl, expat et libiconv. Par exemple, si vous utilisez un système doté de dnf (comme Fedora) ou d'apt-get (comme un système basé sur Debian), vous pouvez utiliser l'une de ces commandes pour installer les dépendances minimales pour la compilation et l'installation des binaires Git :

Afin de pouvoir ajouter la documentation dans différents formats (doc, html, info), ces dépendances supplémentaires sont nécessaires :

Remarque : Les utilisateurs de RHEL et des dérivés de RHEL comme CentOS et Scientific Linux devront activer le référentiel EPEL pour télécharger le paquet docbook2X.

Si vous utilisez une distribution basée sur Debian (Debian/Ubuntu/Ubuntu-derivatives), vous avez également besoin du paquet install-info :

Si vous utilisez une distribution basée sur RPM (Fedora/RHEL/dérivés de RHEL), vous avez également besoin du paquet getopt (étant déjà installé sur une distribution basée sur Debian) :

De plus, si vous utilisez Fedora/RHEL/les dérivés de RHEL, vous devez procéder comme suit :

en raison des différences de noms binaires.

Lorsque vous avez toutes les dépendances nécessaires, vous pouvez aller de l'avant et récupérer la dernière version tarball étiquetée à plusieurs endroits. Vous pouvez l'obtenir via le site kernel.org, à l'adresse https://www.kernel.org/pub/software/scm/git, ou le miroir sur le site Web GitHub, à l'adresse https://github.com/git/git/tags. Il est généralement un peu plus clair quelle est la dernière version sur la page GitHub, mais la page kernel.org contient également des signatures de version si vous souhaitez vérifier votre téléchargement.

Ensuite, compilez et installez :

Une fois cela fait, vous pouvez également obtenir Git via Git lui-même pour les mises à jour :

Configuration initiale de Git

Maintenant que Git est installé sur votre système, vous souhaiterez effectuer quelques opérations pour personnaliser votre environnement Git. Vous ne devriez avoir à effectuer ces opérations qu'une seule fois sur un ordinateur donné; elles resteront en place entre les mises à niveau. Vous pouvez également les modifier à tout moment en exécutant à nouveau les commandes.

Git est fourni avec un outil appelé git config vous permettant d'obtenir et de définir des variables de configuration contrôlant tous les aspects de l'apparence et du fonctionnement de Git. Ces variables peuvent être entreposées à trois endroits différents :

• Fichier [path]/etc/gitconfig : contient des valeurs appliquées à chaque utilisateur du système et à tous ses dépôts. Si vous passez l'option --system à git config, il lit et écrit spécifiquement à partir de ce fichier. Comme il s'agit d'un fichier de configuration système, vous aurez besoin de privilèges d'administrateur ou de superutilisateur pour y apporter des modifications.
• Fichier ~/.gitconfig ou ~/.config/git/config : valeurs spécifiques à vous, l'utilisateur. Vous pouvez forcer Git à lire et à écrire dans ce fichier spécifiquement en passant l'option --global, et cela affecte tous les dépôts avec lesquels vous travaillez sur votre système.
• Fichier de configuration dans le répertoire Git (c'est-à-dire .git/config) du dépôt que vous utilisez actuellement : spécifique à ce dépôt unique. Vous pouvez forcer Git à lire et à écrire dans ce fichier avec l'option --local, mais c'est en fait la valeur par défaut. Sans surprise, vous devez être situé quelque part dans un dépôt Git pour que cette option fonctionne correctement.

Chaque niveau remplace les valeurs du niveau précédent, donc les valeurs dans .git/config prévalent sur celles dans [path]/etc/gitconfig.

Sur les systèmes Windows, Git recherche le fichier .gitconfig dans le répertoire $HOME (C:\Users\$USER pour la plupart des gens). Il recherche également [path]/etc/gitconfig, bien qu'il soit relatif à la racine MSys, correspondant à l'endroit où vous décidez d'installer Git sur votre système Windows lorsque vous exécutez le programme d'installation. Si vous utilisez la version 2.x ou ultérieure de Git pour Windows, il existe également un fichier de configuration au niveau du système dans C:\Documents and Settings\All Users\Application Data\Git\config sur Windows XP, et dans C:\ProgramData\Git\config sur Windows Vista et les versions plus récentes. Ce fichier de configuration ne peut être modifié que par git config -f <file> en tant qu'administrateur.

Vous pouvez afficher tous vos paramètres et leur provenance en utilisant :

Votre identité

La première chose à faire lorsque vous installez Git est de définir votre nom d'utilisateur et votre adresse de courriel. C'est important car chaque commit Git utilise ces informations, et elles sont intégrées de manière immuable dans les commits que vous commencez à créer :

Encore une fois, vous n'avez besoin de le faire qu'une seule fois si vous passez l'option --global, car Git utilisera alors toujours ces informations pour tout ce que vous ferez sur ce système. Si vous souhaitez remplacer cela par un nom ou une adresse de courriel différent pour des projets spécifiques, vous pouvez exécuter la commande sans l'option --global lorsque vous êtes dans ce projet.

De nombreux outils d'interface graphique vous aideront à le faire lors de leur première exécution.

Votre éditeur

Maintenant que votre identité est configurée, vous pouvez configurer l'éditeur de texte par défaut qui sera utilisé lorsque Git aura besoin que vous saisissiez un message. S'il n'est pas configuré, Git utilise l'éditeur par défaut de votre système.

Si vous souhaitez utiliser un autre éditeur de texte, tel qu'Emacs, vous pouvez procéder comme suit :

Sur un système Windows, si vous souhaitez utiliser un autre éditeur de texte, vous devez spécifier le chemin d'accès complet à son fichier exécutable. Cela peut être différent selon la manière dont votre éditeur est empaqueté.

Dans le cas de Notepad++, un éditeur de programmation populaire, vous souhaiterez probablement utiliser la version 32 bits, car au moment de la rédaction de cet page, la version 64 bits ne prend pas en charge tous les plugiciels. Si vous utilisez un système Windows 32 bits ou si vous disposez d'un éditeur 64 bits sur un système 64 bits, vous saisirez quelque chose comme ceci :

Remarque : Vim, Emacs et Notepad++ sont des éditeurs de texte populaires souvent utilisés par les développeurs sur des systèmes basés sur Unix comme Linux et macOS ou un système Windows. Si vous utilisez un autre éditeur ou une version 32 bits, veuillez trouver des instructions spécifiques sur la façon de configurer votre éditeur préféré avec Git dans les commandes git config core.editor.

Avertissement : vous risquez de vous retrouver dans un état vraiment déroutant si vous ne configurez pas votre éditeur de cette manière lorsque Git tente de le lancer. Un exemple sur un système Windows peut inclure une opération Git terminée prématurément lors d'une modification initiée par Git.

Votre nom de branche par défaut

Par défaut, Git crée une branche appelée master lorsque vous créez un nouveau dépôt avec git init. À partir de la version 2.28 de Git, vous pouvez définir un nom différent pour la branche initiale.

Pour définir main comme nom de branche par défaut, procédez comme suit :

Vérification de vos paramètres

Si vous souhaitez vérifier vos paramètres de configuration, vous pouvez utiliser la commande git config --list pour répertorier tous les paramètres que Git peut trouver à ce stade :

on obtiendra un résultat ressemblant à ceci :

Vous pouvez voir des clefs plusieurs fois, car Git lit la même clef à partir de fichiers différents ([path]/etc/gitconfig et ~/.gitconfig, par exemple). Dans ce cas, Git utilise la dernière valeur pour chaque clef unique qu'il voit.

Vous pouvez également vérifier ce que Git pense de la valeur d'une clef spécifique en tapant git config <key> :

on obtiendra un résultat ressemblant à ceci :

Remarque : Étant donné que Git peut lire la même valeur de variable de configuration à partir de plusieurs fichiers, il est possible que vous ayez une valeur inattendue pour l'une de ces valeurs et que vous ne sachiez pas pourquoi. Dans ce cas, vous pouvez interroger Git sur l'origine de cette valeur, et il vous indiquera quel fichier de configuration a eu le dernier mot dans la définition de cette valeur :

on obtiendra un résultat ressemblant à ceci :

Obtenir de l'aide

Si vous avez besoin d'aide lors de l'utilisation de Git, il existe trois manières équivalentes d'obtenir l'aide complète de la page de manuel (manpage) pour l'une des commandes Git :

Par exemple, vous pouvez obtenir l'aide de la page de manuel pour la commande git config en exécutant ceci :

Ces commandes sont pratiques car vous pouvez y accéder n'importe où, même hors ligne.

De plus, si vous n'avez pas besoin de l'aide complète de la page de manuel, mais que vous avez juste besoin d'un rappel rapide sur les options disponibles pour une commande Git, vous pouvez demander la sortie «help» plus concise avec l'option -h, comme dans :

on obtiendra un résultat ressemblant à ceci :