Configuration de Git

, par _Eric_

Principes de base

Lien tutoriel : https://git-scm.com/book/fr/v2/D%C3...

L’installation terminée il est possible d’invoquer Git au travers d’une fenêtre Bash (la commande git est connue car on a adapté le PATH en conséquence à l’étape d’installation). Par exemple, on vérifie la version installée en tapant la commande git --version dans l’invite de commande.

$ git --version
git version 2.23.0

Maintenant, pour utiliser Git de façon extensive, il est nécessaire de définir une fois pour toute quelques paramètres de configuration persistants comme l’identité de l’utilisateur. Pour ce faire, Git propose un outil git config qui génère des fichiers de configuration :

  • soit au niveau système (pour tous les utilisateurs). Ce fichier n’existe pas toujours. Pour le créer, il faut invoquer la commande git config avec l’option --system et les paramètres désirés. Ce paramétrage est rarement utile, on en parlera plus dans la suite de cet article.
  • soit au niveau de l’utilisateur et s’appelle ~/.gitconfig [1]. Pour le mettre à jour, il faut invoquer la commande git config avec l’option --global.
  • soit au niveau d’un dépôt local (répertoire Git). Dans ce cas, il s’appelle .git/config, quelque soit l’OS.

Ces fichiers sont aussi consultables et modifiables par un éditeur de texte.

Configuration classique au niveau utilisateur

Lien tutoriel : https://git-scm.com/book/fr/v2/Pers...
Lien de référence de l’outil git config : https://git-scm.com/docs/git-config.html

Pour configurer son identité, à savoir, le nom de l’utilisateur, Jean Martin et son email, jean.martin@spip.org, il faut lancer les commandes suivantes à l’invite de commande (Git Bash pour Windows ou Terminal pour MacOS) :

$ git config --global user.name "Jean Martin"
$ git config --global user.email jean.martin@spip.org

Pour définir l’éditeur de texte qui sera lancé pour saisir les messages (inutile quand on utilise un GUI mais nécessaire si on utilise uniquement l’invite de commande), il faut préciser à Git le chemin vers l’exécutable en utilisant la commande suivante :

$ git config --global core.editor emacs

Il est aussi possible de changer les couleurs utilisées pour repérer les changements de code (ajout, modification, suppression), de définir une modèle pour les messages de commits, une clé PGP pour signer les commits et bien d’autres choses décrites dans la documentation de référence de l’outil git config.

Configuration des fichiers ignorés

Lien tutoriel : https://www.atlassian.com/git/tutor...
Lien de référence du gitignore : https://git-scm.com/docs/gitignore

Git donne la possibilité d’exclure des fichiers ou des modèles de fichier du versionnage. Par défaut, ces fichiers ne seront jamais ajoutés au dépôt Git. Cette configuration est spécifique à un dépôt Git et le fichier de nom .gitignore est positionné en général à la racine du dépôt et s’applique à toute l’arborescence. Il est aussi possible de rajouter d’autres fichiers de ce type dans une sous-arborescence sachant que les .gitignore s’applique en cascade du haut (moins prioritaire) en bas (plus prioritaire).

Maintenant, il est possible de définir une liste d’exclusions au niveau de l’utilisateur qui s’appliqueront à tous les dépôts locaux de celui-ci. Pour cela il faut utiliser la commande suivante qui configure ce fichier d’exclusions global :

$ git config --global core.excludesfile ~/.gitignore_global

Il est classique d’utiliser le nom .gitignore_global pour désigner ce fichier et de le placer à la racine de l’utilisateur (C:\Users\nom_user\ pour Windows en anglais ou C:\Utilisateurs\nom_user\ pour la version française).

Une fois créé, le fichier doit être édité et complété avec les motifs définissant les fichiers à ignorer. Il est conseillé d’utiliser les commentaires pour préciser l’objectif de chaque motif. Par exemple :

# Exclure les fichiers .bak et .log
*.bak
*.log

La page suivante décrit la grammaire des motifs : https://www.atlassian.com/git/tutor.... Github propose aussi une liste de modèles de .gitignore en fonction du langage (https://github.com/github/gitignore).

Configuration des droits d’accès

Une fois que vous aurez effectué des modifications sur votre dépôt Git local, il sera nécessaire de les pousser sur le serveur Git distant (à l’instar du commit SVN). Pour ce faire, il faut que vous soyez autorisé à accéder au dépôt distant en écriture.

Git supporte les protocoles HTTPS et SSH. HTTPS requiert une authentification classique par login et mot de passe mais l’utilisation de SSH est fortement recommandée car elle est simple et très sécurisée. C’est la méthode que nous allons décrire ci-après.

Pour utiliser SSH, il vous faut une paire de clés attachée à un compte utilisateur. L’une des clés est dite privée car elle est destinée à rester sur l’ordinateur de l’utilisateur (souvent nommée id_rsa) et l’autre est dite publique car c’est elle qui est copiée sur les serveurs avec qui on veut communiquer (souvent nommée id_rsa.pub). Par défaut, ces clés sont créées dans le dossier ~/.ssh (ou C:\Users\nom_user\.ssh\ sous Windows en anglais).

Si vous n’en disposez pas déjà, vous devrez générer une paire de clés SSH. Pour cela, il faut lancer la commande ssh-keygen à l’invite de commande comme suit :

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/nom_user/.ssh/id_rsa):

Le mieux est d’accepter le nom par défaut proposé pour le fichier en pressant la touche retour. Un mot de passe est alors requis deux fois : c’est une sécurité supplémentaire mais cela pose parfois quelques soucis avec les GUI si on n’enregistre pas correctement ce mot de passe. Il est donc possible de le laisser vide en pressant deux fois la touche retour. Le répertoire ~/.ssh contient maintenant les fichiers id_rsa et id_rsa.pub.

Si vous souhaitez ajouter un mot de passe à votre clé SSH suivez le tutoriel d’Atlassian https://confluence.atlassian.com/bi... et l’utilisation du ssh-agent.

Si le serveur Git est motorisé par une forge comme Github, Bitbucket, Gitlab.com ou une forge communautaire comme celle de SPIP sous Gitea, il suffit de se rendre sur son compte et d’y ajouter la clé publique générée. Pour ce faire, il est nécessaire de copier son contenu complet (le fichier id_rsa.pub est éditable par tout éditeur de texte) dans l’emplacement demandé par la forge. Si aucune forge n’est utilisée, il suffit de fournir sa clé à l’administrateur du serveur Git.

Pour la forge SPIP propulsée par Gitea voilà à quoi ressemble l’onglet Clés SSH d’un utilisateur [2] :

Si vous avez plusieurs ordinateurs, le mieux est de générer une clé pour chacun et d’ajouter les différentes clés à la forge utilisée.

Notes

[1Sous Windows 10, le fichier de niveau utilisateur .gitconfig se trouve dans C:\Users\nom_user\.

[2Pour Github ou BitBucket des interfaces similaires sont disponibles.