-
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
8.1 Personnalisation de Git - Configuration de Git
Jusqu’ici, nous avons traité les bases du fonctionnement et de l’utilisation de Git et introduit un certain nombre d’outils fournis par Git pour travailler plus facilement et plus efficacement. Dans ce chapitre, nous aborderons quelques opérations permettant d’utiliser Git de manière plus personnalisée en vous présentant quelques paramètres de configuration importants et le système d’interceptions. Grâce à ces outils, il devient enfantin de faire fonctionner Git exactement comme vous, votre société ou votre communauté en avez besoin.
Configuration de Git
Comme vous avez pu l’entrevoir dans Démarrage rapide, vous pouvez spécifier les paramètres de configuration de Git avec la commande git config
.
Une des premières choses que vous avez faites a été de paramétrer votre nom et votre adresse de courriel :
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
À présent, vous allez apprendre quelques-unes des options similaires les plus intéressantes pour paramétrer votre usage de Git.
Vous avez vu des détails de configuration simple de Git au premier chapitre, mais nous allons les réviser.
Git utilise une série de fichiers de configuration pour déterminer son comportement selon votre personnalisation.
Le premier endroit que Git visite est le fichier /etc/gitconfig
qui contient des valeurs pour tous les utilisateurs du système et tous leurs dépôts.
Si vous passez l’option --system
à git config
, il lit et écrit ce fichier.
L’endroit suivant visité par Git est le fichier ~/.gitconfig
qui est spécifique à chaque utilisateur.
Vous pouvez faire lire et écrire Git dans ce fichier au moyen de l’option --global
.
Enfin, Git recherche des valeurs de configuration dans le fichier de configuration du répertoire Git (.git/config
) du dépôt en cours d’utilisation.
Ces valeurs sont spécifiques à un unique dépôt.
Chaque niveau surcharge le niveau précédent, ce qui signifie que les valeurs dans .git/config
écrasent celles dans /etc/gitconfig
.
Note
|
Ces fichiers de configuration Git sont des fichiers texte, donc vous pouvez positionner ces valeurs manuellement en éditant le fichier et en utilisant la syntaxe correcte, mais il reste généralement plus facile de lancer la commande |
Configuration de base d’un client
Les options de configuration reconnues par Git tombent dans deux catégories : côté client et côté serveur. La grande majorité se situe côté client pour coller à vos préférences personnelles de travail. Parmi les tonnes d’options disponibles, seules les plus communes ou affectant significativement la manière de travailler seront couvertes. De nombreuses options ne s’avèrent utiles qu’en de rares cas et ne seront pas traitées. Pour voir la liste de toutes les options que votre version de Git reconnaît, vous pouvez lancer :
$ man git-config
Cette commande affiche toutes les options disponibles avec quelques détails. Vous pouvez aussi trouver des informations de référence sur https://git-scm.com/docs/git-config.html.
core.editor
Par défaut, Git utilise votre éditeur par défaut ($VISUAL
ou $EDITOR
) ou se replie sur l’éditeur Vi pour la création et l’édition des messages de validation et d’étiquetage.
Pour modifier ce programme par défaut pour un autre, vous pouvez utiliser le paramètre core.editor
:
$ git config --global core.editor emacs
Maintenant, quel que soit votre éditeur par défaut, Git démarrera Emacs pour éditer les messages.
commit.template
Si vous réglez ceci sur le chemin d’un fichier sur votre système, Git utilisera ce fichier comme message par défaut quand vous validez. L’intérêt de créer un modèle de message de validation est que vous pouvez l’utiliser pour vous rappeler (ou rappeler aux autres) du format et du style corrects pour créer un message de validation.
Par exemple, supposons que vous créiez un fichier modèle dans $HOME/.gitmessage.txt
qui ressemble à ceci :
ligne de sujet (essayer de la garder sous 50 caractères)
description multiligne du commit
ajouter tous les détails que vous voulez
[ticket: X]
Notez comment ce modèle de validation rappelle au validateur de conserver une ligne de titre courte (pour coller avec la sortie de git log --oneline
), et d’ajouter de plus amples détails dessous, et de faire référence à un incident ou un numéro de ticket dans un système de suivi de ticket s’il existe.
Pour indiquer à Git de l’utiliser pour le message par défaut qui apparaîtra dans votre éditeur quand vous lancerez git commit
, réglez le paramètre de configuration commit.template
:
$ git config --global commit.template ~/.gitmessage.txt
$ git commit
Ainsi, votre éditeur ouvrira quelque chose ressemblant à ceci comme modèle de message de validation :
ligne de sujet
description
[ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C
Si vous avez une règle de messages de validation, placez un modèle de cette règle sur votre système et configurez Git pour qu’il l’utilise par défaut, cela améliorera les chances que cette règle soit effectivement suivie.
core.pager
Le paramètre core.pager
détermine quel pager est utilisé lorsque des pages de Git sont émises, par exemple lors d’un log
ou d’un diff
.
Vous pouvez le fixer à more
ou à votre pager favori (par défaut, il vaut less
) ou vous pouvez le désactiver en fixant sa valeur à une chaîne vide :
$ git config --global core.pager ''
Si vous lancez cela, Git affichera la totalité du résultat de toutes les commandes d’une traite, quelle que soit sa longueur.
user.signingkey
Si vous faites des étiquettes annotées signées (comme décrit dans Signer votre travail), simplifiez-vous la vie en définissant votre clé GPG de signature en paramètre de configuration. Définissez votre ID de clé ainsi :
$ git config --global user.signingkey <gpg-key-id>
Maintenant, vous pouvez signer vos étiquettes sans devoir spécifier votre clé à chaque fois que vous utilisez la commande git tag
:
$ git tag -s <nom-étiquette>
core.excludesfile
Comme décrit dans Ignorer des fichiers, vous pouvez ajouter des patrons dans le fichier .gitignore
de votre projet pour indiquer à Git de ne pas considérer certains fichiers comme non suivis ou pour éviter de les indexer lorsque vous lancez git add
sur eux.
Mais vous pouvez souhaiter dans quelques cas ignorer certains fichiers dans tous vos dépôts.
Si votre ordinateur utilise macOS, vous connaissez certainement les fichiers .DS_Store
.
Si votre éditeur préféré est Emacs ou Vim, vous connaissez sûrement aussi les fichiers qui se terminent par ~
ou .swp
.
Cette option vous permet d’écrire un fichier .gitignore
global.
Si vous créez un fichier ~/.gitignore_global
contenant ceci :
*~
.*.swp
.DS_Store
et que vous lancez git config --global core.excludesfile ~/.gitignore_global
, Git ne vous importunera plus avec ces fichiers.
help.autocorrect
Si vous avez fait une faute de frappe en tapant une commande Git, il vous affiche quelque chose comme :
$ git chekcout master
git : 'chekcout' n'est pas une commande git. Voir 'git --help'.
Vouliez-vous dire cela ?
checkout
Git essaie de deviner ce que vous avez voulu dire, mais continue de refuser de le faire.
Si vous positionnez le paramètre help.autocorrect
à 1, Git va réellement lancer cette commande à votre place :
$ git chekcout master
ATTENTION : vous avez invoqué une commande Git nommée 'chekcout' qui n'existe pas.
Continuons en supposant que vous avez voulu dire 'checkout'
dans 0.1 secondes automatiquement...
Notez l’histoire des « 0.1 secondes ».
help.autocorrect
est un fait un entier qui représente des dixièmes de seconde.
Ainsi, si vous le réglez à 50, Git vous laissera 5 secondes pour changer d’avis avant de lancer la commande qu’il aura devinée.
Couleurs dans Git
Git sait coloriser ses affichages dans votre terminal, ce qui peut faciliter le parcours visuel des résultats. Un certain nombre d’options peuvent vous aider à régler la colorisation à votre goût.
color.ui
Git colorise automatiquement la plupart de ses affichages mais il existe une option globale pour désactiver ce comportement. Pour désactiver toute la colorisation par défaut, lancez ceci :
$ git config --global color.ui false
La valeur par défaut est auto
, ce qui colorise la sortie lorsque celle-ci est destinée à un terminal, mais élimine les codes de contrôle de couleur quand la sortie est redirigée dans un fichier ou l’entrée d’une autre commande.
Vous pouvez aussi la régler à always
(toujours) pour activer la colorisation en permanence.
C’est une option rarement utile.
Dans la plupart des cas, si vous tenez vraiment à coloriser vos sorties redirigées, vous pourrez passer le drapeau --color
à la commande Git pour la forcer à utiliser les codes de couleur.
Le réglage par défaut est donc le plus utilisé.
color.*
Si vous souhaitez être plus spécifique concernant les commandes colorisées, Git propose des paramètres de colorisation par action.
Chacun peut être fixé à true
, false
ou always
.
color.branch color.diff color.interactive color.status
De plus, chacun d’entre eux dispose d’un sous-ensemble de paramètres qui permettent de surcharger les couleurs pour des parties des affichages. Par exemple, pour régler les couleurs de méta-informations du diff avec une écriture en bleu gras (bold en anglais) sur fond noir :
$ git config --global color.diff.meta "blue black bold"
La couleur peut prendre les valeurs suivantes : normal, black, red, green, yellow, blue, magenta, cyan ou white. Si vous souhaitez ajouter un attribut de casse, les valeurs disponibles sont bold (gras), dim (léger), ul (underlined, souligné), blink (clignotant) et reverse (inversé).
Outils externes de fusion et de différence
Bien que Git ait une implémentation interne de diff que vous avez déjà utilisée, vous pouvez sélectionner à la place un outil externe. Vous pouvez aussi sélectionner un outil graphique pour la fusion et la résolution de conflit au lieu de devoir résoudre les conflits manuellement. Je démontrerai le paramétrage avec Perforce Merge Tool (P4Merge) pour visualiser vos différences et résoudre vos fusions parce que c’est un outil graphique agréable et gratuit.
Si vous voulez l’essayer, P4Merge fonctionne sur tous les principaux systèmes d’exploitation.
Dans cet exemple, je vais utiliser la forme des chemins usitée sur macOS et Linux.
Pour Windows, vous devrez changer /usr/local/bin
en un chemin d’exécution d’un programme de votre environnement.
Pour commencer, téléchargez P4Merge depuis https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools.
Ensuite, il faudra mettre en place un script d’enrobage pour lancer les commandes.
Je vais utiliser le chemin macOS pour l’exécutable ; dans d’autres systèmes, il résidera où votre binaire p4merge
a été installé.
Créez un script enveloppe nommé extMerge
qui appelle votre binaire avec tous les arguments fournis :
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*
L’enveloppe diff s’assure que sept arguments ont été fournis et en passe deux à votre script de fusion. Par défaut, Git passe au programme de diff les arguments suivants :
chemin ancien-fichier ancien-hex ancien-mode nouveau-fichier nouveau-hex nouveau-mode
Comme seuls les arguments ancien-fichier
et nouveau-fichier
sont nécessaires, vous utilisez le script d’enveloppe pour passer ceux dont vous avez besoin.
$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
Vous devez aussi vous assurer que ces fichiers sont exécutables :
$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff
À présent, vous pouvez régler votre fichier de configuration pour utiliser vos outils personnalisés de résolution de fusion et de différence.
Pour cela, il faut un certain nombre de personnalisations : merge.tool
pour indiquer à Git quelle stratégie utiliser, mergetool.<tool>.cmd
pour spécifier comment lancer cette commande, mergetool.<tool>.trustExitCode
pour indiquer à Git si le code de sortie du programme indique une résolution de fusion réussie ou non et diff.external
pour indiquer à Git quelle commande lancer pour les différences.
Ainsi, vous pouvez lancer les quatre commandes :
$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"'
$ git config --global mergetool.trustExitCode false
$ git config --global diff.external extDiff
ou vous pouvez éditer votre fichier ~/.gitconfig
pour y ajouter ces lignes :
[merge]
tool = extMerge
[mergetool "extMerge"]
cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
trustExitCode = false
[diff]
external = extDiff
Après avoir réglé tout ceci, si vous lancez des commandes de diff telles que celle-ci :
$ git diff 32d1776b1^ 32d1776b1
Au lieu d’obtenir la sortie du diff dans le terminal, Git lance P4Merge, ce qui ressemble à ceci :
![P4Merge.](png/p4merge.png)
Si vous essayez de fusionner deux branches et créez des conflits de fusion, vous pouvez lancer la commande git mergetool
qui démarrera P4Merge pour vous laisser résoudre les conflits au moyen d’un outil graphique.
Le point agréable avec cette méthode d’enveloppe est que vous pouvez changer facilement d’outils de diff et de fusion.
Par exemple, pour changer vos outils extDiff
et extMerge
pour une utilisation de l’outil KDiff3, il vous suffit d’éditer le fichier extMerge
:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
À présent, Git va utiliser l’outil KDiff3 pour visualiser les différences et résoudre les conflits de fusion.
Git est livré préréglé avec un certain nombre d’autres outils de résolution de fusion pour vous éviter d’avoir à gérer la configuration cmd
.
Pour obtenir une liste des outils qu’il supporte, essayez ceci :
$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
emerge
gvimdiff
gvimdiff2
opendiff
p4merge
vimdiff
vimdiff2
The following tools are valid, but not currently available:
araxis
bc3
codecompare
deltawalker
diffmerge
diffuse
ecmerge
kdiff3
meld
tkdiff
tortoisemerge
xxdiff
Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.
Si KDiff3 ne vous intéresse pas pour gérer les différences mais seulement pour la résolution de fusion et qu’il est présent dans votre chemin d’exécution, vous pouvez lancer :
$ git config --global merge.tool kdiff3
Si vous lancez ceci au lieu de modifier les fichiers extMerge
ou extDiff
, Git utilisera KDiff3 pour les résolutions de fusion et l’outil diff normal de Git pour les différences.
Formatage et espaces blancs
Les problèmes de formatage et de blancs sont parmi les plus subtils et frustrants que les développeurs rencontrent lorsqu’ils collaborent, spécifiquement d’une plate-forme à l’autre. Il est très facile d’introduire des modifications subtiles de blancs lors de soumission de patchs ou d’autres modes de collaboration, car les éditeurs de texte les insèrent silencieusement ou les programmeurs Windows ajoutent des retours chariot à la fin des lignes qu’ils modifient. Git dispose de quelques options de configuration pour traiter ces problèmes.
core.autocrlf
Si vous programmez vous-même sous Windows ou si vous utilisez un autre système d’exploitation mais devez travailler avec des personnes travaillant sous Windows, vous rencontrerez à un moment ou à un autre des problèmes de caractères de fin de ligne. Ceci est dû au fait que Windows utilise pour marquer les fins de ligne dans ses fichiers un caractère « retour chariot » (carriage return, CR) suivi d’un caractère « saut de ligne » (line feed, LF), tandis que macOS et Linux utilisent seulement le caractère « saut de ligne ». C’est un cas subtil mais incroyablement ennuyeux de problème généré par la collaboration inter plate-forme.
Git peut gérer ce cas en convertissant automatiquement les fins de ligne CRLF en LF lorsque vous validez, et inversement lorsqu’il extrait des fichiers sur votre système.
Vous pouvez activer cette fonctionnalité au moyen du paramètre core.autocrlf
.
Si vous avez une machine Windows, positionnez-le à true
.
Git convertira les fins de ligne de LF en CRLF lorsque vous extrairez votre code :
$ git config --global core.autocrlf true
Si vous utilisez un système Linux ou macOS qui utilise les fins de ligne LF, vous ne souhaitez sûrement pas que Git les convertisse automatiquement lorsque vous extrayez des fichiers.
Cependant, si un fichier contenant des CRLF est accidentellement introduit en gestion de versions, vous souhaitez que Git le corrige.
Vous pouvez indiquer à Git de convertir CRLF en LF lors de la validation mais pas dans l’autre sens en fixant core.autocrlf
à input
:
$ git config --global core.autocrlf input
Ce réglage devrait donner des fins de ligne en CRLF lors d’extraction sous Windows mais en LF sous macOS et Linux et dans le dépôt.
Si vous êtes un programmeur Windows gérant un projet spécifique à Windows, vous pouvez désactiver cette fonctionnalité et forcer l’enregistrement des « retour chariot » dans le dépôt en réglant la valeur du paramètre à false
:
$ git config --global core.autocrlf false
core.whitespace
Git est paramétré par défaut pour détecter et corriger certains problèmes de blancs. Il peut rechercher six problèmes de blancs de base. La correction de trois problèmes est activée par défaut et peut être désactivée et celle des trois autres n’est pas activée par défaut mais peut être activée.
Les trois activées par défaut sont blank-at-eol
qui détecte les espaces en fin de ligne, blank-at-eof
qui détecte les espaces en fin de fichier et space-before-tab
qui recherche les espaces avant les tabulations au début d’une ligne.
Les trois autres qui sont désactivées par défaut mais peuvent être activées sont indent-with-non-tab
qui recherche des lignes qui commencent par des espaces au lieu de tabulations (contrôlé par l’option tabwidth
), tab-in-indent
qui recherche les tabulations dans la portion d’indentation d’une ligne et cr-at-eol
qui indique à Git que les « retour chariot » en fin de ligne sont acceptés.
Vous pouvez indiquer à Git quelle correction vous voulez activer en fixant core.whitespace
avec les valeurs que vous voulez ou non, séparées par des virgules.
Vous pouvez désactiver des réglages en les éliminant de la chaîne de paramétrage ou en les préfixant avec un -
.
Par exemple, si vous souhaitez activer tout sauf space-before-tab
, vous pouvez lancer ceci (avec trailing-space
comme raccourci pour à la fois blank-at-eol
et blank-at-eof
) :
$ git config --global core.whitespace \
trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol
Ou vous pouvez spécifier seulement la partie personnalisée :
$ git config --global core.whitespace \
-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol
Git va détecter ces problèmes quand vous lancez une commande git diff
et essayer de les coloriser pour vous permettre de les régler avant de valider.
Il utilisera aussi ces paramètres pour vous aider quand vous appliquerez des patchs avec git apply
.
Quand vous appliquez des patchs, vous pouvez paramétrer Git pour qu’il vous avertisse s’il doit appliquer des patchs qui présentent les défauts de blancs :
$ git apply --whitespace=warn <rustine>
Ou vous pouvez indiquer à Git d’essayer de corriger automatiquement le problème avant d’appliquer le patch :
$ git apply --whitespace=fix <rustine>
Ces options s’appliquent aussi à git rebase
.
Si vous avez validé avec des problèmes de blancs mais n’avez pas encore poussé en amont, vous pouvez lancer un rebase
avec l’option --whitespace=fix
pour faire corriger à Git les erreurs de blancs pendant qu’il réécrit les patchs.
Configuration du serveur
Il n’y a pas autant d’options de configuration de Git côté serveur, mais en voici quelques unes intéressantes dont il est utile de prendre note.
receive.fsckObjects
Git est capable de vérifier que tous les objets reçus pendant une poussée correspondent à leur somme de contrôle SHA-1 et qu’ils pointent sur des objets valides.
Cependant, il ne le fait pas par défaut sur chaque poussée.
C’est une opération relativement lourde qui peut énormément allonger les poussées selon la taille du dépôt ou de la poussée.
Si vous voulez que Git vérifie la cohérence des objets à chaque poussée, vous pouvez le forcer en fixant le paramètre receive.fsckObjects
à true
:
$ git config --system receive.fsckObjects true
Maintenant, Git va vérifier l’intégrité de votre dépôt avant que chaque poussée ne soit acceptée pour s’assurer que des clients défectueux (ou malicieux) n’introduisent pas des données corrompues.
receive.denyNonFastForwards
Si vous rebasez des commits que vous avez déjà poussés, puis essayez de pousser à nouveau, ou inversement, si vous essayez de pousser un commit sur une branche distante qui ne contient pas le commit sur lequel la branche distante pointe, votre essai échouera.
C’est généralement une bonne politique, mais dans le cas d’un rebasage, vous pouvez décider que vous savez ce que vous faites et forcer la mise à jour de la branche distante en ajoutant l’option -f
à votre commande.
Pour désactiver la possibilité de forcer la mise à jour des branches distantes autres qu’en avance rapide, réglez receive.denyNonFastForwards
:
$ git config --system receive.denyNonFastForwards true
Un autre moyen de faire consiste à utiliser des crochets côté-serveur, point qui sera abordé plus loin. Cette autre approche permet de réaliser des traitements plus complexes comme de refuser l’avance rapide seulement à un certain groupe d’utilisateurs.
receive.denyDeletes
Un des contournements possible à la politique denyNonFastForwards
consiste à simplement effacer la branche distante et à la repousser avec les nouvelles références.
Pour interdire ceci, réglez receive.denyDeletes
à true
:
$ git config --system receive.denyDeletes true
Ceci interdit la suppression de branches ou d’étiquettes. Aucun utilisateur n’en a le droit. Pour pouvoir effacer des branches distantes, vous devez effacer manuellement les fichiers de référence sur le serveur. Il existe aussi des moyens plus intéressants de gérer cette politique utilisateur par utilisateur au moyen des listes de contrôle d’accès, point qui sera abordé dans Exemple de politique gérée par Git.