2011-12-16 8 views
10

Actualmente estamos usando SVN. Me gustaría comenzar a usar GitHub, pero un requisito absoluto es que tendremos que tener la validación precommit (premerge) del código como la que tenemos actualmente. ¿GitHub es compatible con precomteryooks (premergehooks)?github support precommithooks?

Somos un equipo de 5 desarrolladores. Hicimos un acuerdo de que todo el código (JavaScript) debería pasar la validación JSLint. La validación voluntaria ha demostrado no funcionar porque se olvida fácilmente. ¿Cómo podemos estar seguros de que el código que está disponible para los demás está garantizado para validar contra JSLint (o similar)?

+3

(GIT! = Github) – smitec

+4

soy consciente de ello y sé que Git apoya precommithooks. así que mudarse a git no será un problema, pero no lo haremos a menos que podamos usar github. – coen

+0

los ganchos precommit en git se ejecutarán en su máquina, si detienen la confirmación no hay posibilidad de forzar el código no validado a github – smitec

Respuesta

2

No creo que github admita ganchos de precompromiso. Sin embargo, el núcleo git sí. Puede configurar los ganchos de precompromiso localmente, o aplicarlos como prueba antes de fusionar ramas en su github principal.

+0

Para nosotros, un requisito es que no se puede comprometer sin que se valide su código, por lo que probar antes de la fusión no es una solución desafortunadamente – coen

+0

Quizás debería alejarse de github entonces. No es difícil configurar un simple servidor de git, y luego puede configurar los ganchos exactamente de la manera que desee. –

+0

El objetivo de git es permitir que las confirmaciones sucedan fácilmente; de ​​hecho, comprometerse es algo que ocurre en su máquina local; ninguna cantidad de enganches en el servidor remoto puede evitar que cometa basura localmente. Tal vez debería cambiar su definición de 'commit' a 'merge'? O si confía en que sus usuarios pongan una copia de los ganchos en cada copia de trabajo del cliente. – bdonlan

2

No, GitHub no admite ganchos de precompromiso. Cómo sería posible que eso funcione? El compromiso ocurre en su computadora, ¿realmente desea permitir que GitHub ejecute código arbitrario en su máquina?

+2

Estaría bien fusionarse mientras trabaje localmente, pero cuando se fusione con el repositorio principal, el código debería validarse. Me imagino que esto podría hacerse con webhooks, por ejemplo. – coen

+0

//, ¿Tal vez podría explicar cómo la pregunta podría hacerse más inteligible? Tenga en cuenta que muchas personas que pegan esto tendrán antecedentes en SVN. –

2

Creo que te estás perdiendo algo fundamental acerca de git. No es un modelo centralizado (está bien, puede ser, pero si vas a usarlo de esta manera, entonces github es probablemente el enfoque equivocado). Si está utilizando github, la manera correcta de hacerlo es:

  1. Aloja tu repositorio principal
  2. Tenga sus desarrolladores cada uno crear su propio tenedor
  3. ¡Que felizmente cortar lejos, comprometiéndose y empujando a su heart's content
  4. Cuando creen que una característica está lista, le envían una solicitud de extracción (el mantenedor) que usted mismo verifica en un costado para garantizar la estabilidad. Luego fusiona/rebase sus cambios en el repositorio principal.

Naturalmente, hay muchas maneras de despellejar a un gato. Pero cuando se habla de "git real" (del tipo empleado por la comunidad de código abierto), el modelo centralizado de "verifíquelo-y-maldito-bueno-mejor-trabaje" es un poco difícil, especialmente cuando se trata de proyectos más grandes.

+1

De hecho, podría. Debería echar un vistazo al principio de "solicitud de extracción" que me perdí por completo. – coen

+0

Es perfectamente razonable querer evitar que los usuarios presionen al repositorio desde el que implementan cada vez que fallan las pruebas si está realizando una implementación continua. – kranzky

+0

@kranzky Gracias por el voto a la baja, aunque como que te perdiste el sentido de esta respuesta. –

3

Creo que este artículo se describe un muy buen flujo de trabajo que podría ser una base para la automatización:

http://scottchacon.com/2011/08/31/github-flow.html

La idea principal es que se utilice solicitudes de extracción como se mencionó anteriormente, pero también se puede disponer de un servicio que puede usar github api para buscar o tirar de la rama haciendo la solicitud, fusionar, probar, validar y luego enviar a la rama de destino.