Créez vos propres sous-commandes Git

Git est assez célèbre pour avoir beaucoup de sous-commandes, comme clone, init, add, mv, restore, bisect, blame, show, rebase, et beaucoup plus. Dans un article précédent, j’ai écrit sur la sous-commande très utile rev-parse pour Git. Même avec toutes ces sous-commandes disponibles, les utilisateurs proposent toujours des fonctions pour améliorer leur expérience Git. Bien que vous soyez libre de créer des commandes liées à Git et de les exécuter en tant que scripts, il est facile de créer vos propres sous-commandes Git personnalisées. Vous pouvez même les intégrer à Git via rev-parse.

Créer un script Git simple

Un script qui s’intègre à Git peut être aussi complexe que vous en avez besoin, ou il peut être court et simple.

À titre d’exemple simple, supposons que vous avez créé un script qui rassemble les noms de fichiers de votre dernier commit et les place dans un fichier appelé latest.txt. Vous utilisez ce script après chaque validation à des fins de création de rapports, et vous avez décidé qu’il serait pratique de pouvoir exécuter le script comme s’il s’agissait d’une fonctionnalité intégrée de Git, par exemple, avec la commande git report.

Actuellement, en cours d’exécution git report rend cette erreur:

$ git report

git: 'report' is not a git command. See 'git --help'.
The most similar command is
        bugreport

Voici le script qui génère votre rapport :

#!/bin/sh
TOP=$(git rev-parse --show-toplevel)
HASH=$(git log --pretty=format:'%h' -n 1)
mkdir "${TOP}"/reports || true
git diff-tree \
--no-commit-id --name-only \
-r HEAD > "${TOP}"/reports/$HASH

Enregistrez ce fichier sous git-report.sh quelque part dans votre PATH.

Vous n’allez pas exécuter ce script directement, alors incluez le .sh extension dans le nom. Rendre le script exécutable :

$ chmod +x git-report.sh

Créer la commande frontale

Vous pouvez forcer Git à s’exécuter git report par rev-parse et lancez votre git-report.sh script au lieu de renvoyer une erreur. Voici le scénario :

Enregistrez ce fichier sous git-report (ne pas utiliser de .sh extension de fichier) quelque part sur votre PATH. Rendre le script exécutable :

$ chmod +x git-report

Exécuter votre commande Git personnalisée

Maintenant, testez-le. Tout d’abord, créez l’infrastructure et quelques exemples de données :

$ mkdir myproject ; cd !$
$ git init
$ echo "foo" > hello.txt
$ git add hello.txt
$ git commit -m 'first file'
$ git report

Regardez à l’intérieur du reports répertoire pour voir un enregistrement de votre dernier commit :

$ cat reports/2e3efd8
hello.txt

Passez des arguments à votre script

Vous pouvez faire passer des arguments rev-parse, aussi. J’aide à maintenir une sous-commande Git appelée Git-portal, qui permet de gérer de gros fichiers multimédias associés à un référentiel Git.

C’est un peu comme Git LFS ou Git Annex, sauf sans la surcharge de la gestion des versions des fichiers multimédias réels. (Les liens symboliques vers les fichiers sont conservés sous contrôle de version, mais le contenu des fichiers est traité indépendamment, ce qui est utile dans les scénarios où le processus artistique est distinct du processus de développement.)

Pour intégrer Git-portal à Git en tant que sous-commande, j’utilise un simple script shell frontal, qui à son tour invoque rev-parse pour l’analyse littérale.

L’exemple de script fourni dans cet article ne peut prendre aucun paramètre, mais les scripts Git réels que j’écris le font presque toujours. Voici comment les arguments sont passés, par exemple, à Git-portal :

#!/bin/sh
ARG=$(git rev-parse --sq-quote "$@")
CMD="git-portal.sh $ARG"
eval "$CMD"

le --sq-quote option cite tous les arguments suivants git portal et les inclut comme nouveaux paramètres pour git-portal.sh, qui est le script avec toutes les fonctions utiles qu’il contient. Une nouvelle commande est assemblée dans le CMD variable, puis cette variable est évaluée et exécutée.

Voici un exemple simple que vous pouvez exécuter. Il s’agit d’une version modifiée d’un script que j’utilise pour redimensionner et appliquer des données EXIF ​​précises de copyright (ou de copyleft, selon le cas) aux images pour un CMS à fichier plat que j’utilise Git pour gérer.

Ceci est un exemple simplifié, et il n’y a aucune bonne raison pour que ce script soit une sous-commande Git, mais c’est démonstratif. Vous pouvez utiliser votre imagination pour trouver des moyens de l’étendre pour utiliser les fonctions Git.

Appelez ce fichier git-imager.sh:

#!/bin/sh
## Requires
# GNU Bash
# exiftool (sometimes packaged as perl-Image-exiftool)
# Image Magick
PIC="${1}"
COPY="-Copyright"
LEFT="${2}"
mogrify -geometry 512^x512 -gravity Center \
        -crop 512x512+0+0 "${1}"
exiftool -Copyright="${2}" "${1}"

Le script frontal pour l’intégration Git transmet tous les paramètres (le nom du fichier et la licence) au git-imager.sh scénario.

#!/bin/sh
ARG=$(git rev-parse --sq-quote "$@")
CMD="git-imager.sh $ARG"
eval "$CMD"

Essaye le:

$ git imager logo.jpg "Tux CC BY-SA"
 1 image files updated

Personnalisation facile de Git

La création de votre propre sous-commande Git donne à vos scripts personnalisés l’impression d’être des composants naturels de Git. Pour les utilisateurs, cela facilite la mémorisation des nouvelles sous-commandes et aide vos sous-commandes à s’intégrer dans le reste du flux de travail Git de chacun.