Estoy intentando limitar los envíos a la twig master solo permitiendo commands de push que provienen de la twig de test .
¿Cómo puedo saber de qué twig proviene el push ?
No se puede, al less no con methods convencionales en ganchos de recepción y actualización. Los empujes no "provienen" de ninguna parte en particular: los ganchos simplemente obtienen una list de nombres de reference y valores de SHA-1.
Los ganchos de pre-receive y update tienen la oportunidad de aprobar o desaprobar cada request para cambiar los refs/ whatever label refs/ whatever que refs/ whatever a algún SHA-1 nuevo (en su caso, querría ver si la label es específicamente refs/heads/master ) . (La diferencia entre pre-receive y update es que el primero obtiene la list completa en stdin, con valores SHA-1 antiguos y nuevos, mientras que el último obtiene las actualizaciones una a la vez como arguments, es decir, se llama una vez para cada uno -be-updated ref. Un solo push puede impulsar muchas actualizaciones de ref. El gancho de pre-receive puede verificar el set como un todo, pero solo puede decir "sí" o "no" a la actualización como un todo; , el gancho de update puede verificar cada actualización individualmente y decir Sí o No a cada una individualmente).
El gancho post-receive se llama después de que se hayan realizado todas las actualizaciones, con una list de los cambios "ref X utilizados para apuntar a oldsha y ahora apunta a newsha ".
En todos los casos, no hay información de origen, solo SHA-1 sin formatting, lo que tiene sentido ya que quien ejecuta el command push puede hacer:
git push remote 1234567:refs/tags/foo
por ejemplo, para crear una nueva label apuntando al object 1234567 sin tener realmente ninguna label correspondiente en su propio repository.
Para hacer que este tipo de cosas funcionen, puedes rechazar bashs de master completo y modificar el process: los usuarios ingresan a otra twig (o incluso a un repository diferente) y, una vez que se ve el resultado, se ingresa la confirmación ahora revisada. master por otros medios (fusión manual o automática desde el éxito).
La forma más rápida es usar gitk: http://git-scm.com/docs/gitk