Git permet de modifier son comportement de plusieurs manières. Vous pouvez bien entendu utiliser les options de chaque commandes, mais aussi modifier la configuration de l’outil.

Il est ainsi possible de spécifier que pull doit automatiquement utiliser l’option --rebase, ou bien que push ne peut pas être appeler sans arguments.

Fichiers de config

La configuration peut être réparti dans plusieurs fichiers, c’est ce qui permet d’avoir des configurations spécifiques pour chaque dépôt (par exemple les infos de trackings ou les dépôts distants).

Voici la liste des fichiers de configuration, dans l’ordre de priorité (toute variable déclarée dans un fichier écrasera celles potentiellement déclarées dans ceux décrits après).

  • $GIT_DIR/config
  • Fichier de configuration spécifique au dépôt.

  • ~/.gitconfig

  • Fichier de configuration spécifique à l’utilisateur. Aussi nommé « global ».

  • $XDG_CONFIG_HOME/git/config

  • Deuxième fichier de configuration spécifique à l’utilisateur. Si $XDG_CONFIG_HOME n’existe pas, alors $HOME/.config/git/config sera utilisé. (depuis Git 1.7.xx)

  • $(prefix)/etc/gitconfig

  • Fichier de configuration système

Git ignore

Il existe plusieurs fichiers d’ignore, recensant les fichiers et dossiers que Git devrait ignorer.

Encore une fois, je ne peux que vous conseiller de lire la documentation fournie (git help ignore).

Voici la liste des endroits où vous pouvez demander à Git d’ignorer certains pattern (dans l’ordre de priorité — le premier étant le plus prioritaire) :

  • Ligne de commande
  • Certaines commandes permettent de spécifier des fichiers à ignorer, voire de fournir un fichier contenant la liste.

  • $GIT_DIR/info/exclude

  • Fichier existant dans chaque dépôt. Pratique pour ignorer d’éventuels scripts perso que vous utiliseriez dans un projet particulier (et donc que vous stockeriez à l’intérieur).

  • Fichier spécifié par la variable de configuration core.excludesfile

  • Par défaut dans $XDG_CONFIG_HOME/git/config ou $HOME/.config/git/config si $XDG_CONFIG_HOME n’est pas défini.

Pour info, la syntaxe permet d’annuler l’ignorance de certains patterns en les préfixant par un point d’exclamation (« ! »). Par exemple vous pouvez avoir ceci :

# ignore all files in data
/data
# except the boostrap ones
!/data/boostrap

Variables d’environnement

Git — à l’instar des autres commandes Unix — se réfère aux variables d’environnement pour certaines options de configuration élémentaires. Voici quelques variables utiles.

EDITOR
L’éditeur utilisé par les commandes interactives (comme commit, rebase --interactive, etc). On peut aussi le spécifier dans le fichier de configuration.
GIT_DIR
Le chemin du dossier .git (permet d’exécuter des commandes sans être dans le dossier)
GIT_WORK_TREE
Le chemin du working tree, c.a.d le dossier dans lequel se trouvent les fichiers pris en charge par Git.
GIT_INDEX_FILE
Le chemin du fichier d’index (permet de le sauvegarder pour plus tard)

Aliases

Le principes derrière les alias est très vieux, donc inutile de vous le présenter, je me permets cependant de vous glisser subtilement 1 un petit conseil du soir, une recommandation, une idée, un concept… bref, un truc à ne pas transgresser si vous souhaitez — et vous le souhaitez — ne pas subir le châtiment divin : ne laissez jamais un alias vous masquer la vraie commande. Il s’agit de raccourci — pour économiser des précieuses lettres qui coûtent si cher à vos petit shell — et non de personnalisation des commandes existantes.

Par exemple, je me verrai contraint d’empaler à un poteau électrique quiconque oserait créer un alias nommé « commit » dont la valeur serait, par exemple, tant qu’à blasphémer autant ne pas y aller de main morte, « commit -a »2. Bon, cela dit, pour cet exemple, ça ne ferait pas grand chose, Git se contenterait de l’ignorer (ouf). Il en va de même pour des « ci=commit -a » qui — s’il permettent de savoir qu’on parle à un alias — risquent de vous faire oublier que vous utiliser une option de la commande (et pas la meilleure de qui plus est).

Voici des exemples d’alias que je trouve pertinents, mais c’est juste pour donner une idée :

  • fetchap=fetch --all --prune — On sait qu’on fait un fetch, et on sait qu’on ajoute des options
  • me=merge — Plus rapide à taper que merge, sans pour autant changer le comportement
  • meff=merge --ff-only — Plus rapide à taper que merge, et change le comportement de manière évidente.

Petite note pour la route : Git propose (via la config help.autocorrect) de corriger automatiquement vos fautes de frappe. Par exemple en appelant « merge » au lieu de « merhe ». Il va sans dire3 qu’un grand nombre d’alias aux graphies proches risquent de nuire à cette aide. Vous voilà prévenu.

Tracking

Je vais faire très court (parce que ça n’est pas la partie qui me fait le plus rêver) : le tracking c’est de la conf qui permet à Git savoir qu’une branche locale (disons develop) est liée à une branche distance (disons la branche develop du dépôt origin). C’est tout.

Configurer le tracking permet

  • d’avoir des rappels sur les divergences potentielles entre ces deux branches ;
  • d’utiliser les commandes git push et git pull sans leur fournir d’arguments (à condition qu’ils soient configurés pour utiliser le tracking).

Bref : voyez le tracking comme une aide potentielle fournie par Git, mais ne tentez pas de vous reposer dessus si vous n’êtes pas sûr d’avoir la maîtrise de l’engin.

De la bonne utilisation des éditeurs lancés par Git

Lorsque Git lance un éditeur, il commence par créer un fichier temporaire (dans le dossier $GIT_DIR) puis l’ouvre avec votre éditeur favori. Il attend ensuite que l’éditeur lui rende la main puis lit le contenu du fichier et continue ce qu’il faisait.

Conséquence directe : si Git vous lance un éditeur et que vous voulez annuler la commande, alors il ne faut pas juste quitter. Pour annuler il faut supprimer le contenu du fichier et sauvegarder, ainsi Git comprendra que vous ne souhaitez plus réaliser la commande. Si vous vous contentez de quitter l’éditeur, Git interprétera cela comme « ok c’est parfait comme ça ».

De même, il est très important que votre éditeur reste au premier plan. S’il s’exécute en arrière plan alors Git pensera que vous avez déjà fini… Ce qui n’est pas exactement ce que vous souhaitez.

Ceci est valable pour les commandes commit, rebase -i, tag, merge, …


  1. Subtilement et explicitement, ce qui est — il faut bien l’avouer — d’une classe assez peu représentée de nos jours.
  2. Mais je m’emploierais néanmoins à cette tâche avec un zèle peu commun.
  3. Heureusement je l’écris, donc ça va.