-
1. Démarrage rapide
-
2. Les bases de Git
-
3. Les branches avec Git
-
4. Git sur le serveur
- 4.1 Protocoles
- 4.2 Installation de Git sur un serveur
- 4.3 Génération des clés publiques SSH
- 4.4 Mise en place du serveur
- 4.5 Démon (Daemon) Git
- 4.6 HTTP intelligent
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Git hébergé
- 4.10 Résumé
-
5. Git distribué
-
6. GitHub
-
7. Utilitaires Git
- 7.1 Sélection des versions
- 7.2 Indexation interactive
- 7.3 Remisage et nettoyage
- 7.4 Signer votre travail
- 7.5 Recherche
- 7.6 Réécrire l’historique
- 7.7 Reset démystifié
- 7.8 Fusion avancée
- 7.9 Rerere
- 7.10 Déboguer avec Git
- 7.11 Sous-modules
- 7.12 Empaquetage (bundling)
- 7.13 Replace
- 7.14 Stockage des identifiants
- 7.15 Résumé
-
8. Personnalisation de Git
- 8.1 Configuration de Git
- 8.2 Attributs Git
- 8.3 Crochets Git
- 8.4 Exemple de politique gérée par Git
- 8.5 Résumé
-
9. Git et les autres systèmes
- 9.1 Git comme client
- 9.2 Migration vers Git
- 9.3 Résumé
-
10. Les tripes de Git
- 10.1 Plomberie et porcelaine
- 10.2 Les objets de Git
- 10.3 Références Git
- 10.4 Fichiers groupés
- 10.5 La refspec
- 10.6 Les protocoles de transfert
- 10.7 Maintenance et récupération de données
- 10.8 Les variables d’environnement
- 10.9 Résumé
-
A1. Annexe A: Git dans d’autres environnements
- A1.1 Interfaces graphiques
- A1.2 Git dans Visual Studio
- A1.3 Git dans Visual Studio Code
- A1.4 Git dans IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git dans Sublime Text
- A1.6 Git dans Bash
- A1.7 Git dans Zsh
- A1.8 Git dans PowerShell
- A1.9 Résumé
-
A2. Annexe B: Embarquer Git dans vos applications
- A2.1 Git en ligne de commande
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Commandes Git
- A3.1 Installation et configuration
- A3.2 Obtention et création des projets
- A3.3 Capture d’instantané basique
- A3.4 Création de branches et fusion
- A3.5 Partage et mise à jour de projets
- A3.6 Inspection et comparaison
- A3.7 Débogage
- A3.8 Patchs
- A3.9 Courriel
- A3.10 Systèmes externes
- A3.11 Administration
- A3.12 Commandes de plomberie
10.8 Les tripes de Git - Les variables d’environnement
Les variables d’environnement
Git s’exécute toujours dans un shell bash
, et utilise un certain nombre de variables d’environnement pour savoir comment se comporter.
Il est parfois pratique de savoir lesquelles, et la façon de les utiliser pour que Git se comporte comme vous le souhaitez.
Ceci n’est pas une liste exhaustive de toutes les variables d’environnement que Git utilise, mais nous allons voir les plus utiles.
Comportement général
Certains aspects du comportement général de Git en tant que programme dépend de variables d’environnement.
GIT_EXEC_PATH
détermine l’endroit où Git va chercher ses sous-programmes (comme git-commit
, git-diff
, et d’autres).
Vous pouvez vérifier le réglage actuel en lançant git --exec-path
.
HOME
n’est pas en général considérée comme modifiable (trop d’autres choses en dépendent), mais c’est l’endroit où Git va chercher le fichier de configuration général (global).
Si vous voulez une installation de Git vraiment portable, complète du point de vue de la configuration générale, vous pouvez surcharger HOME
dans le profil (profile).
PREFIX
est l’équivalent pour la configuration au niveau du système.
Git va chercher le fichier $PREFIX/etc/gitconfig
.
GIT_CONFIG_NOSYSTEM
, si elle est définie, invalide l’utilisation du fichier de configuration au niveau du système.
Cette variable est utile si la configuration système interfère avec vos commandes et que vous n’avez pas les privilèges pour la changer ou la supprimer.
GIT_PAGER
contrôle le programme que vous utilisez pour afficher les résultats sur plusieurs pages à la ligne de commande.
Si elle n’est pas définie, Git utilisera PAGER
à la place.
GIT_EDITOR
est l’éditeur lancé par Git quand l’utilisateur doit taper du texte (un message de commit par exemple).
Si elle n’est pas définie, Git utilisera EDITOR
.
Les emplacements du dépôt
Git utilise plusieurs variables d’environnement pour déterminer comment interagir avec le dépôt courant.
GIT_DIR
est l’emplacement du répertoire .git
.
S’il n’est pas spécifié, Git remonte l’arbre des répertoires jusqu’à ce qu’il arrive à ~
ou bien /
, en cherchant un répertoire .git
à chaque étape.
GIT_CEILING_DIRECTORIES
contrôle le comportement de Git pendant la recherche d’un répertoire .git
.
Si vous êtes sur des répertoires qui se chargent lentement (par exemple sur une bande magnétique ou à travers une connexion réseau lente), vous pouvez souhaiter que Git s’arrête plus tôt qu’il ne le ferait habituellemnt, surtout si Git est appelé à la construction de votre appel shell (prompt).
GIT_WORK_TREE
est l’emplacement de la racine du répertoire de travail pour un dépôt non nu.
Si cette variable n’est pas spécifiée, c’est le répertoire parent de $GIT_DIR
qui est utilisé.
GIT_INDEX_FILE
est le chemin du fichier d’index (uniquement pour les dépôts non nus).
GIT_OBJECT_DIRECTORY
peut être utilisé pour spécifier l’emplacement du répertoire qui se trouve habituellement à .git/objects
.
GIT_ALTERNATE_OBJECT_DIRECTORIES
est une liste séparée par des « : » (formattée comme ceci : /rep/un:/rep/deux:…
) qui dit à Git où trouver les objets s’ils ne sont pas dans GIT_OBJECT_DIRECTORY
.
S’il vous arrive d’avoir beaucoup de projets avec des gros fichiers ayant exactement le même contenu, cette variable peut vous éviter d’en garder trop de copies.
Pathspecs
Une "pathspec" fait référence à la façon dont on spécifie les chemins dans Git, y compris l’utilisation des jokers.
Ils sont utilisés dans le fichier .gitignore
, mais également à la ligne de commande (git add \*.c
).
GIT_GLOB_PATHSPECS
et GIT_NOGLOB_PATHSPECS
contrôlent le comportement par défaut des jokers dans les pathspecs.
Si GIT_GLOB_PATHSPECS
vaut 1, les caractères jokers agissent comme des jokers (ce qui est le comportement par défaut) ; si GIT_NOGLOB_PATHSPECS
vaut 1, les caractères jokers ne correspondent qu’à eux-même, ce qui veut dire que quelque chose comme *.c
ne correspondrait qu’à un fichier nommé « \*.c », et non pas tout fichier dont le nom se termine par .c
.
Vous pouvez surcharger ce comportement pour certains cas en faisant commencer la pathspec par :(glob)
pour utiliser le joker, ou bien :(literal)
pour une correspondance stricte, comme dans :(glob)\*.c
.
GIT_LITERAL_PATHSPECS
empêche ces deux comportements ; aucun joker ne fonctionnera, et les préfixes de surcharge seront également inopérants.
GIT_ICASE_PATHSPECS
rend toutes les pathspecs insensibles à la casse.
Création de commits
La création finale d’un objet Git commit est habituellement faite par git-commit-tree
, qui utilise les variables d’environnement suivantes comme première source d’information, se repliant sur les valeurs de configuration seulement si celles-ci ne sont pas présentes :
GIT_AUTHOR_NAME
est le nom lisible par un humain dans le champ « Auteur » (author).
GIT_AUTHOR_EMAIL
est l’adresse de courriel pour le champ « Auteur ».
GIT_AUTHOR_DATE
est l’horodatage utilisé pourle champ « Auteur ».
GIT_COMMITTER_NAME
définit le nom humain pour le champ « Validateur » (commiter).
GIT_COMMITTER_EMAIL
est l’adresse de courriel pour le champ « Validateur ».
GIT_COMMITTER_DATE
est utilisé pour l’horodatage dans le champ « Validateur ».
EMAIL
est l’adresse de courriel de repli pour le cas où la valeur de configuration user.email
n’est pas définie.
Si celle-ci n’est pas définie, Git se replie sur les noms d’utilisateur système et d’hôte.
Travail sur le réseau
Git utilise la bibliothèque curl
pour effectuer des opérations sur HTTP, ainsi GIT_CURL_VERBOSE
demande à Git d’émettre tous les messages générés par cette bibliothèque.
C’est similaire à curl -v
en ligne de commande.
GIT_SSL_NO_VERIFY
demande à Git de ne pas vérifier les certificats SSL.
Cela peut être parfois nécessaire si vous utilisez des certificats auto-signés pour servir des dépôts Git sur HTTPS, ou si vous êtes au milieu de l’installation d’un serveur Git mais n’avez pas encore installé un certificat complet.
Si le taux de données d’une opération HTTP est plus basse que GIT_HTTP_LOW_SPEED_LIMIT
octets par seconde pendant plus longtemps que GIT_HTTP_LOW_SPEED_TIME
secondes, Git annulera cette opération.
Ces valeurs surchargent les valeurs de configuration http.lowSpeedLimit
et http.lowSpeedTime
.
GIT_HTTP_USER_AGENT
définit la chaîne d’agent utilisateur utilisée par Git quand il communique sur HTTP.
La valeur par défaut est quelque chose comme git/2.0.0
.
Visualisation des différences et Fusion
GIT_DIFF_OPTS
est un terme un peu inapproprié.
Les seules valeurs valides sont -u<n>
ou --unified=<n>
, qui contrôlent le nombre de lignes de contexte affichées dans une commande git diff
.
GIT_EXTERNAL_DIFF
est utilisée comme une surcharge de la valeur de configuration diff.external
.
Si elle est définie, Git invoquera ce programme quand git diff
sera invoquée.
GIT_DIFF_PATH_COUNTER
et GIT_DIFF_PATH_TOTAL
sont utiles à l’intérieur du programme spécifié par GIT_EXTERNAL_DIFF
ou diff.external
.
Le premier represente le fichier de la série dont on est en train de visualiser les différences (en commençant par 1), et le dernier est le nombre total de fichiers dans le lot.
GIT_MERGE_VERBOSITY
contrôle la sortie pour la stratégie de fusion récursive.
Les valeurs admises sont les suivantes :
-
0 ne sort rien, sauf éventuellement un seul message d’erreur.
-
1 ne montre que les conflits.
-
2 montre aussi les modifications de fichier.
-
3 montre quand les fichiers sont sautés parce qu’ils n’ont pas changé.
-
4 montre tous les chemins qui sont en train d’être traités.
-
5 et au-delà montrent des informations détaillées de débogage.
La valeur par défaut est 2.
Débogage
Vous voulez vraiment savoir de quoi Git est capable ? Git comprend un ensemble de traces assez complet, et tout ce que vous avez à faire est de les activer. Les valeurs possibles de ces variables sont les suivantes :
-
« true », « 1 » ou « 2 » – la catégorie de trace est écrite sur la sortie d’erreur standard (stderr).
-
Un chemin absolu commençant par
/
– la sortie de trace sera écrite dans ce fichier.
GIT_TRACE
contrôle les traces générales, qui ne rentrent dans aucune catégorie spécifique.
Cela inclut le développement des alias et la délégation aux autres sous-programmes.
$ GIT_TRACE=true git lga
20:12:49.877982 git.c:554 trace: exec: 'git-lga'
20:12:49.878369 run-command.c:341 trace: run_command: 'git-lga'
20:12:49.879529 git.c:282 trace: alias expansion: lga => 'log' '--graph' '--pretty=oneline' '--abbrev-commit' '--decorate' '--all'
20:12:49.879885 git.c:349 trace: built-in: git 'log' '--graph' '--pretty=oneline' '--abbrev-commit' '--decorate' '--all'
20:12:49.899217 run-command.c:341 trace: run_command: 'less'
20:12:49.899675 run-command.c:192 trace: exec: 'less'
GIT_TRACE_PACK_ACCESS
contrôle le traçage d’accès aux fichiers groupés.
Le premier champ est le fichier groupé auquel on est en train d’accéder, le second est le décalage dans ce fichier :
$ GIT_TRACE_PACK_ACCESS=true git status
20:10:12.081397 sha1_file.c:2088 .git/objects/pack/pack-c3fa...291e.pack 12
20:10:12.081886 sha1_file.c:2088 .git/objects/pack/pack-c3fa...291e.pack 34662
20:10:12.082115 sha1_file.c:2088 .git/objects/pack/pack-c3fa...291e.pack 35175
# […]
20:10:12.087398 sha1_file.c:2088 .git/objects/pack/pack-e80e...e3d2.pack 56914983
20:10:12.087419 sha1_file.c:2088 .git/objects/pack/pack-e80e...e3d2.pack 14303666
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
GIT_TRACE_PACKET
permet le traçage au niveau paquet pour les opérations sur le réseau.
$ GIT_TRACE_PACKET=true git ls-remote origin
20:15:14.867043 pkt-line.c:46 packet: git< # service=git-upload-pack
20:15:14.867071 pkt-line.c:46 packet: git< 0000
20:15:14.867079 pkt-line.c:46 packet: git< 97b8860c071898d9e162678ea1035a8ced2f8b1f HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed no-done symref=HEAD:refs/heads/master agent=git/2.0.4
20:15:14.867088 pkt-line.c:46 packet: git< 0f20ae29889d61f2e93ae00fd34f1cdb53285702 refs/heads/ab/add-interactive-show-diff-func-name
20:15:14.867094 pkt-line.c:46 packet: git< 36dc827bc9d17f80ed4f326de21247a5d1341fbc refs/heads/ah/doc-gitk-config
# […]
GIT_TRACE_PERFORMANCE
contrôle la journalisation d’information de performance.
La sortie montre combien de temps prend chaque invocation particulère de Git.
$ GIT_TRACE_PERFORMANCE=true git gc
20:18:19.499676 trace.c:414 performance: 0.374835000 s: git command: 'git' 'pack-refs' '--all' '--prune'
20:18:19.845585 trace.c:414 performance: 0.343020000 s: git command: 'git' 'reflog' 'expire' '--all'
Counting objects: 170994, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (43413/43413), done.
Writing objects: 100% (170994/170994), done.
Total 170994 (delta 126176), reused 170524 (delta 125706)
20:18:23.567927 trace.c:414 performance: 3.715349000 s: git command: 'git' 'pack-objects' '--keep-true-parents' '--honor-pack-keep' '--non-empty' '--all' '--reflog' '--unpack-unreachable=2.weeks.ago' '--local' '--delta-base-offset' '.git/objects/pack/.tmp-49190-pack'
20:18:23.584728 trace.c:414 performance: 0.000910000 s: git command: 'git' 'prune-packed'
20:18:23.605218 trace.c:414 performance: 0.017972000 s: git command: 'git' 'update-server-info'
20:18:23.606342 trace.c:414 performance: 3.756312000 s: git command: 'git' 'repack' '-d' '-l' '-A' '--unpack-unreachable=2.weeks.ago'
Checking connectivity: 170994, done.
20:18:25.225424 trace.c:414 performance: 1.616423000 s: git command: 'git' 'prune' '--expire' '2.weeks.ago'
20:18:25.232403 trace.c:414 performance: 0.001051000 s: git command: 'git' 'rerere' 'gc'
20:18:25.233159 trace.c:414 performance: 6.112217000 s: git command: 'git' 'gc'
GIT_TRACE_SETUP
montre des informations sur ce que Git découvre sur le dépôt et l’environnement avec lequel il interagit.
$ GIT_TRACE_SETUP=true git status
20:19:47.086765 trace.c:315 setup: git_dir: .git
20:19:47.087184 trace.c:316 setup: worktree: /Users/ben/src/git
20:19:47.087191 trace.c:317 setup: cwd: /Users/ben/src/git
20:19:47.087194 trace.c:318 setup: prefix: (null)
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Divers
GIT_SSH
, si spécifié, est un programme qui est invoqué à la place de ssh
quand Git essaie de se connecter à un hôte SSH.
Il est invoqué comme $GIT_SSH [username@]host [-p <port>] <command>
.
Notez que ce n’est pas le moyen le plus facile de personnaliser la façon dont ssh est invoqué ; il ne prendra pas en compte des paramètres supplémentaires en ligne de commande, donc vous devriez écrire un script l’enveloppant et faire pointer GIT_SSH
dessus.
Il est sans doute plus facile d’utiliser le fichier ~/.ssh/config
pour cela.
GIT_ASKPASS
est une surcharge pour la valeur de configuration core.askpass
.
C’est le programme invoqué lorsque Git à besoin de demander ses identifiants à l’utilisateur, qui peut s’attendre à un texte comme argument en ligne de commande, et qui devrait retourner la réponse sur la sortie standard (stdout
).
(Consultez Stockage des identifiants pour plus d’information sur ce sous-système.)
GIT_NAMESPACE
contrôle l’accès des références cloisonnées dans des espaces de nom, et est équivalent à l’option --namespace
.
C’est surtout utile côté serveur, où vous pourriez vouloir stocker plusieurs bifurcations (forks) d’un seul dépôt dans un seul dépôt, en gardant seulement les références séparées.
GIT_FLUSH
peut être utilisée pour forcer Git à utiliser des entrées/sorties non mises en mémoire tampon (buffer) quand il écrit progressivement dans la sortie standard.
Une valeur de 1 fait que Git évacue (flush) plus souvent, une valeur de 0 fait que la sortie est mise en mémoire tampon.
La valeur par défaut (si la variable n’est pas définie) est à choisir selon un plan approprié de mise en mémoire tampon en fonction de l’activité et du mode de sortie.
GIT_REFLOG_ACTION
vous permet de spécifier le texte descriptif écrit dans le reflog
.
Voici un exemple :
$ GIT_REFLOG_ACTION="my action" git commit --allow-empty -m 'my message'
[master 9e3d55a] my message
$ git reflog -1
9e3d55a HEAD@{0}: my action: my message