Mais même au sein de ces derniers, une part encore trop grande ne recourt pas à un prompt personnalisé pour disposer à tout moment d’informations importantes sur leur dépôt local et leur copie de travail, sans parler d’une complétion intelligente sur les commandes Git.

Cet article vise à vous aider à optimiser votre prompt quand vous êtes dans vos dépôts Git.

C’est quoi un prompt ?

C’est le texte qui est affiché avant chaque invite de commande dans une session shell. Par exemple, dans une invite de commande Windows classique, c’est généralement juste le chemin suivi d’un chevron fermant, du genre :

1

C:\Users\Tristounet> _

Sur les système Linux/Unix, la plupart des gens ont un prompt par défaut qui affiche leur identifiant, le nom de la machine, et le chemin courant, suivis d’un $ s’ils sont des utilisateurs classiques ou de # s’ils sont le super-utilisateur, root :

1

tdd@CodeWeaver:js-attitude $ _

Selon le shell utilisé (cmd ou PowerShell sous Windows, une pléthore sur Linux/Unix dont émergent principalement Bash et ZSH), ce prompt se configure de diverses façons, le plus souvent au moyen de variables d’environnement dédiées, voire d’une fonction shell spécifique.

Pourquoi un prompt personnalisé ?

Beaucoup de gens configurent leur prompt pour ajuster l’ordre d’affichage des infos, en ajouter, coloriser des parties, indiquer automatiquement si la dernière commande a rencontré une erreur, etc.

Informations immédiates sur l’état / le statut

Dans cet esprit d’informations complémentaires, il est possible de recourir à des fichiers spécifiques de Git pour y incruster plein d’infos utiles sur le dépôt courant, son index et sa copie de travail, afin…

• de gagner du temps (inutile de les demander explicitement)
• mais aussi d’éviter de nombreux pièges en remarquant en amont qu’on n’est pas dans l’état où on croyait (ex. il reste de l’untracked, y’a du modified, la branche active n’est pas la bonne, etc.).

Pour cela, on va personnaliser les variables qui gouvernent la construction du prompt à chaque invite de commande.

Complétion intelligente

Il ne s’agit pas du prompt à proprement parler, mais il est également possible de renseigner auprès de notre shell une gestion de complétion (généralement avec la touche Tab) pour les diverses commandes de Git, et même pour les arguments de ces commandes !

Ce confort supplémentaire n’est pas anodin, en ce qu’il rend de nombreux aliases (raccourcis) superflus, et accélère considérablement la saisie des commandes.

Les cas déjà gérés

Selon votre situation technique, vous avez déjà plus ou moins de choses qui sont configurées pour vous côté prompt et complétion.

Oh-my-Zsh

Pour ceux qui utilisent ZSH au travers de l’excellentissime projet Oh My ZSH, ils disposent automatiquement d’une prise en charge des dépôts Git et d’un grand nombre de thèmes (du sublime à l’immonde) pour personnaliser leur affichage.

Vous y noterez un recours fréquent aux caractères Unicode et à la palette 256 couleurs. Utiliser un terminal moderne est donc recommandé.

mSysGit (Windows)

Curieusement, les utilisateurs de Git sous Windows, au travers de mSysGit, sont déjà pas mal lotis puisque la complétion et le prompt sont déjà en place dans le Git Bash installé par l’outil.

Seul bémol : la configuration par défaut omet certaines infos, notamment les untracked, il faudra donc personnaliser un peu le fichier .bashrc à la racine du compte utilisateur pour améliorer l’affichage obtenu. Vous verrez comment dans un instant.

Se configurer ça à la main

Pour les utilisateurs de ZSH, vous êtes sensés être des utilisateurs avancés, je vous laisse donc aller fouiller dans les fichiers fournis par Oh My ZSH pour y trouver votre bonheur.

Les utilisateurs de Bash auront besoin de trois choses :

1. Charger les fichiers de prompt/complétion s’ils ne sont pas auto-chargés
2. Définir les variables d’environnement contrôlant l’affichage par la fonction de prompt Git
3. Modifier la définition du prompt pour recourir à ladite fonction

Le fichier de configuration du shell

Suivant le système que vous utilisez et la façon dont vous ouvrez votre shell, Bash reconnaît trois fichiers de configuration, tous placés à la racine de votre compte utilisateur.

Cette racine est du style C:\Documents and Settings\TonPtitNom ou C:\Users\TonPtitNom sur Windows, /home/tonptitnom sur Linux/Unix et /Users/tonptitnom sur OSX.

Les trois fichiers concernés sont .bashrc, .bash_profile et .profile. Linux/Unix utilise généralement les deux premiers : l’un contient les instructions d’initialisation tandis que l’autre se contente de lui déléguer le travail. OSX a tendance à favoriser .profile pour son Terminal.

mSysGit n’en propose aucun par défaut, mais vous pourrez créer .bashrc manuellement (attention toutefois à la majorité des éditeurs Windows qui refuseront de créer un fichier commençant par un point : ils colleront sûrement une extension .txt supplémentaire derrière, il vous faudra ouvrir le Git Bash et faire mv .bashrc.txt .bashrc pour le renommer correctement afin qu’il soit utilisé par le shell).

Dans la suite de cet article, nous ferons référence au fichier qui concerne votre cas de figure sous le nom générique « fichier de configuration ».

Localiser les fichiers contribués

C’est ici que ça varie pas mal suivant votre contexte technique.

Si vous utilisez mSysGit, vous n’avez rien à faire côté fichiers, il vous suffira de manipuler les variables d’environnement tout à l’heure.

Dans les autres cas basés sur Bash, tout dépend de comment vous avez installé Git.

Si vous êtes passés par un paquet Linux/Unix classique, vous avez probablement le fichier de complétion déjà posé à la bonne place. C’est généralement dans /etc/bash_completion.d, et ça s’appelle soit git (un seul fichier), soit git-completion.bash et git-prompt.sh (deux fichiers). Dans les deux cas, vu qu’ils sont placés dans ce dossier, ils sont auto-chargés.

Si c’est auto-chargé, vous n’avez rien à faire à la section suivante (« Activer la complétion »), passez directement aux sections de configuration du prompt.

Activer la complétion

Restent les cas d’installation manuelle, au travers d’une compilation des sources ou, plus automatiquement, de Homebrew sur OSX.

Dans le cas d’une compilation manuelle, cherchez vos fichiers de complétion. Ils sont probablement quelque part dans /usr/local, par exemple /usr/local/git/contrib/completion. Supposons que ce soit le cas, vous devrez rajouter au fichier de configuration la ligne suivante (adaptez aux noms de fichier que vous y aurez trouvés) :

1
2

source /usr/local/git/contrib/completion/git-completion.bash
source /usr/local/git/contrib/completion/git-prompt.sh

Dans le cas de Homebrew, ils sont normalement dans le etc/bash_completion.d du préfixe Homebrew, qui est par défaut /usr/local. Les scripts de ce répertoire sont alors traités automatiquement par un script général etc/bash_completion. Histoire d’être génériques, on va lui demander de nous sortir ça et on teste autour pour ne pas se faire mal plus tard. Ajoutez ceci à votre fichier de configuration :

1
2
3

if [ -f $(brew --prefix)/etc/bash_completion ]; then
  source $(brew --prefix)/etc/bash_completion
fi

Une fois que vous avez bidouillé et sauvé (si si, plein de gens oublient…) votre fichier de configuration, ouvrez directement un nouveau terminal pour vérifier que vous n’avez pas d’erreur au démarrage (regardez bien ce qui s’affiche dès le lancement !).

Tapez ensuite git, une espace, et la touche Tab (une ou deux fois, suivant votre terminal) : si vous voyez apparaître une liste de commandes Git, on a gagné. Si vous voyez juste les fichiers du répertoire courant, on a perdu, et il vous va falloir examiner votre configuration pour trouver ce qui cloche.

Configurer un prompt simple

Commençons avec un prompt simple, qui reproduirait uniquement la version classique en incrustant si besoin des infos Git. Cette section est longue mais c’est parce qu’on teste plusieurs configurations d’affichage, n’ayez pas peur…

Nous allons personnaliser la variable spéciale de Bash nommée PS1. Cette variable agit comme un motif évalué à chaque invite de commande. Elle peut contenir des codes spéciaux sous forme d’un caractère précédé d’une barre oblique inverse (antislash : \). Par exemple, un prompt classique est de la forme :

1

export PS1='\u@\h:\w \$ '

Décryptons un brin :

• \u est l’identifiant de l’utilisateur courant
• \h est le premier segment du nom de la machine courante (avant un éventuel premier .)
• \w est le chemin complet du répertoire courant, l’éventuelle racine de votre compte étant abrégée en ~ (par exemple, au lieu de /Users/tdd/js-attitude, on verrait ~/js-attitude)
• \$ affichera # ou $ suivant que l’on est super-utilisateur ou non
• Les autres caractères (@, :, les espaces) sont littéraux.

Vous trouverez la liste complète des codes dans l’aide de Bash (man bash), à la section PROMPTING.

Ce qui nous intéresse nous, c’est qu’on peut utiliser la syntaxe d’imbrication d’exécution de Bash pour évaluer une fonction Bash et en récupérer l’affichage, directement dans le motif du prompt. Cette syntaxe est de la forme $(ligne de commande), et nous aurons ici recours à une fonction dédiée, __git_ps1, fournie par les fameux scripts qu’on s’est échinés à trouver puis charger quelques paragraphes plus haut.

Le prompt final donnerait ceci :

1

export PS1='\u@\h:\w$(__git_ps1) \$ '

Notez qu’il est possible de passer à __git_ps1 un motif printf pour formater son affichage. Par défaut, il s’agit de " (%s)". Le %s sera remplacé par le texte issu de la commande.

Mettez à jour votre PS1 en fin du fichier de configuration, puis rechargez-le en tapant source nom-du-fichier, ou ouvrez un nouveau terminal.

Vérifiez déjà que votre prompt n’a pas d’entrée de jeu une sale tête, ou affiche une erreur. Il devrait être comme avant (sauf si vous l’aviez personnalisé, auquel cas préférez incruster où bon vous semble $(__git_ps1) dans le motif que vous aviez déjà).

Si dès l’ouverture d’un terminal, à la racine de votre compte, vous voyez s’afficher des infos entre parenthèses (sans doute après qu’un certain temps de gel apparent a passé) c’est que vous avez créé un dépôt Git à la racine de votre compte, voire plus haut (le pire cas possible étant /, la racine absolue). Un tel cas est plus que probablement une erreur, et vous devrez retirer/déplacer le dossier .git correspondant si vous souhaitez utiliser le prompt, car dans une telle situation, à chaque prompt, tous les sous-dossiers de celui contenant le .git seront examinés en profondeur pour déterminer l’état à afficher, ce qui est catastrophique en performances.

Si tout va bien, déplacez-vous dans un dépôt Git local (à défaut, créez-en un pour voir : mkdir /tmp/toto && cd /tmp/toto && git init) : vous devriez voir apparaître, entre parenthèses, au minimum le nom de la branche courante, suivi potentiellement de plusieurs symboles.

Par défaut, seules les modifications dans la copie locale (dirty) et l’index (staged) sont signalées, au moyen des symboles * et +, respectivement. Suivant la version de Git utilisée, vous disposez de plus ou moins de réglages, au travers de variables d’environnement.

Sur Git 1.8.1.2 par exemple, ces variables sont :

• GIT_PS1_SHOWDIRTYSTATE : signaler les modifs à la copie locale (symbole *) et à l’index (le stage, symbole +).
• GIT_PS1_SHOWSTASHSTATE : signaler la présence d’entrées dans le stash (symbole $)
• GIT_PS1_SHOWUNTRACKEDFILES : signaler la présence de fichiers ni versionnés ni ignorés (donc untracked) dans la copie locale (symbole %).
• GIT_PS1_SHOWUPSTREAM : indiquer le rapport entre la branche locale et sa version trackée (en retard <, en avance >, synchro = ou ayant divergé <>). Les affichages peuvent être modifiés selon la valeur de la variable ; les symboles décrits ici sont pour la valeur auto, mais on en a d’autres, notamment verbose. Voyez votre script de prompt pour les détails.
• GIT_PS1_DESCRIBE_STYLE peut prendre diverses valeurs pour représenter un detached HEAD ; par défaut (default), on a l’abbreviated SHA mais on a d’autres options, la plus utile étant probablement branch.

Eh ben, ça fait déjà du monde !

Du coup, pour personnaliser un peu votre prompt, définissons les variables qui vont bien au sein de votre fichier de configuration, par exemple juste avant de redéfinir PS1 :

1
2

export GIT_PS1_SHOWDIRTYSTATE=1 GIT_PS1_SHOWSTASHSTATE=1 GIT_PS1_SHOWUNTRACKEDFILES=1
export GIT_PS1_SHOWUPSTREAM=verbose GIT_PS1_DESCRIBE_STYLE=branch

Notez le % en plus (puisque j’ai de l’untracked, là…) et le u+1 qui m’indique en l’occurrence que j’ai un commit d’avance sur la branche distante, et aucun commit en retard.

Configurer un prompt avancé

Pour obtenir davantage de notre prompt, il nous faut recourir à une autre variable Bash que PS1, à savoir la bien-nommée PROMPT_COMMAND.

Cette variable contient une ligne de commande Bash complète (en général un appel de fonction, les instructions complexes étant dans la fonction) qui va être exécutée à chaque invite. Elle n’a pas pour but de renvoyer un texte, mais fait tout ce qu’elle veut et l’affichage directement. Libre à elle, donc, de faire du multi-ligne, de découper sa sortie à gauche et à droite à l’aide des codes ANSI VT-x, etc.

Avant d’entrer dans des commandes de fou, commençons juste par faire l’équivalent de ce qu’on avait jusqu’ici, mais en mode commande au lieu du motif de prompt. Il suffit de remplacer la ligne où nous définissions PS1 par celle-ci :

1

export PROMPT_COMMAND='__git_ps1 "\u@\h:\w" " \\\$ "'

Vous voyez ici qu’on appelle __git_ps1 avec deux arguments : le préfixe et le suffixe de l’éventuel affichage Git-spécifique. Dans cette syntaxe, si vous vouliez préciser un motif de formatage, il aurait fait l’objet d’un troisième argument. L’antislash avant le dollar est triplé car on est dans une chaîne interprétée (guillemets droits "), il y a donc déjà un premier niveau d’échappement utilisé d’entrée de jeu.

Ce qui est sympa avec ce mode, c’est qu’il nous permet de demander la colorisation du texte affiché par __git_ps1, en ajoutant à nos variables de configuration GIT_PS1_SHOWCOLORHINTS=1 :

On peut bien sûr aller beaucoup plus loin en créant ses propres fonctions. Ainsi, Matthew McCullough, le principal formateur Git chez Github, maintient dans ses fichiers de conf un prompt personnalisé plutôt bourrin, qui recourt librement aux caractères Unicode :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

#!/bin/bash

########################################################################
# Matthew's Git Bash Prompt
########################################################################
        RED="\[\033[0;31m\]"
     YELLOW="\[\033[0;33m\]"
    GREEN="\[\033[0;32m\]"
       BLUE="\[\033[0;34m\]"
  LIGHT_RED="\[\033[1;31m\]"
LIGHT_GREEN="\[\033[1;32m\]"
      WHITE="\[\033[1;37m\]"
 LIGHT_GRAY="\[\033[0;37m\]"
 COLOR_NONE="\[\e[0m\]"

function parse_git_branch {
  git rev-parse --git-dir &> /dev/null
  git_status="$(git status 2> /dev/null)"
  branch_pattern="^# On branch ([^${IFS}]*)"
  remote_pattern="# Your branch is (.*) of"
  diverge_pattern="# Your branch and (.*) have diverged"

  if [[ ! ${git_status}} =~ "working directory clean" ]]; then
    state="${RED}⚡"
  fi
  # add an else if or two here if you want to get more specific
  if [[ ${git_status} =~ ${remote_pattern} ]]; then
    if [[ ${BASH_REMATCH[1]} == "ahead" ]]; then
      remote="${YELLOW}↑"
    else
      remote="${YELLOW}↓"
    fi
  fi
  if [[ ${git_status} =~ ${diverge_pattern} ]]; then
    remote="${YELLOW}↕"
  fi
  if [[ ${git_status} =~ ${branch_pattern} ]]; then
    branch=${BASH_REMATCH[1]}
    echo " (${branch})${remote}${state}"
  fi
}

function git_dirty_flag {
  git status 2> /dev/null | grep -c : | awk '{if ($1 > 0) print "⚡"}'
}

function prompt_func() {
    previous_return_value=$?;
    #The lowercase w is the full current working directory
    #prompt="${TITLEBAR}${BLUE}[${RED}\w${GREEN}$(parse_git_branch)${BLUE}]${COLOR_NONE}"

    #Capital W is just the trailing part of the current working directory
    prompt="${TITLEBAR}${BLUE}[${RED}\W${GREEN}$(parse_git_branch)${BLUE}]${COLOR_NONE}"

    if test $previous_return_value -eq 0
    then
        PS1="${prompt}> "
    else
        PS1="${prompt}${RED}>${COLOR_NONE} "
    fi
}

PROMPT_COMMAND=prompt_func

Pour la même situation que tout à l’heure, ça donne ceci :

Chez Matthew, l’écart avec la branche distante trackée utilise des flèches simples ou doubles, et tout état non « clean tree » affiche juste un éclair. On pourrait bien sûr revenir au chemin complet, identifiant et nom de machine, etc. en plus de ces infos et de leur colorisation, et détailler les états locaux distincts.

L’important, c’est que c’est un script, votre script, et que vous pouvez donc tout faire :-)

Envie d’en savoir plus ?

Nos formations Git au Quotidien explorent en profondeur les questions de configuration, de prompt et d’options avancées ou méconnues pour les commandes même les plus simples. Une excellente façon d’aller bien au-delà de ces quelques réglages !

Ceci étant dit, c’est l’occasion de faire le point sur l’évolution de notre activité de formation. Et comme Attitude, c’est avant tout la transparence, je me suis dit que ça pourrait vous intéresser de voir d’où nous sommes partis et où nous en sommes.

(note : cet article est posté sur l’ensemble des sites Attitude)

Pratiquement 3 ans

Si Delicious Insights n’existe que depuis août 2011, notre activité de formation a démarré bien avant cela, sous d’autres formes : dès le 2 juillet 2010, pour être précis. C’était la première formation Git au Quotidien, déjà chez Clever Age et à un tarif ubuesque pour les valeureux pionniers qui osaient l’aventure : 50€ la journée, déjeuner compris !

Lorsqu’en octobre j’expliquais l’idée derrière Git Attitude aux copains pendant Paris Web, ce bon vieux Jérémie Patonnier m’a dit sur un ton débonnaire et détaché : « mais pourquoi tu ne fais pas la même chose avec JavaScript ? ». Après m’être tapé la tête contre le mur de ne pas y avoir pensé dès le début, j’ai donc lancé JS Attitude avec tout d’abord JS Puissant et une première session bondée (16 personnes !) le 27 novembre, vendue en quelques jours, presque quelques heures…

Voici un petit historique de jalons sélectionnés :

Quelques chiffres

Je vous passe l’évolution d’un exercice fiscal à l’autre, mais sachez qu’aujourd’hui, Delicious Insights, au travers de Git Attitude et JS Attitude, c’est :

• 7 formations au catalogue (3 Git et 4 JavaScript)
• 52 sessions déjà données, soit
• 544 heures de formation à destination de
• 444 stagiaires au sein de
• plus de 80 sociétés clientes (et de nombreux participants à titre personnel)

Parmi nos clients, un équilibre surprenant entre TPE/PME, agences (TBWA, MRM Worldwide, Fullsix / Ekino…), SSII (Atos, Valtech…) et grands comptes (SNCF, Orange, EADS, Dassault, Intel, Alcatel-Lucent, 4D, FNAC, l’OCDE, Météo France, MisterGoodDeal, PriceMinister…). Des clients situés dans 5 pays : France, Royaume-Uni, Belgique, Suisse et Luxembourg.

Des stagiaires enchantés

Tous nos stagiaires ont l’occasion de faire un retour à chaud en fin de session, face à face, ainsi qu’un retour à froid via un formulaire en ligne proposant des évaluations tant quantitatives (notes de 1 à 5) que qualitatives (texte libre). Un bon tiers de nos stagiaires prennent le temps de le remplir (une proportion historique qui, toutefois, ne cesse de s’améliorer). Nous n’avons rien à cacher, alors allez donc consulter un rapport temps réel sur les retours qui nous sont faits.

Merci à vous

Je voudrais profiter de cet article pour remercier très chaleureusement tous les stagiaires qui nous ont fait confiance jusqu’ici, et leurs employeurs qui ont accepté de les envoyer dans nos formations. C’est un plaisir chaque fois renouvellé de vous transmettre tout ce qu’on peut, d’échanger avec vous et de lire vos retours !

Et maintenant ?

Eh bien, on va commencer par finir l’exercice en cours (au 30 juin), et préparer la rentrée…

Je souhaite rédiger davantage d’articles de fond, ainsi que de la retranscription de veille et des didacticiels sur diverses technos, sur les différents sites Attitude.

J’ai très envie de pouvoir mettre au catalogue des formations Node.js, Ruby et Rails, mais on verra si le temps de préparation ne fait pas trop défaut.

On va probablement élargir petit à petit le groupe de formateurs, aussi, en travaillant avec des personnes de confiance qu’on connaît de longue date, qui partagent notre philosophie, nos valeurs, et font preuve d’une expertise technique et d’une pédagogie à la hauteur de nos exigences.

Enfin, le catalogue de formations va faire l’objet au fur et à mesure d’une déclinaison sous forme de screencasts qualitatifs payants, d’une heure environ chacun, avec des possibilités d’achat par lot (pour toute la série “Git au Quotidien” par exemple), les stagiaires bénéficiant automatiquement d’un fort rabais sur ces derniers.

Espérons qu’on aura le temps de tout faire !

1. Locale. Spécifique à chaque dépôt local, elle est stockée dans le .git/config. On y trouve notamment les trackings de branches, le remote, etc.
2. Globale. Spécifique à l’utilisateur, elle est stockée à la racine de son compte, dans le fichier ~/.gitconfig. C’est celle qui nous intéresse ici.
3. Système. Généralement stockée dans /etc/gitconfig, elle est partagée par tous les utilisateurs. Elle est rarement employée.

Les priorités vont dans l’ordre usuel : du local au système.

La majorité des utilisateurs se contente de coller dans son .gitconfig ses nom, e-mail et préférences d’éditeur. C’est là une sous-utilisation navrante. De très nombreux aspects quotidiens de Git sont paramétrables, et donc améliorables, au travers de la configuration.

Cet article explore ma configuration personnelle pour vous faire découvrir de nombreuses astuces utiles.

Avant toute chose, assurez-vous que vous utilisez un Git récent (1.8+). Plusieurs options de configuration évoquées ci-après n’ont fait leur apparition que récemment. Si une option semble ignorée chez vous, vérifiez soigneusement son nom et sa valeur, puis jetez un œil aux notes de version pour retrouver la version dans laquelle l’option est apparue.

Je maintiens une version publique générisée de ma configuration dans ce Gist. Par « générisée », je veux dire que j’en retire, ou que j’y commente, quelques traitements qui me semblent délicats à activer par défaut, car ils concernent des comportements subtils de Git qu’il vaut mieux bien connaître avant de les appliquer.

Un fichier de configuration Git est d’une syntaxe similaire à un bon vieux fichier INI : les sections sont délimitées par un en-tête [nom.section], et les lignes de propriété qui suivent appartiennent à la section. L’indentation est recommandée mais nullement obligatoire. La représentation linéarisée d’une propriété est section.nom, par exemple core.whitespace pour la propriété whitespace au sein de la section [core].

Voici déjà le gist global :

Examinons à présent les réglages un par un.

Identité par défaut pour les commits

C’est la base de la base : identifier vos commits à venir. On utilise pour cela user.name et user.email. Évitez toutefois de pourrir la config Git d’un utilisateur de déploiement sur un serveur de prod avec ce genre de trucs, si vous êtes plusieurs personnes à pouvoir déployer. Préférez qualifier un éventuel commit en prod (ouh là là…) avec git commit --author=… afin de ne pas vous mélanger les pinceaux.

Colorisation

De nombreuses commandes Git sont capables de coloriser leur affichage à l’aide de codes ANSI VT lorsque le terminal le permet. La valeur auto a le même sens que dans de nombreuses autres commandes Linux (par exemple ls) : Git détectera s’il est utilisé en direct par un terminal VT capable de gérer les codes de couleur, et si c’est le cas, exploitera cette possibilité.

La propriété color.ui est un paravent générique pour l’ensemble des propriétés plus spécifiques de gestion de couleur, par exemple color.branch, color.diff, color.grep, color.interactive, etc. En gros, on veut de la couleur !

Aliases

Git ne permet par défaut que les noms de commande complets (commit, checkout, etc.), ce qui fait parfois rager les Subversioniens débutant sur Git, qui cherchent en vain leur git ci. Outre qu’un prompt correctement configuré proposera une complétion avancée (ça fera l’objet d’un autre billet), la vraie raison est que Git permet de se créer autant d’aliases qu’on le désire, au moyen des réglages de la section [alias]. Chaque propriété a pour nom celui de l’alias et pour valeur la ligne de commande Git sans le git initial.

Ma configuration prévoit 3 aliases sans lesquels je ne saurais bosser :

• ci pour commit
• st pour status
• lg pour un log textuel avancé qui, en ce qui me concerne, est tout-à-fait à la hauteur des logs graphiques (graphe de branches et fusions, références symboliques, tags et têtes de branches, SHAs, auteurs et horodatage relatif). Et le bonus, c’est qu’il marche dans un terminal, donc via SSH…

Pagination, whitespace et autres réglages « noyau »

Par défaut, Git pagine tout ce qu’il affiche : si ça dépasse la hauteur du terminal, ça se prend un less dans la figure. Personnellement, je ne supporte pas ça : si je veux paginer, je | less moi-même ! En spécifiant via core.pager de passer par cat plutôt que less, je désactive de facto la pagination.

Lorsqu’il ouvre un éditeur (notamment pour les messages de commit ou la mise en place d’un rebase interactif), Git choisit l’éditeur comme ceci :

1. Variable d’environnement GIT_EDITOR
2. Réglage core.editor (c’est ce que je préfère)
3. Variable d’environnement VISUAL
4. Variable d’environnement EDITOR
5. Binaire par défaut retenu à la compilation de Git ; en général, vi.

Si le comportement par défaut n’est pas votre tasse de thé, il vous faut spécifier la ligne de commande à exécuter. Lorsque l’éditeur est graphique, vous devrez l’invoquer de façon à ce qu’il soit en wait mode, c’est-à-dire qu’il ne rende la main qu’une fois le fichier fourni refermé. Tous les éditeurs graphiques n’ont pas cette possibilité.

Voici une liste de lignes de commandes compilée au fil du temps ; vous allez voir, on distingue une tendance :-)… Testez par vous-mêmes pour vérifier ce que ça donne, et si ça a changé, faites-moi signe en commentaires !

• TextMate : l’invocation en ligne de commande mate doit être installée (ça se fait depuis Help > Terminal Usage… dans la v1 et depuis l’onglet Terminal des Préférences dans la v2), après quoi c’est juste mate -w.
• SublimeText : il faut avoir un appel en ligne de commande, là aussi. Sur OSX avec ST2, j’ai un lien symbolique /usr/local/bin/subl vers /Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl, qui est fourni pour ça. Après quoi subl -w.
• GEdit : gedit -w -s
• GVim : gvim --nofork
• Coda : Il vous faut installer coda-cli (généralement via Homebrew, toujours aussi utile…) après quoi coda -w.
• Chocolat : Installez l’appel en ligne de commande (Chocolat > Install Command Line Tool…) après quoi choc -w
• Notepad++ : vous aurez peut-être besoin d’adapter le chemin en fonction de là où vous avez installé Notepad++, mais voici l’idée : 'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin.
• Ultra-Edit : uedit32 /fni

Enfin, le réglage core.whitespace est là pour éviter que certains types de différences liées au whitespace ne soient détectés ou posent problème à des commandes comme git diff, git add -p, git apply ou git rebase. Il existe toute une série de valeurs possibles et combinables ; trailing-space est une combo pour blank-at-eol (whitespace en fin de ligne) et blank-at-eof (whitespace, notamment lignes vides, en fin de fichier). Comme j’indique ici cette valeur en négatif (notez le - préfixe), je précise que ce type d’écarts ne doit pas poser souci ni être signalé.

Diffs améliorés

Par défaut, toute forme de diff signale les deux versions comme a et b :

1
2
3
4
5

[15:54] tdd@CodeWeaver:git-attitude (master *+%) $ git diff 2013-04-03-configuration-git.markdown
diff --git a/source/_posts/2013-04-03-configuration-git.markdown b/source/_posts/2013-04-03-configuration-git.markdown
index e69de29..44bd5ae 100644
--- a/source/_posts/2013-04-03-configuration-git.markdown
+++ b/source/_posts/2013-04-03-configuration-git.markdown

Ce n’est pas toujours évident de savoir ce qu’est a et ce qu’est b… Le HEAD ? Le stage ? Le working directory ? Récemment, Git a fourni un réglage, diff.mnemonicPrefix, qui lorsqu’il est à true va remplacer, lorsque c’est possible, ces initiales anonymes par trois autres :

• c pour Commit (généralement le HEAD)
• i pour Index (le stage)
• w pour Working directory

Ainsi, un diff classique explicite qu’il est effectué entre le stage (l’index) et le working directory :

1
2
3
4
5

[16:02] tdd@CodeWeaver:_posts (master *+) $ git diff 2013-04-03-configuration-git.markdown
diff --git i/source/_posts/2013-04-03-configuration-git.markdown w/source/_posts/2013-04-03-configuration-git.markdown
index 202f830..cde050e 100644
--- i/source/_posts/2013-04-03-configuration-git.markdown
+++ w/source/_posts/2013-04-03-configuration-git.markdown

Un diff --staged indique bien qu’il est effectué entre le HEAD (un commit) et le stage (l’index) :

1
2
3
4
5

[16:02] tdd@CodeWeaver:_posts (master *+) $ git diff --staged 2013-04-03-configuration-git.markdown
diff --git c/source/_posts/2013-04-03-configuration-git.markdown i/source/_posts/2013-04-03-configuration-git.markdown
index cde050e..202f830 100644
--- c/source/_posts/2013-04-03-configuration-git.markdown
+++ i/source/_posts/2013-04-03-configuration-git.markdown

Quant à un diff HEAD, qui explicite son commit de référence, il confirme qu’il compare un commit et le working directory :

1
2
3
4
5

[16:02] tdd@CodeWeaver:_posts (master *+) $ git diff HEAD 2013-04-03-configuration-git.markdown
diff --git c/source/_posts/2013-04-03-configuration-git.markdown w/source/_posts/2013-04-03-configuration-git.markdown
index cde050e..3f85496 100644
--- c/source/_posts/2013-04-03-configuration-git.markdown
+++ w/source/_posts/2013-04-03-configuration-git.markdown

Un autre aspect un peu dommage de git diff est le comportement par défaut de git diff --word-diff. S’il est bien agréable d’avoir par défaut un mode word diff, qui permet de cibler, au sein de deux lignes sans doute très similaires, la zone de différence (un peu comme le changement de contraste dans des outils de diff graphiques), Git considère par défaut comme « mot » toute séquence de caractères non-whitespace. Dans un bloc de code, ça fait vite long, vu que les délimiteurs et opérateurs seront aussi comptabilisés. Par exemple, @twitterClient.directMessage(contact, est considéré comme un mot. Snif.

C’est pourquoi git diff fournit une autre option, --word-diff-regex=…, qui permet de préciser une regex représentant un « mot ». Naturellement, en réduisant cette regex à ., on va tenter la correspondance minimale (jusqu’à un seul caractère). Dans la pratique, quand je fais un diff de niveau mot, je fais toujours comme ça.

C’est là tout l’intérêt du réglage diff.wordRegex : il permet de traiter un simple --word-diff comme un --word-diff-regex=…. Voyez plutôt :

Submodules

Les submodules sont une mauvaise idée. J’en reparlerai en détail dans un prochain article. Toutefois, pour ceux qui sont empêtrés dans les emmerdes quotidiennes des submodules (il y a des pièges à foison dans leur maintenance au quotidien), divers réglages permettent, au fil des versions, d’ajouter des garde-fous. J’en préconise quelques-uns :

• fetch.recurseSubmodules détecte automatiquement lors d’un fetch (et donc d’un pull) si les références des submodules ont bougé, et propose de les récupérer automatiquement si c’est le cas. Attention, ça ne fait pas le submodule update pour autant.
• status.submoduleSummary prend soin de signaler dans git status les submodules dont la référence a bougé, en listant les deltas de commits concernés.

Regex étendues par défaut

Git propose à de nombreux endroits de recourir aux expressions rationnelles (regex). Notamment git log --grep et git log -G, pour ne citer qu’eux. Par défaut cependant, seules les BRE (Basic Regular Expressions) sont traitées, c’est-à-dire que la majorité des caractères spéciaux tels que {}, ‘()’, + et ? sont ignorés. Dans la pratique, quand j’utilise une regex, je veux toujours disposer de la syntaxe étendue (ERE, Extended Regular Expressions), qui active toutes les syntaxes possibles.

Plutôt que d’avoir alors à ajouter -E à ma ligne de commande, j’active le réglage grep.extendedRegexp dans la configuration globale.

Attention cependant : vos regex ne seront pas insensibles à la casse pour autant. Si vous voulez garantir cela, vous devrez généralement ajouter -i à vos lignes de commande.

Les SHA1 complets, ça ne sert à rien

C’est un peu comme le H de Hawai.

La majorité des commandes de Git et de la documentation utilise des abbreviated SHA1s, ou abbrevs, soit les 7 premiers caractères seulement. La probabilité de collision de valeurs effectives à 7 caractères de SHA1 est infinitésimale (je ne suis pas expert, mais ça doit plafonner à 2⁻¹³², ce qui revient à dire que tu as à peine moins de chances de tomber sur un atome précis parmi tous ceux qui composent la Terre, nous inclus ; moi je dis, risque acceptable).

Histoire que même un bête git log sans options particulières se limite à ça, j’active log.abbrevCommit.

Des fusions plus pratiques

Si Git nous fournit effectivement pléthore de mécanismes afin de résoudre au mieux un conflit de fusion, il reste possible d’améliorer les comportements par défaut.

Ainsi, Git injecte dans les fichiers textuels des marqueurs de conflit classiques. Par exemple :

1
2
3
4
5
6
7

<body>
<<<<<<< HEAD
  <h1>Super site de gros bills</h1>
=======
  <h1>Super site de malades</h1>
>>>>>>> feature
</body>

Il est déjà possible d’obtenir davantage d’informations à ce stade, en affichant entre les deux (la branche récipiendaire de la fusion et la branche en cours de fusion) la version du texte dans l’ancêtre commun (le point de divergence). C’est le mode diff3, que j’active automatiquement avec le réglage merge.conflictStyle :

1
2
3
4
5
6
7
8
9

<body>
<<<<<<< HEAD
  <h1>Super site de gros bills</h1>
||||||| merged common ancestors
  <h1>Super site de oufs</h1>
=======
  <h1>Super site de malades</h1>
>>>>>>> feature
</body>

Par ailleurs, lorsqu’on recourt à un outil de résolution de conflits (un mergetool), celui-ci peut générer des fichiers temporaires ou de sauvegarde (souvent avec des extensions genre .rej, .orig, .local, .tmp, .bak…), qui viennent joyeusement pourrir votre working directory. Même si ces extensions sont protégées contre un ajout par inadvertance à l’aide d’un .gitignore ou équivalent, les fichiers restent là.

Vous pouvez vous assurer que votre outil va nettoyer derrière lui en désactivant les réglages mergetool.keepBackup et mergetool.keepTemporaries.

Pour finir sur les mergetools, lorsqu’on lance git mergetool, il demande par défaut confirmation quant au fichier à manipuler. Afin de vous éviter cette question le plus souvent superflue, désactivez mergetool.prompt.

Un autre sujet important, sur lequel j’écrirai un article un de ces jours, est Rerere. Cette fonctionnalité avancée de Git permet d’enregistrer (localement) des empreintes de conflits et les résolutions manuelles que vous leur avez apportées, pour ré-utiliser automatiquement ces résolutions par la suite. C’est extrêmement pratique et permet des workflows très puissants. Je vous invite à aller explorer la doc à ce sujet, et si vous souhaitez vous en servir, vous n’aurez qu’à activer rerere.enabled et, si vous souhaitez mettre automatiquement dans le stage ces résolutions automatisées, rerere.autoupdate.

Des pulls en rebase par défaut

J’écrirai prochainement un article détaillé sur les raisons pour lesquelles j’estime que l’immense majorité des pulls devraient utiliser un rebase plutôt qu’un merge. En gros, il s’agit d’éviter de pourrir l’historique quand on est à plusieurs à committer en même temps sur la même branche partagée.

La commande git pull est en fait une séquence de deux commandes plus spécifiques : git fetch suivie de git merge. Par exemple, si vous êtes sur master avec un remote par défaut origin, git pull revient à faire :

1. git fetch
2. git merge origin/master

Quand vous bossez à plusieurs sur la branche, il est le plus souvent préférable de faire l’équivalent de :

1. git fetch
2. git rebase origin/master

Git anticipe ce scénario et vous le permet avec git pull --rebase. Toutefois, il devrait s’agir à mon sens du cas général, et non du cas particulier. Il est en effet devenu possible de bosser ainsi en activant l’option pull.rebase.

Le seul danger potentiel, c’est qu’un rebase, par défaut, « inline » les fusions. C’est ajustable quand on git rebase manuellement, mais pas dans le cadre d’un pull. Prenons un exemple.

Disons que vous venez de procéder à une fusion légitime sur votre branche locale (par exemple, la branche feature était terminée et vous avez procédé à son rapatriement sur master à l’aide d’un git merge feature).

Le push vous est refusé car il s’avère que le master distant (origin/master) a bougé. Pas le choix, vous faites un pull avant de continuer. Si celui-ci est en mode rebase, vous allez automatiquement rebaser l’historique local récent (les commits depuis votre ancienne référence origin/master, dont votre commit de fusion) sur le nouveau origin/master. En temps normal c’est top, mais sur ce coup ça va inliner la fusion en remplaçant le true merge par un rebase. La branche, jusqu’ici bien visible dans le graphe du log, va disparaître.

Ma recommandation est la suivante :

1. Si vous vous apprêtez à fusionner une branche et que vous avez l’excellente habitude de nettoyer votre historique local avant de pusher, faites-le dès maintenant (vous ne pourrez plus le faire après sans inliner la fusion).
2. Pullez ensuite immédiatement, en mode rebase. Ce sera toujours ça comme risque en moins pour après.
3. Effectuez la fusion.
4. Pushez immédiatement ; si un petit malin a remis à jour le remote entre-temps, au pire, faites un git pull --no-rebase juste pour cette fois. L’historique ne sera pas bien joli, mais bon.

À noter que le recours à Rerere (voir plus haut) permet de préparer la fusion à l’avance (en résolvant d’éventuels conflits), puis l’annuler, et dans le cadre de la séquence ci-dessus, d’être certain que l’étape 3 sera très courte, laissant d’autant moins de temps aux copains pour refaire bouger le remote.

Des pushes plus ciblés

Par défaut, git push tente de publier toutes vos branches homonymes au remote. S’il m’arrive très rarement d’avoir de nouveaux travaux sur plusieurs branches en local qui soient trackées sur le remote, et donc d’avoir besoin de ça, il m’arrive en revanche régulièrement de tomber dans le scénario suivant :

1. Je dois collaborer quelques temps à la branche feature : je git checkout feature, ce qui cale une branche locale trackée sur la distante.
2. Je bosse, je committe, je pushe, tout roule…
3. Au bout d’un moment, soit ça fait un bail que je ne bosse que sur feature et mon master prend du retard sur le distant, soit j’ai fini avec feature jusqu’à nouvel ordre, je repasse sur master et au bout d’un moment ma feature locale est en retard sur la version distante.

À ce moment-là, chaque push va me taper dessus en rejetant la ou les branches en retard. C’est assez pénible, parce que je ne cherche pas en fait à pusher ces branches, je les ai juste en local et je rebosserai sans doute dessus plus tard. C’est le mode matching, qui comme le dit la doc n’est pas approprié à un environnement multi-développeurs, mais est (jusqu’à Git 2.0 en tout cas) le mode par défaut.

En réglant push.default à upstream, je change le comportement par défaut de push afin qu’il ne se préoccupe que de la branche active. C’est une variante plus flexible du mode simple, qui exigerait que les branches locale et distante soient non seulement connectées (tracking) mais homonymes. À noter que ce mode simple sera le mode par défaut à partir de Git 2.0.

En conclusion…

Bon, voilà une bonne chose de faite ! Pensez à jeter un œil aux notes de version quand vous mettez à jour votre Git, et surtout à regarder de temps en temps ce qu’on trouve dans git help config, qui liste tous les réglages proposés, ou simplement si le git help de votre commande en cours ne fournit pas une section CONFIGURATION sur la fin, qui cible les réglages associés. On y apprend toujours plein de choses…

Bonne config à tous !

Envie d’en savoir plus ?

Nos formations Git au Quotidien explorent en profondeur les questions de configuration, de prompt et d’options avancées ou méconnues pour les commandes même les plus simples. Une excellente façon d’aller bien au-delà de ces quelques réglages !

1. Git au Quotidien le 26/03 (plus qu’une place)
2. Git au Quotidien le 26/04
3. Git Avancé le 22/05
4. Git au Quotidien le 20/06

N’attendez pas ! Demandez rapidement vos conventions pour ces dates !

Et si vous avez un besoin suffisant en intra-entreprise, rejoignez les nombreuses sociétés qui ont déjà fait une formation Git Quotidien ou Git Total en interne : faites une demande de formation intra / sur mesure.

1. Git au Quotidien le 29/01
2. Git Avancé le 30/01 (reporté au 27/03)

En revanche, en raison d’un nombre d’inscriptions véritablement trop faible d’une part, et de besoins intra-entreprises trop forts d’autre part, nous avons dû annuler préemptivement la session Git Total du 04 au 05/12.

Quant à la session Git Avancé du 27/11 prochain, elle va devoir être annulée si elle ne se remplit pas davantage d’ici mardi 20 ! N’oubliez pas que les sessions de 2012 font l’objet d’une promotion en ce moment :

• -20% sur Git au Quotidien le 20/11
• -30% sur Git Avancé le 27/11

Il vous suffit de préciser le code GITQLM dans votre demande de convention. Profitez-en !

N’attendez pas ! Demandez rapidement vos conventions pour ces nouvelles dates !

À partir de la semaine du 19/11/2012, les formations Attitude vont passer à la vitesse supérieure. Dans la pratique, cela signifie :

• De nouveaux ateliers
• (Beaucoup) plus de dates et un lieu de formation au top
• Plus d’articles didactiques sur le site
• Une nouvelle plate-forme intégrée pour présenter les formations, gérer les inscriptions, permettre les évaluations et commentaires, accéder aux ressources pédagogiques, demander des conventions de formation, etc.

De nouveaux ateliers

Comme annoncé il y a quelques semaines sur Twitter, l’automne-hiver 2012 voit l’apparition d’un nouvel atelier au catalogue Git Attitude : Git Total.

Décliné en versions 2 jours et 3 jours, il combine les ateliers classiques Git au Quotidien et Git Avancé. Le format 3 jours donne davantage de temps aux exercices autonomes et à l’expérimentation personnelle, afin de renforcer l’assimilation immédiate des savoirs.

D’autres ateliers devraient ouvrir sur le premier semestre 2013, autour notamment de Github et, séparément, de l’hébergement privé de dépôts Git. En attendant, nous vous invitons à regarder le détail des pages des ateliers pour découvrir les programmes détaillées, le lieu de formation, les tarifs et dates, etc.

Nouveau planning, nouvel endroit !

Historiquement, les sessions Attitude inter-entreprises se sont toujours tenues le samedi, presque exclusivement dans les locaux de Clever Age Paris, boulevard des Capucines, à deux pas d’Opera. Nous tenons d’ailleurs à les remercier encore une fois chaleureusement pour ce gentleman’s agreement qui aura duré plus de 2 ans et sans lequel les formations Attitude n’auraient peut-être pas connu le succès qui est le leur aujourd’hui.

Toutefois, cette contrainte de planning (samedi seulement, une journée maximum) posait problème à de nombreux stagiaires potentiels, et limitait la gamme des ateliers proposables.

Toutes les sessions seront en semaine dans notre nouveau lieu. Jusqu’à nouvel ordre, elles se tiendront entre le mardi et le vendredi.

La barre latérale du site (ou sur mobile, le bas de page) listent à tout moment l’ensemble des dates prévues, avec le cas échéant un indicateur de places restantes (s’il en reste 4 ou moins). À ce jour, les dates suivantes sont proposées :

1. Git au Quotidien mardi 20/11
2. Git Avancé mardi 27/11
3. Git Total (format 2 jours) mardi 04/12 et mercredi 05/12

Aucune session n’est prévue sur la dernière semaine de décembre ; passez donc les fêtes avec proches, que diable !

Par ailleurs, à compter du 20/11/2012, nous serons également beaucoup plus disponibles pour des formations intra-entreprises et/ou sur-mesure. Là aussi, la sidebar et une page dédiée vous informent et vous permettent de nous contacter sur ce sujet.

Parlons à présent du nouvel endroit dans lequel auront lieu les formations Attitude.

Nous avons longuement cherché un endroit qui corresponde à nos exigences et à l’esprit des formations : décontracté, agréable et professionnel. Nous avons donc été emballés en découvrant et visitant l’espace La Rochefoucauld du Groupe Formeret.

Le Groupe Formeret ne fait qu’une chose et le fait manifestement très bien : héberger des formations, séminaires, examens, etc. Leurs 4 lieux sont impeccables, parfaitement accessibles à tous, conviviaux et lumineux. À leur rencontre, on sent tout de suite leur volonté de bien faire et de fournir un service d’excellente qualité. Nous espérons avoir trouvé en eux un partenaire de confiance sur la durée.

Nous avons choisi en priorité l’espace La Rochefoucauld en raison de sa situation géographique (Notre-Dame de Lorette / Saint-Georges, presque aussi central qu’Opéra) mais aussi du cachet du lieu (très calme, entouré de verdure, avec une vue imprenable sur le Sacré-Cœur) et de sa taille, qui permet d’éviter un effet « grands bureaux ».

La formation se déroule dans une salle privative climatisée, lumineuse, fonctionnelle et très confortable. L’ensemble des locaux sont facilement accessibles en transports en commun et classés ERP, notamment accessibles aux Personnes à Mobilité Réduite.

Espace La Rochefoucauld
11 rue de La Rochefoucauld
75009 Paris

Situé en plein cœur de Paris, tout près de la Gare Saint-Lazare et d’Opera, il est accessible via pas moins de 6 lignes de métro, 2 lignes de RER et 7 lignes de bus :

• Métro : Saint-Georges, Trinité (ligne 12), St-Lazare (lignes 3, 9, 12, 13 et 14), Chaussée d’Antin (lignes 7 et 9)
• RER : Haussman Saint-Lazare (ligne E), Auber (ligne A)
• Bus : Saint-Georges (67, 74), La Bruyere (74), Trinité (26, 32, 43, 68, 81)

On trouve également nombre de parkings alentour.

Chaque stagiaire amène son propre poste de travail ou ordinateur portable.

L’accès internet est assuré par une connexion fibre très haut débit. La salle fournit un accès Wi-Fi ainsi que des connexions RJ45 pour les postes qui le nécessiteraient.

Plus d’articles didactiques

Jusqu’à présent, le manque de temps ne nous a pas permis de maintenir pour le site Git Attitude l’envergure pédagogique et didactique que nous souhaitions. Des dizaines de sujets d’articles et de didacticiels attendent depuis de nombreux mois d’être rédigés et publiés, et certains articles de référence (installation de Git, hébergément privé…) commencent à être obsolètes. Les articles du site et la timeline Twitter se résumaient pour l’essentiel à des annonces d’atelier et du marketing, et étaient globalement en suspens pendant la période « Clever Institut ».

Si le marketing ne disparaîtra pas tout-à-coup du flux (pour le moment, Twitter et le bouche-à-oreille restent nos seuls canaux de communication et de marketing), les articles d’annonce, eux, n’auront plus cours : les pages détaillées des ateliers existent et contiendront toujours la liste des prochaines dates ; leurs URLs ne changeront pas. Et la sidebar du site reprend ces informations.

En revanche, nous allons prendre de plus en plus de temps pour produire et publier des articles, didacticiels et suggestions de veille technologique, sur un rythme régulier et, nous l’espérons, assez fréquent. Nous espérons qu’ainsi, vous trouverez le site toujours plus intéressant et utile.

Bientôt une nouvelle plate-forme intégrée

Il n’est plus possible pour le moment de vous inscrire directement en ligne, en payant par carte bancaire ou PayPal. Nous travaillons à l’aboutissement d’un projet interne de plate-forme qui va regrouper l’ensemble des services en ligne dont les formations Attitude ont besoin : présentation, suivi des places disponibles, inscription ou demande de convention en ligne, attestations de présence, factures, évaluations par les stagiaires, accès aux ressources pédagogiques et forums de discussion entre les stagiaires passés et les formateurs, etc.

Les sites dédiés (git-attitude.fr, js-attitude.fr, etc.) se concentreront alors sur les contenus didactiques, et recroiseront diverses infos (dont le planning des sessions) avec la plate-forme.

En attendant, vous pouvez naturellement toujours nous faire une demande de convention via le formulaire habituel.

En résumé…

Dès mi-novembre, Attitude passe la 5ème ! Nous espérons vous retrouver nombreux à nos sessions, et que le travail et la passion intenses que nous mettons dans la conception et la tenue de nos ateliers sauront vous séduire.

Parce que nous anticipons des articles de plus en plus riche en codes sources, parce que nous souhaitons enrichir la discussion autour des commentaires et des réseaux sociaux, et parce que nous trouvons le look par défaut beaucoup plus propre que ce qu’on sur le site en place, nous avons passé Git Attitude sur Octopress.

Le catalogue est à l’honneur, au travers de la nouvelle page Tout sur les ateliers et des pages détaillées pour nos formations existantes (parfois remaniées).

Vous trouverez d’ailleurs une liste à jour des dates planifiées des ateliers Git Attitude dans la barre latérale (ou inférieure, sur des affichages étroits), ainsi qu’en bas de chaque page atelier du catalogue. À partir de la mi-novembre 2012, vous aurez jusqu’à 4 jours de formation proposés par mois !

Nous espérons que le nouveau Git Attitude vous plaira. Comme toujours, n’hésitez pas à échanger avec nous via les commentaires en bas de chaque page. À très vite pour des articles et formations du tonnerre !

Sur la même période, j’assurerai par ailleurs en direct, et toujours le samedi pour le moment, les ateliers JS Attitude. Vous trouverez le détail et les dates dans les articles suivants :

• JS Puissant le 12/05/2012 à Paris
• JS Guru le 30/06/2012 à Paris

Au plaisir de vous voir prochainement en atelier !

Les éventuelles formations intra-entreprises restent assurées directement par Delicious Insights.

Nous avons tout récemment ancré les prochaines dates de session pour les deux types d’atelier. Il y en aura une par mois, en semaine (grosse nouveauté !), et nous augmenterons si besoin la fréquence à partir de mai ou juin 2012. Comme pour les sessions en direct, elles sont limitées à 10 places par atelier.

Dans l’immédiat, elles auront toutes lieu sur Paris. Vous pouvez vous inscrire dès maintenant sur les pages concernées :

1. Git au Quotidien le 14/02/2012 (originellement le 21/02)
2. Git Avancé le 23/03/2012
3. Git au Quotidien le 11/04/2012 (mise à jour)

Les premières places partent déjà, je vous invite donc à lancer vos inscriptions le plus tôt possible.

Sur la même période, j’assurerai par ailleurs en direct, et toujours le samedi pour le moment, les ateliers JS Attitude. Vous trouverez le détail et les dates dans les articles suivants :

• JS Puissant les 14/01 et 31/03/2012 à Paris !
• JS Guru le 18/02/2012 à Bordeaux et le 21/04 à Paris !

Au plaisir de vous voir prochainement en atelier !

C’est une formation Git pas comme les autres****.

Vous trouverez tous les détails de l’atelier sur la page Git au Quotidien : programme, esprit, pré-requis technologiques, etc.

Qui est le formateur ?

L’atelier est assuré par Christophe Porteneuve (bonjour, c’est moi !).

Après plus de 15 ans à utiliser des gestionnaires de source divers, et pour finir quelques millions de lignes de code gérées avec Subversion, je me suis mis à Git en 2008 dans le cadre notamment de mes contributions à Rails, Prototype et script.aculo.us. Vers 2009, j’ai décidé d’y aller pour de bon et d’explorer en profondeur les tenants et aboutissants de cet outil, afin d’en tirer toute la puissance possible. En juin 2010, à force de discussions, je réalise qu’aucune formation Git n’existe apparemment en France (en tout cas aucune qui retienne l’attention…) et je lance Git Attitude.

Vous pouvez me retrouver sur Twitter, LinkedIn et Github.

J’ai par ailleurs plus de 6 000 heures de formation derrière moi, dont plus de la moitié dans le cadre de la formation professionnelle des adultes. J’adore transmettre, en fait, et les bouquins et conférences sont un prolongement de ça.

Vous vous ferez votre propre idée naturellement, mais ce qu’il faut retenir et que je peux vous garantir : je sais de quoi je parle quand je parle de Git, et je sais transmettre la connaissance.

Les ateliers Attitude se déroulent tous dans une atmosphère studieuse et experte, mais détendue et cordiale. On apprend, on s’émerveille parfois, on a des illuminations parfois, et on rigole souvent. Demandez donc aux stagiaires précédents (via Twitter avec le hashtag #gitattitude par exemple).

Où, quand, comment, combien ?

Ça se passe chez Clever Age Paris (le partenaire de longue date des ateliers Attitude), au 37 bd des Capucines 75002 Paris. C’est à deux pas d’Opera, super facile à rejoindre en transports en commun et depuis les principales gares parisiennes.

C’est samedi 19 novembre 2011, de 9h30 à 19h.

Chacun amène son portable avec une alimentation, et nous fournissons le reste (petit-déjeuner, déjeuner, boissons, café, Wi-Fi, etc.)

L’atelier coûte 300€ HT, et fait naturellement l’objet d’une véritable facture par Delicious Insights, la société qui produit les ateliers Attitude. On peut s’inscrire en ligne et payer l’intégralité ou juste l’acompte de 30%, suivant son mode de fonctionnement. Ceux qui sont soumis à un process d’entreprise à l’ancienne peuvent s’inscrire hors-ligne et payer l’acompte par virement bancaire. Tous les détails sur les modalités de paiement sont dans les informations générales.

Du coup, vous pouvez le financer un peu comme vous voulez :

• DIF
• Crédit d’impôt au titre de la formation
• Facture de prestation classique
• …et prochainement OPCA (nous attendons notre numéro d’agrément formateur pour pouvoir le proposer)

C’est pas un peu cher, ça ?

C’est sûr que ce n’est plus les 100€ de l’année de rodage, mais la fiscalité française des TPE-PME étant ce qu’elle est, pour être un tant soit peu rentables sur les ateliers, on doit répercuter les innombrables taxes et impôts sur le prix des prestations… Si ça a donc pas mal augmenté avec la rentrée 2011, ça reste plus de deux fois inférieur à la moyenne du marché, qui est aux alentours de 700€ HT. Et j’aurais tendance à dire qu’en plus, la formation est nettement meilleure, justement, que la moyenne du marché.

On essaie de rester aussi accessibles que possible dans ce nouveau contexte fiscal, mais on doit quand même essayer de gagner de l’argent. Voilà, vous savez tout !

Super, je m’inscris !

Vous avez mille fois raison :-) Pour la version en ligne immédiate et rapide, c’est par ici. Pour les modalités d’inscription hors-ligne, c’est par là.

Des questions ?

N’hésitez pas à nous contacter, soit par commentaire sur cet article, soit par e-mail à inscriptions AT delicious TIRET insights POINT com.

Inscrivez-vous rapidement, il n’y a que 10 places et la demande est forte pour cette prochaine session !

Au plaisir de vous voir le 19 novembre prochain.

Delicious Insights

Les formations sont désormais dispensées dans un cadre formel et professionnel parfaitement défini : au travers de ma nouvelle société, Delicious Insights.

Évidemment, cela veut dire que, si nous avons décidé de rester abordables, la fiscalité invraisemblable des TPE et PME en France nous a toutefois contraint à abandonner le joli rêve des 100/150€. Les formations sont désormais à 300€ HT pour JS Puissant et 450€ HT pour JS Guru. Ça reste très inférieur aux tarifs moyens du marché (environ 700€ HT), sans parler de l’écart de qualité, que je vous laisse juger.

En revanche, cela signifie aussi que les financements de ces formations ne sont plus cantonnés aux notes de frais et cartes bancaires personnelles ! Puisque vous disposez désormais d’une facture tout ce qu’il y a de plus officiel, vous voilà à même d’utiliser les financements que vous souhaitez : prestation classique, DIF, crédit d’impôt et prochainement OPCA ! Ce qui rend les choses singulièrement plus simples pour la majorité de mes clients et prospects, qui sont des entreprises et non des particuliers.

Où, quand, comment ?

Dans les prochaines semaines, nous allons mettre en place le site de Delicious Insights et commencer à consolider l’ensemble de notre présence en ligne autour de la formation : Git Attitude, JS Attitude et Mon Attitude vont se rejoindre sur un nouveau serveur, homogénéiser un peu leurs identités visuelles avec celle de Delicious Insights, et bénéficier d’une plate-forme intégrée de proposition de sessions, consultation des dates, inscription, paiement, retour d’expérience et témoignage des stagiaires.

Pour encore quelques semaines, le paiement en ligne reste traité via Stage et Paypal, mais ça va changer. Et le paiement hors-ligne par bon de commande et virement et d’ores et déjà accepté. En revanche, on ne prend pas les chèques.

Quant aux sessions proprement dites, elles vont se dérouler suivant les principes que voici :

1. Jusqu’au 31/12/2011, uniquement le samedi, en direct par Delicious Insights. Les 4 sessions sont déjà planifiées : une Git et 3 JS. Les dates et lieux sont plus bas dans cet article.
2. À partir du 01/01/2012 et jusqu’au 31/03/2012 au minimum, les ateliers JS Attitude se tiendront toujours un samedi par mois, et les ateliers Git se tiendront environ un jour ouvré par mois, dans le cadre du Clever Institut, dont nous assurerons la partie Git du catalogue. Par ailleurs, le contenu des ateliers va progressivement être mis à disposition sous une forme alternative : des screencasts ciblés, de 30 à 60 minutes, proposés en ligne à un tarif attractif.
3. Ensuite, il va se passer plusieurs choses :
   • des prestations intra-entreprises sur mesure vont devenir possibles,
   • Delicious Insights proposera jusqu’à 4 sessions par mois au lieu de 2,
   • un cursus de formations Ruby On Rails sera proposé (sessions de 2 à 3 jours, 3 à 5 sessions distinctes prévues),
   • l’offre JavaScript s’enrichira d’au moins quatre nouveaux ateliers sur les technologies de test automatisé, de documentation, NodeJS et CoffeeScript.

Comme vous pouvez le voir, 2012 va être une année exceptionnelle pour la formation Attitude !

Les ateliers continuent naturellement à intégrer petit-déjeuner et déjeuner dans leurs tarifs.

Les fiches de formation et conditions générales

Git Attitude, comme JS Attitude, est désormais doté d’onglets permanents pour ses ateliers, ainsi que d’un onglet Informations générales.

Les premiers proposent les fiches de formation détaillées, ainsi qu’un accès à une fiche PDF complète dotée des informations générales en sus et d’un bon de commande, pour ceux qui souhaiteraient ne pas payer en ligne.

Les informations générales, reprises dans chaque fichier PDF de fiche formation (sauf Git Avancé, assuré uniquement via Clever Institut pour le moment et donc sujet à leurs propres modalités), vous disent tout ce que vous voulez savoir sur les modalités d’inscription en ligne et hors-ligne, les conditions d’annulation et de remboursement, le règlement intérieur, etc. On fait ça au cordeau, en pleine conformité avec les sections concernées du Code du Travail et les décrets du Conseil d’État relatifs à la formation professionnelle continue.

Les dates de l’automne 2011

Voici les quatre dates de l’automne, toutes le samedi :

1. 24/09/2011 chez Comuto (des gens super sympa qui éditent Covoiturage), à Paris 17e : JS Puissant
2. 22/10/2011 chez Clever Age à Paris 2e : JS Guru (demandez à ceux du 03/07 combien la nouvelle formule est top !)
3. 19/11/2011 chez Clever Age à Paris 2e : Git au Quotidien
4. 10/12/2011 chez Clever Age à Lyon : JS Guru (depuis le temps que les Lyonnais le réclament…)

N’hésitez pas à poser toutes vos questions dans les commentaires.

Cette rentrée et 2012 s’annonce exceptionnelle pour notre activité de formation, et nous sommes impatients de voir comment se déroulent les ateliers déjà rodés et ce que donneront les nouveaux. Excellente année à vous tous !

À la demande générale, le prochain atelier Git au Quotidien aura lieu samedi 11/06/2011 chez Clever Age Paris !

Il y a seulement 16 places, dépêchez-vous de vous inscrire !

Un Atelier Git Attitude, c’est l’occasion de booster immédiatement sa productivité avec Git, ou de découvrir ce merveilleux outil dans les meilleures conditions. En petit groupe, avec un formateur compétent et passionné, sur votre ordinateur portable, vous apprenez la philosophie, les commandes utiles, les bonnes pratiques, les astuces qui changent la vie, et les compétences qui sauvent la journée en cas de pépin ou de besoin complexe.

Les participants aux précédentes sessions sont enthousiastes, comme en témoignent leurs évaluations.

Ça se passe où ?

Nous serons à nouveau hébergés par les Gens Bien™ de Clever Age, au 37, boulevard des Capucines 75002 Paris.

Voir le plan

La journée en un clin d’œil

Cet atelier part de zéro (une connaissance d’un système de version usuel, type CVS ou Subversion, voire d’un autre DVCS type Bazaar, Fossil ou Mercurial, est clairement un plus, ne serait-ce que pour comprendre ce qu’on gagne…).

Dans cet atelier, vous apprendrez notamment toutes les meilleures façons de…

• configurer votre Git aux p’tits oignons
• manipuler votre dépôt localement
• faire des commits ajustés, parfois volontairement partiels, y compris sur des parties de fichier
• gérer votre historique local de commits, en l’amendant si besoin
• travailler avec des tas de branche et les fusionner facilement
• gérer au mieux une urgence qui tombe en plein milieu d’un gros boulot sur le code
• synchroniser avec des dépôts distants
• et plus, bien plus encore !

Le principe est d’aborder en profondeur toutes les commandes examinées ; la plupart des gens sous-utilisent atrocement des fondamentaux comme git add, git diff ou git log, ou encore ignorent tout des merveilles de git reset. Cet atelier donne d’entrée de jeu nombre de clés inestimables pour être redoutablement efficace dans sa gestion de sources au quotidien.

En plus de ça, vous avez droit à un petit-déjeuner, un déjeuner convivial dans un restaurant sympathique, du café (Nespresso !), du thé (équitable !) et des boissons fraîches à volonté…

Tout ça pour seulement 75€ ! (en early bird ; 100€ en tarif plein)

Comme le disent des participants passés, c’est « tellement pas cher que je n’en reviens pas » !

Alors n’hésitez plus, et rejoignez-nous dès aujourd’hui pour cette session Git au Quotidien !

Il existe naturellement des demandeurs qui n’ont encore qu’une expérience très réduite (voire inexistante) de Git, et attendent du coup de pouvoir assister à un atelier Git au Quotidien pour ensuite faire leurs dents sur quelques projets avant de venir à Git Avancé.

Cependant, il existe aussi de nombreux « Git’ers » en France (pour ne pas dire en francophonie), qui ont une utilisation quotidienne équivalente, voire un peu au-delà, de ce premier niveau d’atelier. Peut-être ne sont-ils pas très à l’aise avec git reset ; peut-être n’ont-ils jamais utilisé git add -p ni git rebase -i. Mais cela ne les empêche pas d’être à l’aise avec les notions fondamentales de Git (working tree, stage, index), d’utiliser sans problème les syntaxes classiques de git add, git commit, git log, git push, git pull, git branch et git checkout.

Et ce niveau simple de pratique de Git suffit amplement pour attaquer Git Avancé et en tirer le meilleur parti

L’atelier Git Avancé est d’abord là pour approfondir les commandes fondamentales, notamment en explorant les plus utiles de leurs options méconnues (et il y en a de nombreuses qui recèlent de véritables trésors de productivité). Rien que là, il est possible de réaliser un incoryable gain de temps dans ses tâches usuelles.

Au-delà de ça, l’objectif fondamental de l’atelier est de transmettre des meilleures pratiques adaptées à de nombreuses situations, parfois fréquentes, parfois plus rares mais bien épineuses… Voici une petite liste, comme ça au débotté, des questions auxquelles cet atelier tente d’apporter une réponse :

• Comment factoriser une codebase entre plusieurs projets ? Vaut-il mieux utiliser des dépôts imbriqués ou des submodules ?
• merge ou rebase ? Pourquoi ? Dans quels cas ?
• Si on est plusieurs à travailler sur un même dépôt, quels workflows sont les plus adaptés ? Combien de dépôts distants utiliser ?
• Comment bien gérer la mise à jour des submodules et leur propagation raisonnée ?
• Comment je fais pour retomber sur mes pattes après que l’autre andouille ait cassé l’historique distant ?
• J’aurais dû faire une branche plus tôt… Comment je récupère le coup ?
• J’ai committé par mégarde des fichiers confidentiels ou sensibles : je peux en effacer toutes les traces, historique compris ?
• Comment fusionner un commit seul, sans se farcir pour autant son historique ?
• Comment déterminer quels commits ont déjà été fusionnés d’une branche A dans une branche B ?
• Tags, branches… master/develop/production… Qu’est-ce qui marche comme organisations ?
• J’ai paumé un commit en jouant trop avec git reset ! Comment le retrouver ?
• Comment exécuter des tâches automatiquement à chaque commit ou à chaque push ?
• Je viens de faire une résolution manuelle de fusion bien galère… Comment éviter à mes collègues de se galérer pareil s’ils fusionnent la même branche ?
• Je viens de repérer un bug qui ne date pas d’hier mais n’était pas là y’a un mois… Comment trouver quel commit l’a introduit ?
• J’en ai ras le c… de l’éditeur pourri de Jean-Kevin qui me fout des TAB et laisse plein d’espaces en fin de ligne… Est-ce qu’on pourrait pas nettoyer tout ça automatiquement chaque fois qu’un fichier texte est committé ?
• J’ai plein de taf en cours dans le WT qui m’empêche de faire un pull, mais c’est trop pas prêt à être committé ! Qu’est-ce que je peux faire ?

Bref, Git ça torche, il est temps d’arrêter de s’en servir à peine mieux que si c’était Subversion.

Alors n’hésitez plus et courrez vous inscrire pour le 19 février. C’est dans même pas 3 semaines !

La première session Git Avancé aura lieu samedi 19 février 2011 chez Clever Age, à Paris, de 9h30 à 19h30.

Il y a seulement 16 places, dépêchez-vous de vous inscrire !

Un Atelier Git Attitude, c’est l’occasion de booster immédiatement sa productivité avec Git, ou de découvrir ce merveilleux outil dans les meilleures conditions. En petit groupe, avec un formateur compétent et passionné, sur votre ordinateur portable, vous apprenez la philosophie, les commandes utiles, les bonnes pratiques, les astuces qui changent la vie, et les compétences qui sauvent la journée en cas de pépin ou de besoin complexe.

Les participants aux précédentes sessions sont enthousiastes, comme en témoignent leurs évaluations.

Ça se passe où ?

Nous serons à nouvceau hébergés par les Gens Bien™ de Clever Age, au 37, boulevard des Capucines 75002 Paris.

Voir le plan

La journée en un clin d’œil

Cet atelier s’adresse aux personnes déjà bien rompues à Git (d’un niveau similaire à celui, déjà pas mal du tout, procuré par notre session Git au Quotidien), et qui souhaitent pousser plus loin. Voici un aperçu des sujets qui seront triturés dans tous les sens :

• Tout sur les submodules : les ajouter, les modifier, les mettre à jour, éviter les pièges et erreurs usuelles…
• Pas mal de choses sur le boulot à plusieurs : gérer des dépôts distants multiples, tirer parti du rebase, etc.
• Partager une résolution manuelle de conflits avec git rerere
• Traquer automatiquement la source historique d’un bug avec git bisect
• Récupérer un commit éjecté de l’historique avec git reflog
• Peaufiner les comportements de Git avec les Attributs
• Utiliser les hooks pour automatiser des traitements
• Annoter les commits avec git notes
• …

En plus de ça, vous avez droit à un petit-déjeuner, un déjeuner convivial dans un restaurant sympathique, du café (Nespresso !), du thé (équitable !) et des boissons fraîches à volonté…

Tout ça pour seulement 100€ ! (en early bird ; 150€ en tarif plein)

Comme le disent des participants passés, c’est « tellement pas cher que je n’en reviens pas » !

Alors n’hésitez plus, et rejoignez-nous dès aujourd’hui pour la première session Git Avancé !

Dans les couloirs de l’édition 2010 de Paris-Web, on m’a proposé des locaux d’accueil pour les ateliers à Nantes, Bordeaux, Lyon, Strasbourg et Nîmes. Voilà de quoi bien couvrir l’hexagone ! Git Attitude Corp. n’est pas loin…

Toujours dans ces fameux couloirs, une belle idée s’est fait jour : il faut lancer les Ateliers JS Attitude. En effet, voilà un autre domaine où des formations de qualité font cruellement défaut, notamment en francophonie, et où je me trouve être expert (reconnu, en plus !)

Je suis donc en train de mettre sur pied js-attitude.fr (patience, ça arrive, c’est pas encore là du tout…) et j’ai déjà la structuration des ateliers en tête. Comme le domaine dédié n’est pas encore équipé-avec-toutes-les-options, je les annonce ici :

• Niveau 1 : JS Solide. S’adresse à pratiquement tout le monde sauf les gens déjà capables, par exemple, de contribuer utilement à un framework établi. Si tu es fort en jQuery, tu n’es pas fort en JS pour autant, par exemple. Au menu, entre autres : module pattern, méthodes méconnues des types natifs (notamment Number), pièges classiques, ES4 vs. ES5 vs. Harmony, accès DOM, tâches fréquentes, savoir trouver et utiliser les bonnes docs, meilleures pratiques diverses…
• Niveau 2 : JS Avancé. Niveau 1 indispensable. On entre dans beaucoup de détails techniques, d’optimisation et de performances, d’outils de concaténation/minification/structuration (Sprockets, YUI Compressor, Clojure…), de tâches complexes, de sécurité, et bien entendu on parle des principaux frameworks, sur desktop et mobile.
• JS en Vrai. Même principe de travail sur études de cas réelles, issues des projets des participants, que pour les ateliers Git en Vrai.
• JS Côté Serveur. JavaScript domine le monde ! :-) Et JS côté serveur, avec notamment Node.js (basé sur V8) mais aussi Rhino, Squirrelfish Extreme et la JSC d’OSX, et plein d’autres choses, nous permettent d’utiliser cet extraordinaire langage côté serveur, ou simplement hors du navigateur (pour tester un bout de code vite fait). Il y a plein de belles choses à faire !
• JS Blindé. JavaScript n’est PAS un langage jouet, loin s’en faut, et à ce titre rien ne justifie qu’on soit plus laxiste en développant du JS qu’en développant autre chose. Heureusement, il existe d’excellents outils de tests (unitaires, fonctionnels et d’intégration) et de doc, qui nous permettent de fournir à notre code JS une couverture de tests et une doc d’API digne des meilleures codebases. Cet atelier se penche sur QUnit, JSUnit, Evidence, JsDoc, PDoc et d’autres outils du même genre pour fournir des réponses concrètes sur ces sujets importants.

Ce qui est important, c’est que j’ai mis en place un Doodle où vous pouvez indiquer votre intérêt pour les divers ateliers Git Attitude et JS Attitude, ainsi que pour les lieux déjà prévus. Je vous demande deux choses quand vous y participez.

• Primo, indiquez votre e-mail ou au moins votre Twitter ID, histoire qu’on puisse facilement vous recontacter.
• Secundo, n’indiquez votre intérêt que s’il est « réel », c’est-à-dire si vous seriez effectivement prêt(e) à payer votre place pour un tel atelier (les tarifs allant de 100€ à 300€ pour la journée, suivant que c’est à Paris ou en Province, et plus ou moins avancé ou complexe à préparer). Je ne vous forcerai naturellement jamais la main, mais cela me permet d’avoir des « prévisions » plus fiables et de ne pas me retrouver le bec dans l’eau, à ne même pas rentrer dans mes frais…

Et naturellement, vous avez les commentaires, comme toujours, pour participer plus avant. Et Twitter, en mention, retweet, etc. pour colporter la bonne nouvelle et échanger « en live » avec @gitattitude et @jsattitude !

J’ai hâte de lire vos retours.

Ça vient, ça vient, seulement voilà : d’une part, ce mois-ci j’ai fait un peu de boulot freelance pour compenser le coût de mon passage à JSConf.eu, et d’autre part, je donne deux ateliers très chronophages à Paris-Web 2010, qui se tiendra dans… 2 semaines !

Donc, le peu de temps perso que j’ai, je le passe là-dessus. Pour le moment. Promis, à partir du 18/10, je remets le focus sur Git Attitude.

En vertu de quoi, la matinée, et le début de l’après-midi, reprennent les bases en détail (en y entrelaçant des usages bien avancés quand même, genre git add -p).

Seulement voilà, il y a beaucoup plus à faire ! J’ai entre autres envie de monter les ateliers suivants :

• Git Avancé : les submodules, rerere, bisect, reflog et ses amis, notes, les attributs Git, les remotes multiples, etc.
• Git En Vrai : toute la journée passée à résoudre des études de cas concrètes, issues des projets des participants (envoyés à l’avance pour validation et recherche d’optimalité)
• Git Chez Soi : tout sur l’hébergement et l’administration (gitosis, git-daemon, gitweb, GitHub avancé, hooks et plugins d’interfaçage, etc.)

Par ailleurs, j’ai envie de permettre aux développeurs non parisiens, et même non francophones, d’accéder à tous les ateliers. Pour cela, deux voies :

• Ouvrir des sessions en anglais (des francophones à l’aise en anglais peuvent naturellement s’inscrire) ; je peux les assurer sans souci.
• Ouvrir des sessions hors de Paris ; ce deuxième point nécessite toutefois un coût d’entrée un peu plus élevé, car j’ai des frais supplémentaires (transport et hébergement). L’idée est de trouver une ville susceptible de rassembler une session “pleine” (au moins 10 personnes payantes), et une gentille structure capable de nous héberger pour la journée, moyennant une ou deux places gratuites et la pub que je lui fais lors des annonces, etc. Dans cet esprit, on m’a déjà ouvert les bras à Lyon. Qui serait partant pour un atelier à Lyon ?

Pour le moment, je réfléchis à tout ça. Si ça décolle, il faudra que je mette en ligne un système de pré-inscription histoire de voir quand on atteint une masse critique justifiant la mise en œuvre de tel type d’atelier dans telle ville… Mais ça peut se faire, il suffit d’un peu de bonne volonté de la part de tous.

J’attends impatiemment vos commentaires, suggestions, retours, etc. sur les types d’ateliers que je décris, et sur Git Attitude hors de Paris ! Le blog est là pour ça, allez-y ! (commentaires modérés, mais je fais vite)

• On est en train de passer un dépôt de Subversion vers Git, en vue d’abandonner le premier au profit du second (yay !).
• On est obligé de bosser sur un dépôt Subversion, mais on refuse de laisser tomber le confort quotidien de Git en local.

Git propose une passerelle au moyen de la commande git svn et de ses sous-commandes. Moyennant quelques précautions d’usage, on peut ainsi travailler avec Git en local et synchroniser vers (et depuis) le dépôt Subversion distant. C’est un sujet assez vaste et j’y reviendrai plus en détail dans un prochain billet.

Toutefois, ceux qui rencontrent déjà ces situations ont sans doute remarqué un phénomène irritant : Git ne prend pas en compte la propriété svn:ignore. En fait, il ne prend en compte que svn:executable (ce qui est déjà pas mal, vu comme elle est grave utile…).

La propriété svn:ignore est similaire au fichier .gitignore : elle permet de lister des motifs de fichiers qui ne doivent pas être versionnés. Il est donc dommage qu’on n’en bénéficie pas automatiquement sur Git, risquant ainsi de versionner par erreur des fichiers qui devraient être ignorés.

Voilà pourquoi j’ai développé un petit outil qui va automatiquement synchroniser vos svn:ignore vers vos .gitignore, à tout moment, pour votre master (c’est-à-dire votre trunk distant), sans écraser d’éventuelles infos déjà présentes dans vos .gitignore… C’est le premier d’une série probable de petits scripts du même genre, destinés à faciliter l’utilisation de Git au quotidien.

Comme mon récent outil git-basecamp, il est disponible en open-source, et documenté, sur GitHub. Je vous invite donc à jeter un œil à mon dépôt git-helpers. Notez qu’il existe aussi une quantité de dépôts nommés « git-tools » sur Github, mais aucun de ceux que j’ai regardés n’avait cette fonctionnalité (et la plupart des aides qu’ils fournissent m’ont semblé un peu basiques…).

Enjoy !

Comme je suis sympa, tous ceux qui ont participé recevront par DM Twitter (pourvu qu’ils suivent @gitattitude…) un code de réduction -20% à utiliser le plus vite possible, car l’atelier, c’est samedi !

Ce billet tente de vous donner toutes les clés (ahem) pour comprendre et manipuler aisément vos identités SSH.

Après un topo rapide sur le principe des clés asymétriques, nous verrons rapidement quels algorithmes sont à favoriser, quelles tailles de clé sont acceptables, et les meilleures pratiques de protection de vos clés (tant en termes de passphrase que de gestion des droits d’accès à vos fichiers de clés).

Ces fondamentaux étant assimilés, nous pourrons vérifier si vous avez déjà des clés, comment en créer de nouvelles, et comment vous en servir efficacement et confortablement pour vos accès à des dépôts Git.

Principe des clés asymétriques

Quand vous travaillez avec des clés asymétriques, par principe, vous avez deux clés (on parle de paire de clés) : une clé publique, que vous pouvez diffuser librement, voire mettre à disposition sur un serveur de clés ; et une clé privée, qui constitue véritablement votre « identité », et ne doit jamais être diffusée : elle reste simplement présente dans votre dépôt de clés personnel.

Comme toujours en cryptographie, on peut faire deux choses avec une clé : chiffrer un contenu (l’encrypter) ou le signer (calculer une valeur unique, reposant sur le contenu concerné et sur votre clé privée, pour obtenir une valeur de signature, comme un cachet spécifique). Seule la clé « d’en face » (la publique si vous avez utilisé la privée, et inversement) permet de déchiffrer ou de vérifier la signature. Notez au passage que signer un contenu permet non seulement d’attester que vous êtes bien l’envoyeur (ou l’auteur, etc.), mais aussi que le contenu n’a pas été modifié après signature.

Une paire de clé permet donc de vous représenter vis-à-vis d’un système tiers, en lui fournissant à l’avance votre clé publique, pour ensuite communiquer avec lui à l’aide de votre clé privée ; puisque seules les clés d’une même paire peuvent se comprendre, le système distant est à même non seulement de vérifier que vous êtes bien celui (ou celle) que vous prétendez être, mais aussi que ce qu’il reçoit est bien ce que vous envoyé. Pas mal !

Si le sujet vous intéresse, vous trouverez une tonne d’infos sur Wikipedia. Mais si j’étais vous, je finirais cet article d’abord histoire de ne pas partir sur une tangente…

RSA vs. DSA

Il existe de nombreux algorithmes de chiffrement basés sur des clés asymétriques, mais les deux dominants, et de loin, son RSA et DSA, d’après les initiales de leurs auteurs respectifs. RSA est historiquement le premier, et DSA a été développé plus récemment, comme une alternative alors qu’RSA était encore breveté.

De nombreux didacticiels, articles et documentations exploitent RSA, mais vous pouvez choisir librement RSA ou DSA pour vos clés, du moment que vous utilisez une taille suffisante (voir ci-après).

Taille de clé

Une clé a une taille, exprimée en nombre de bits. Par exemple, les clés exploitées par les certificats de chiffrement des sites web utilisant la protection SSL (vous savez, ces URLs qui démarrent en https://, par exemple votre gestion de compte bancaire en ligne) sont généralement limitées, pour des raisons légales d’origine honteuse, à 256 bits. En revanche, vos propres clés ne font pas (ou plus, suivant le pays où vous vivez) l’objet d’une telle limitation.

À ce jour, une taille de 2Ko, c’est-à-dire 2048 bits (oui, 8 fois plus qu’un certificat bancaire !) est considérée raisonnablement sécurisée pour RSA, en tout cas pour un particulier. En gros, même si la toute-puissante NSA avait envie de casser votre chiffrage pour jeter un œil à ces données, il leur faudrait quelques heures pour y parvenir. Et pour qu’ils daignent vous allouer quelques heures de leur système, vous devez en gros être un très, très gros poisson.

Donc on est tranquilles.

Notez qu’en revanche une clé DSA fait obligatoirement 1024 bits (1Ko). C’est comme ça.

Passphrase

Vous avez certainement l’habitude voir le terme password, c’est-à-dire mot de passe. Et vous avez sûrement déjà rencontré des tas de systèmes, services et outils qui vous demandent de saisir un mot de passe, en lui imposant une taille minimum (ce qui est bien) et maximum (ce qui est parfaitement stupide et contre-productif). À cause de ce maximum, justement, ces systèmes insistent pour que vous mélangiez à loisir majuscules, minuscules, chiffres et symboles, et n’utilisiez pas de termes trop évidents (dates de naissances, prénoms, noms de vos animaux, mots basiques, segments de touches du clavier, etc.).

Du coup, tout le monde se retrouve forcé d’utiliser des mots de passe genre &dF@8^Xy+, qui sont tellement tordus qu’on s’empresse de les noter sur un papier, massacrant instantanément l’utilité du mot de passe en le rendant facile à découvrir en cas de besoin (surtout quand ledit papier est un Post-It™ collé sous le clavier, voire sur l’écran) (ne rigolez pas, je l’ai déjà vu) (plusieurs fois) (en fait, si ça se trouve, vous l’avez déjà fait) (gredin(e) que vous êtes).

Par contraste, une passphrase (pas d’équivalent français satisfaisant à ma connaissance, aussi essayez de le prononcer correctement, genre passfrayz) est une petite phrase, ou tout au moins un morceau de phrase, donc plusieurs mots. Et je dis bien mots, parce qu’en l’occurrence, utiliser de vrais mots et noms ne pose plus guère de problème, dès lors qu’on en a au moins 3 ou 4, surtout s’ils n’ont aucun rapport.

« Mais on m’a toujours dit que des vrais mots Saymal™ ! », me hurlez-vous avec consternation, le sourcil vengeur.

Oui, sauf dans des jolies passphrases. Pourquoi donc ? Parce que le niveau de complexité augmente de façon plus qu’exponentielle au fil des caractères, en particulier quand on commence à découper en mots. En cryptographie, on considère qu’un mot de passe, ou une passphrase, peuvent appartenir à plusieurs niveaux de sécurité, qui correspondent à la difficulté qu’on rencontre pour les casser. La recherche sur le sujet abonde et se met à jour chaque année, notamment au sein de conférences spécialisées comme la célèbre DEFCON.

Je suis assez fan de cet excellent article de Thomas Baekdal, qui illustre bien le sujet. Imaginons une passphrase qu’il faudrait des centaines d’années, voire des millénaires, dans l’état actuel de la technologie la plus avancée, pour casser par un moyen technologique. On qualifie une telle passphrase de « sécurisée à vie » (secure for life). Eh bien, pour obtenir une telle passphrase, il suffit de combiner au moins 3 mots, pas nécessairement sans rapport, pour un total d’au moins une dizaine de caractères. Voici quelques exemples de telles passphrases :

• this is fun (sérieux ! Il faudrait au moins 25 siècles…)
• j’aime les noix de cajou (le système solaire aura déjà implosé d’ici qu’on casse ça…)
• des filles à la vanille
• san pellegrino enterre badoit
• i love to boogie
• tu fais du vb dommage eliane
• entre git et svn j’ai choisi
• plutot crever qu’installer vista
• …

Vous avez immédiatement perçu l’avantage monstrueux d’une bonne passphrase, lecteurs fûtés que vous êtes : non seulement c’est sécurisé à vie, mais en plus c’est carrément plus facile à mémoriser !

Bon, vous allez me rétorquer que c’est vachement plus long à taper, et là je vous répondrais que oui, mais qu’il existe des tas d’outils de type agents SSH, trousseaux de clés et systèmes de mémorisation de mot de passe (dans votre navigateur par exemple), qui sont de manière générale une bonne idée (surtout si vous leur mettez un mot de passe maître, à taper une seule fois par session, qui les déverrouille explicitement). Puisque nous parlons ici spécifiquement de clés SSH, nous aborderons plus loin comment éviter la saisie systématique de sa passphrase.

Parce que ne vous avisez surtout pas de « résoudre » le pseudo-problème de la longueur du texte en utilisant une passphrase vide. Ce serait complètement stupide, parce que ça reviendrait à ne pas du tout protéger votre clé ! Donc assurez-vous d’utiliser une bonne passphrase bien solide, et préférez les agents SSH (que nous verrons plus bas, je le répète) pour vous éviter des saisies multiples.

Vérifier ce qu’on a comme clé

Bon, il est l’heure de vérifier si vous avez déjà une paire de clés du bon type (DSA)…

Sur tous les systèmes Linux et Unix, vos clés SSH sont normalement stockées dans un dossier .ssh à la racine de votre profil. Ouvrez donc un terminal et tapez la commande suivante :

1

ls -lAF ~/.ssh

Si vous avez un message d’erreur (genre « je ne connais pas ce dossier ») ou un listing ne contenant que des fichiers style authorized_keys, config ou known_hosts, vous n’avez pas encore de clé exploitable. Ce que vous cherchez, ce sont des fichiers qui, classiquement, s’appellent id_dsa (la clé privée) et id_dsa.pub (la clé publique). Ce sont de bêtes fichiers texte, avec un peu d’enrobage autour de votre clé représentée dans un format appelé Base64. Par exemple, sur mon portable, le listing donne ça :

1
2
3
4
5
6
7
8
9

$ ls -lAF ~/.ssh
total 48
-rw------- 1 tdd tdd    90 déc 11  2009 config
-rw------- 1 tdd tdd   736 aoû 23  2007 id_dsa
-rw------- 1 tdd tdd   609 aoû 23  2007 id_dsa.pub
-rw------- 1 tdd tdd   736 jul 17 09:17 id_dsa_git
-rw-r--r-- 1 tdd tdd   609 jul 17 09:17 id_dsa_git.pub
-rw------- 1 tdd tdd   668 avr  6 22:53 id_dsa_sips
-rw-r--r-- 1 tdd tdd 23696 jul 24 11:07 known_hosts

Comme vous pouvez le constater, ma clé fondamentale date un peu (23 août 2007), et j’ai une deuxième paire dédiée pour Git (id_dsa_git), ce qui n’a rien d’obligatoire, ainsi qu’une troisième, dont je n’ai ici que la clé privée, et qui me sert encore à autre chose.

Vous n’avez pas de clé DSA, ou vous en avez une dont vous ignorez la passphrase pour quelque raison que ce soit ? Ou peut-être en voulez-vous une dédiée pour Git ? Pas de souci, on va en créer une nouvelle !

Créer une clé

L’outil de prédilection pour créer des clés (et un peu tout ce qui touche à la crypto) est le système OpenSSL. C’est un ensemble de bibliothèques et outils en ligne de commande, présent sur tous les Linux et Unix (entre autres), qui constitue le standard de facto. Dommage qu’il soit si mal documenté… Ici, on peut passer par une surcouche spécialisée dans les clés SSH, au travers de l’outil en ligne de commande ssh-keygen.

Pour créer une paire de clés DSA, on procède comme suit. Je suppose ici que vous allez changer le nom par défaut vers id_dsa_ga (pour Git Attitude), mais si vous laissez le nom par défaut, il suffit de taper Entrée à la question correspondante. Évidemment, utilisez votre propre chemin.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/tdd/.ssh/id_dsa): /Users/tdd/.ssh/id_dsa_ga
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/tdd/.ssh/id_dsa_ga.
Your public key has been saved in /Users/tdd/.ssh/id_dsa_ga.pub.
The key fingerprint is:
65:31:7e:ee:49:3a:66:cd:92:7b:02:2b:bf:b3:1a:79 tdd@CodeMagic.local
The key’s randomart image is:
+--[ DSA 1024]----+
|          o      |
|         . o     |
|          + .    |
|         o o     |
|        S   o    |
|       ..  B .   |
|      o EoB =    |
|      .ooo.+.    |
|      .+++.o     |
+-----------------+

Suivant votre version de ssh-keygen, vous n’aurez pas forcément le randomart à la fin (et en vrai, on s’en fout), et la ligne qui suit « The key fingerprint is: » sera totalement spécifique à votre propre exécution de la commande. Chaque paire de clés a une empreinte unique.

Et de fait, regardez un peu vos clés toutes neuves (vous aurez naturellement des valeurs différentes de celles présentées ici, celle de la privée étant d’ailleurs tronquée par mes soins :)

1
2
3
4
5
6
7
8
9
10
11
12

$ cat ~/.ssh/id_dsa_ga
-----BEGIN DSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,6ED59B013D8A361F

pB5eHHpvXxoz6i1jFzlKANv9W6SeHw664PV/1A90acR/Mw/ERQvTQKo3TaLaFhkb
…
NwhQFyxZZty2hn6xrv5UIAGTpjk+P2+waRmSno1Vg1x0epCp45kvFRv9AiXsOpt4
RgzPC5+a6kjPf8EtyozGoQ==
-----END DSA PRIVATE KEY-----
$ cat ~/.ssh/id_dsa_ga.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAJhbQcZK8lFMvpw7trbFj51Sqjd9nKBu2xkw/kvUAQlPQPaIRLOiq92fxp+jzp97xDqpwFnvU++ptUiB1nQQ8oq8l5t5QuHwfMMnSDMXhWf2235i4Lw2DtRTbxs0UQJ1l+QxO/AjlV/POcFpq6Z0PKMosi8TslqqPaqAbQtiEX2DAAAAFQDaK1EZY12itrt0lomTAOT0QATilwAAAIAK9C0YTR0T82r7TFheo/+vU6dS9KCypEjR7rEVf7MxCJLd9MQNkVTJe7XCFnYeT9oz7h8NbYHGyDQr7EZGIchtiju6EPFWuQWEAJAHq7z9s9ygoVqyWSQo0y/6riihJk5bo+Etj//OdwndlfKg0c6UGBFg8T2i6nKsbmMMEAI+XAAAAIA+bPjEeoZhwLuCp3Bv0+B4mWgGqnb2IhRSVDQNYeHIofhiSY7prVB+O1iQhrN/EJlygkaFWNaVlPmxrXa+8i+ZGWeVlAaKJdSAsDawNjOaHTi6/Cfqm7NTrLIIeOcjjxwrPLPZ3v0tP8MFjhYFdgjooYjTDzqQmpCGVSA4hXtqhg== tdd@CodeMagic.local

Notez que les clés publiques sont généralement formatées sur une seule ligne ; dans une liste de clés (par exemple le fichier ~/.ssh/authorized_keys, qui liste les clés publiques dont les titulaires peuvent accéder à votre compte via SSH), on a donc en général une clé par ligne. La fin de la clé publique est son commentaire, qui vaut par défaut « identifiant@machine », mais peut être changé.

Dernière info sur la manipulation des fichiers de clé : on peut changer la passphrase d’une clé SSH avec la ligne de commande suivante :

1

$ ssh-keygen -p -f ~/.ssh/le_fichier_de_cle

La commande vous demandera votre ancienne passphrase, puis la nouvelle avec une double saisie (initiale puis de confirmation). Pratique si vous aviez saisi une passphrase un peu pourrie, par exemple. En revanche, si votre clé est compromise (vous avez des raisons de penser qu’un tiers s’est approprié votre clé privée), ne changez pas la passphrase (ça ne servira à rien) : changez de clé !

Agents SSH

Un agent SSH est un outil intégré à votre système d’exploitation qui vous permet de ne saisir la passphrase d’une clé qu’une seule fois (pendant la durée de vie de l’agent, généralement limitée à votre session, entre connexion et déconnexion).

OS X intègre cette fonction dans son outil plus général de Trousseau d’Accès (Keyring) depuis Leopard (10.5). Avant cela (par exemple Tiger, la 10.4), il fallait ruser comme décrit dans cet article. La première utilisation d’une clé entraîne l’affichage d’une demande de passphrase, et la possibilité de stocker celle-ci dans le trousseau d’accès pour éviter des saisies supplémentaires durant la session.

Ubuntu et ses variantes intègrent cette fonction aux principaux gestionnaires de fenêtre (Gnome, KDE, etc.). Le workflow est similaire à celui d’OS X : la première utilisation entraîne une demande de passphrase avec persistence dans l’agent.

Pour les autres distributions Linux et gestionnaires de fenêtre, je ne sais pas trop si un agent est déjà disponible ou pas. Vous pouvez le vérifier en ouvrant un terminal puis en tapant :

1

set | grep SSH_AUTH_SOCK

Si vous ne voyez rien s’afficher, vous n’avez pas d’agent actif ; si vous voyez quelque chose (probablement du genre /var/run/….sock), alors vous en avez un.

Si vous n’avez pas d’agent actif, vous pouvez en lancer un manuellement à l’aide de la bien-nommée commande ssh-agent. Celle-ci crée un processus résident (un daemon) et affiche la série de commandes à balancer dans l’environnement (ou dans chaque terminal) pour qu’il soit au courant que l’agent existe, et donc qu’il essaie de s’en servir. Ces commandes consistent généralement juste à définir les variables d’environnement SSH_AUTH_SOCK et SSH_AGENT_PID. Du coup quand on lance un agent à la main dans le shell courant, on récupère généralement son affichage pour l’exécuter aussi sec, comme ceci :

1
2

$ eval `ssh-agent`
Agent pid 23038

Évidemment, vous verrez un autre numéro de processus (pid), mais le principe est le même.

À partir de là, à vous de tester le comportement lors de la première utilisation d’une clé SSH : si vous voyez une interception globale vous demandant de saisir la passphrase et proposant de la stocker dans l’agent, tout baigne. Si ce n’est pas le cas, vous allez devoir ajouter la passphrase à l’agent manuellement, en utilisant la commande ssh-add. Dans ce cas, soit vous avez une seule clé, et vous n’avez pas besoin de la préciser, soit vous en avez plusieurs et il faut indiquer laquelle :

1
2
3

$ ssh-add ~/.ssh/id_dsa_ga
Enter passphrase for /Users/tdd/.ssh/id_dsa_ga:
Identity added: /Users/tdd/.ssh/id_dsa_ga (/Users/tdd/.ssh/id_dsa_ga)

Après ça, la passphrase est automatiquement exploitée pendant toute la durée de vie de l’agent.

Ce type de manip’ est notamment utile quand on se connecte sur un serveur de production où on va faire une série de git pull, git submodule update, etc. et où on veut éviter de taper sa passphrase une tonne de fois. On commence par configurer l’agent, ajouter sa clé, et hop ! On est prêt à rouler.

Enfin, pour ce qui est de Windows, avec msysGit spécifiquement, vous trouverez quelques instructions pour lancer automatiquement ssh-agent sur cette documentation chez GitHub.

Publier sa clé publique ?

Les clés asymétriques ne sont pas seulement utiles pour SSH et les systèmes se greffant par-dessus. Elles sont aussi, par exemple, le moyen privilégié pour (dé)crypter ou signer numériquement (ou les deux) les e-mails. Je rêve du jour où tout le monde saura utiliser correctement le medium e-mail : pas de pièces jointes énormes ou débiles, pas de liste d’e-mails destinataires visible par tout le monde, pas de HTML pourri rempli de Comic Sans MS… et l’habitude de signer les e-mails importants. Ce dernier point, notamment, ouvrira le chemin des e-mails comme moyen valide de communication à valeur légale, par exemple avec votre banquier, votre notaire, votre avocat, etc.

Si le sujet vous intéresse, jetez par exemple un œil au client de messagerie Thunderbird et à son extension Enigmail, basée sur l’outil libre GnuPG (naturellement, il existe d’autres possibilités techniques autour d’Apple Mail, de GMail et j’en passe).

Dans un tel contexte, il est important de pouvoir facilement récupérer la clé publique de quelqu’un, soit parce qu’on veut lui envoyer un contenu confidentiel (on va donc le chiffrer avec la clé publique du destinataire, dont seule la clé privée pourra déchiffrer), soit parce qu’on a reçu un e-mail signé numériquement de cette personne (grâce à sa clé privée), et qu’on veut vérifier que ça vient bien d’elle, et que le contenu n’a pas été altéré (ce qu’on peut faire uniquement à l’aide de sa clé publique).

Bien entendu, la personne en question peut nous avoir, au préalable, transmis sa clé publique. Encore faut-il pouvoir faire confiance au mécanisme qui a fait cette transmission (il existe des moyens, dont l’empreinte de la clé, mais ce n’est pas le sujet de cet article). Un autre moyen plus général est, pour la personne, de publier sa clé publique aux yeux de tous. Pour cela, il existe des serveurs de clés. La plupart sont gratuits, et les plus connus sont répertoriés par les principaux systèmes exploitant des clés. En voici quelques-uns :

• keyserver.pgp.com
• pgpkeys.mit.edu
• pgp.webtru.st/

Et Git dans tout ça ?

La plupart des hébergements de dépôt Git reposent sur des clés SSH publiques pour identifier les personnes ayant un accès aux dépôts. Lorsque vous accédez à un dépôt authentifié, que ce soit en protocole git://… ou git@…, le système SSH sous-jacent va passer en revue vos clés privées au regard des clés publiques qu’il connaît, et s’il trouve une correspondance, vous demander la passphrase (à moins qu’un agent ne la lui fournisse tout seul) puis engager la suite des opérations.

Dans le cadre des ateliers Git Attitude, lorsque nous étudions l’interaction avec des dépôts distants, j’ai besoin de disposer de clés publiques dont vous avez l’homologue privée, afin de configurer vos accès au serveur Gitosis que nous utilisons. Vous recevez dans vos convocations une demande pour me fournir cette clé à l’avance, avec un lien vers cet article si vous vous sentez déboussolés :-)

J’espère que cet article vous a été utile, et vous a permis de mieux comprendre les clés SSH et leurs meilleures pratiques d’utilisation. Si vous avez des questions, commentaires ou corrections, les commentaires sont là pour ça !