Mettre des crochets git dans le repository

Est-ce considéré comme une mauvaise pratique – de mettre des hooks / git dans le référentiel des projets (en utilisant des liens symboliques, par exemple). Si oui, quelle est la meilleure façon de fournir les mêmes hooks aux différents utilisateurs de git?

    Non, les mettre dans le repository est bien, je suggérerais même de le faire (s’ils sont utiles pour les autres aussi). L’utilisateur doit les activer explicitement (comme vous l’avez dit, par exemple en effectuant une liaison symésortingque), ce qui est un peu pénible, mais protège les utilisateurs d’un autre côté contre l’exécution de code arbitraire sans leur consentement.

    Je suis généralement d’accord avec Scytale, avec quelques suggestions supplémentaires, suffisamment pour que cela vaille une réponse séparée.

    Tout d’abord, vous devez écrire un script qui crée les liens symboliques appropriés, en particulier si ces points concernent l’application de règles ou la création de notifications utiles. Les gens seront beaucoup plus susceptibles d’utiliser les hooks s’ils peuvent simplement taper bin/create-hook-symlinks plutôt que de le faire eux-mêmes.

    Deuxièmement, les hooks directement symésortingsés empêchent les utilisateurs d’append leurs propres hooks personnels. Par exemple, j’aime bien l’exemple de hook de pré-validation qui vérifie que je n’ai aucune erreur de blanc. Un bon moyen de contourner ce problème consiste à insérer un script d’encapsulation dans votre repository et à créer un lien symbolique avec tous les hooks. Le wrapper peut alors examiner $0 (en supposant que ce soit un script bash; un équivalent comme argv[0] sinon) pour déterminer quel crochet il a été appelé en tant que, puis appeler le crochet approprié dans votre repo, ainsi que le hook approprié devra être renommé, en passant tous les arguments à chacun. Exemple rapide de mémoire:

     #!/bin/bash if [ -x $0.local ]; then $0.local "$@" || exit $? fi if [ -x tracked_hooks/$(basename $0) ]; then tracked_hooks/$(basename $0) "$@" || exit $? fi 

    Le script d’installation déplacera tous les hooks préexistants sur le côté (ajout de .local à leurs noms) et un lien symbolique avec tous les noms de hook connus dans le script ci-dessus:

     #!/bin/bash HOOK_NAMES="applypatch-msg pre-applypatch post-applypatch pre-commit prepare-commit-msg commit-msg post-commit pre-rebase post-checkout post-merge pre-receive update post-receive post-update pre-auto-gc" # assuming the script is in a bin directory, one level into the repo HOOK_DIR=$(git rev-parse --show-toplevel)/.git/hooks for hook in $HOOK_NAMES; do # If the hook already exists, is executable, and is not a symlink if [ ! -h $HOOK_DIR/$hook -a -x $HOOK_DIR/$hook ]; then mv $HOOK_DIR/$hook $HOOK_DIR/$hook.local fi # create the symlink, overwriting the file if it exists # probably the only way this would happen is if you're using an old version of git # -- back when the sample hooks were not executable, instead of being named ____.sample ln -s -f ../../bin/hooks-wrapper $HOOK_DIR/$hook done 

    Depuis http://git-scm.com/docs/git-init#_template_directory , vous pouvez utiliser l’un de ces mécanismes pour mettre à jour le répertoire .git / hooks de chaque repository git nouvellement créé:

    Le répertoire du modèle contient des fichiers et des répertoires qui seront copiés dans le fichier $ GIT_DIR après sa création.

    Le répertoire du modèle sera l’un des suivants (dans l’ordre):

    • l’argument donné avec l’option –template;

    • le contenu de la variable d’environnement $ GIT_TEMPLATE_DIR;

    • la variable de configuration init.templateDir; ou

    • le répertoire du modèle par défaut: / usr / share / git-core / templates.

    Le paquet https://www.npmjs.com/package/pre-commit npm gère cette fonctionnalité avec élégance, vous permettant de spécifier des hooks de pré-validation dans votre package.json.