que - Poniendo ganchos git en el repositorio
git tag name (4)
Desde http://git-scm.com/docs/git-init#_template_directory , puede usar uno de estos mecanismos para actualizar el directorio .git / hooks de cada repositorio git recién creado:
El directorio de plantillas contiene archivos y directorios que se copiarán en $ GIT_DIR después de que se haya creado.
El directorio de la plantilla será uno de los siguientes (en orden):
el argumento dado con la opción --template;
el contenido de la variable de entorno $ GIT_TEMPLATE_DIR;
la variable de configuración init.templateDir; o
el directorio de plantillas predeterminado: / usr / share / git-core / templates.
¿Se considera una mala práctica? Colocar .git / hooks en el repositorio de proyectos (utilizando enlaces simbólicos, por ejemplo). En caso afirmativo, ¿cuál es la mejor manera de entregar los mismos ganchos a diferentes usuarios de git?
El paquete https://www.npmjs.com/package/pre-commit npm maneja esto elegantemente, permitiéndote especificar ganchos pre-commit en tu paquete.json.
Generalmente estoy de acuerdo con Scytale, con un par de sugerencias adicionales, lo suficiente como para validar una respuesta por separado.
En primer lugar, debe escribir una secuencia de comandos que cree los enlaces simbólicos apropiados, especialmente si estos enlaces son sobre la aplicación de políticas o la creación de notificaciones útiles. Será mucho más probable que las personas utilicen los ganchos si pueden simplemente escribir bin/create-hook-symlinks
que si lo tienen que hacer ellos mismos.
En segundo lugar, los enlaces directos simbólicos evitan que los usuarios agreguen sus propios ganchos personales. Por ejemplo, prefiero el enlace de precompilación de muestra que asegura que no tengo ningún error de espacio en blanco. Una forma excelente de evitar esto es colocar un script de envoltura de gancho en el repositorio y vincular simbólicamente todos los enlaces a él. El contenedor puede examinar $0
(asumiendo que es un script bash, de otro modo equivalente argv[0]
) para averiguar en qué gancho fue invocado, luego invocar el enlace apropiado dentro de su repositorio, así como el enlace del usuario apropiado, que tendrá que ser renombrado, pasando todos los argumentos a cada uno. Ejemplo rápido de la memoria:
#!/bin/bash
if [ -x $0.local ]; then
$0.local "$@" || exit $?
fi
if [ -x tracked_hooks/$(basename $0) ]; then
tracked_hooks/$(basename $0) "$@" || exit $?
fi
La secuencia de comandos de instalación movería todos los enganches preexistentes al costado (anexar .local
a sus nombres), y enlazará todos los nombres de gancho conocidos al script anterior:
#!/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
No, ponerlos en el repositorio está bien, incluso sugeriría hacerlo (si son útiles para otros también). El usuario tiene que habilitarlos explícitamente (como dijiste, por ejemplo mediante el enlace simbólico), lo que por un lado es un poco molesto, pero protege a los usuarios, por otro lado, de ejecutar código arbitrario sin su consentimiento.