Colocando ganchos do git no repository

É considerado uma prática ruim – colocar .git / hooks no repository de projetos (usando links simbólicos, por exemplo). Se sim, qual é a melhor maneira de entregar os mesmos ganchos para diferentes usuários do git?

    Não, colocá-los no repository é bom, eu até sugiro fazê-lo (se eles são úteis para os outros também). O usuário tem que explicitamente ativá-los (como você disse, por exemplo, por symlinking), que por um lado é um pouco doloroso, mas protege os usuários, por outro lado, de executar código arbitrário sem o seu consentimento.

    Eu geralmente concordo com Scytale, com algumas sugestões adicionais, o suficiente para que valha a pena uma resposta separada.

    Primeiro, você deve escrever um script que crie os links simbólicos apropriados, especialmente se esses ganchos forem sobre imposição de políticas ou criação de notifications úteis. As pessoas estarão muito mais propensas a usar os ganchos se puderem digitar bin/create-hook-symlinks que se eles tiverem que fazer isso sozinhos.

    Em segundo lugar, diretamente ganchos symlinking impede que os usuários adicionem em seus próprios ganchos pessoais. Por exemplo, eu prefiro o exemplo de gancho de pré-consolidação que garante que eu não tenha nenhum erro de espaço em branco. Uma ótima maneira de contornar isso é colocar um script wrapper em seu repository e criar um link simbólico para todos eles. O wrapper pode então examinar $0 (assumindo que é um script bash; um equivalente como argv[0] ) para descobrir qual hook foi invocado como, em seguida invocar o hook apropriado dentro de seu repo, bem como o hook do usuário apropriado, terá que ser renomeado, passando todos os argumentos para cada um. Exemplo rápido da memory:

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

    O script de instalação moveria todos os ganchos pré-existentes para o lado (append .local aos seus nomes) e vincular simbolicamente todos os nomes de gancho conhecidos ao script acima:

     #!/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 

    Em http://git-scm.com/docs/git-init#_template_directory , você poderia usar um desses mecanismos para atualizar o diretório .git / hooks de cada repository git recém-criado:

    O diretório de modelos contém arquivos e diretórios que serão copiados para o $ GIT_DIR depois de criado.

    O diretório de modelos será um dos seguintes (em ordem):

    • o argumento dado com a opção –template;

    • o conteúdo da variável de ambiente $ GIT_TEMPLATE_DIR;

    • a variável de configuração init.templateDir; ou

    • o diretório de modelos padrão: / usr / share / git-core / templates.

    O pacote https://www.npmjs.com/package/pre-commit npm trata isso elegantemente, permitindo que você especifique ganchos de pré-consolidação no seu package.json.