Repositorios, problemas, múltiples desarrolladores y bifurcaciones de la organización Github: las mejores prácticas de flujo de trabajo

14

Un título extraño, sí, pero creo que tengo un poco de terreno por recorrer.

Tenemos una cuenta de organización en github con repositorios privados. Queremos utilizar las funciones nativas de github / solicitudes de extracción (las solicitudes de extracción son básicamente exactamente lo que queremos en cuanto a revisiones de códigos y discusiones de características). Hemos encontrado la herramienta hub por defunkt que tiene una pequeña característica interesante de poder convertir un problema existente en una solicitud de extracción y asociar automáticamente su sucursal actual con él.

Me pregunto si es una práctica recomendada que cada desarrollador de la organización bifurque el repositorio de la organización para hacer su trabajo de características / correcciones de errores / etc. Esto parece un flujo de trabajo bastante sólido (ya que, básicamente, es lo que hace cada proyecto de código abierto en github) pero queremos asegurarnos de que podemos hacer un seguimiento de los problemas y extraer solicitudes de UNA fuente, el repositorio de la organización .

Tengo algunas preguntas:

  1. ¿Es apropiado un enfoque de horquilla por desarrollador en este caso? Parece que podría ser un poco excesivo. No estoy seguro de que necesitemos una bifurcación para cada desarrollador, a menos que presentemos desarrolladores que no tengan acceso directo directo y necesiten que se revise todo su código. En cuyo caso, nos gustaría instituir una política como esa, solo para esos desarrolladores. Entonces, ¿cuál es mejor? ¿Todos los desarrolladores en un solo repositorio, o una bifurcación para todos?
  2. ¿Alguien tiene experiencia con la herramienta hub, específicamente la función de solicitud de extracción? Si hacemos una bifurcación por desarrollador (o incluso para desarrolladores con menos privilegios), ¿la función de solicitud de extracción de hub operará en las solicitudes de extracción del repositorio principal ascendente (el repositorio de la organización?) O tiene un comportamiento diferente? / li>

EDIT
Hice algunas pruebas con problemas, bifurcaciones y solicitudes de extracción y lo encontré. Si crea un problema en el repositorio de su organización, entonces bifurque el repositorio de su organización a su propia cuenta de github, haga algunos cambios, fusione con la rama principal de su fork. Cuando intentas ejecutar hub -i <issue #> , obtienes un error, User is not authorized to modify the issue . Entonces, aparentemente ese flujo de trabajo no funcionará.

    
pregunta Jim Rubenstein 28.02.2012 - 00:10

3 respuestas

6
  

¿En este caso, es apropiado un enfoque de horquilla por desarrollador? Parece que podría ser un poco excesivo. No estoy seguro de que necesitemos una bifurcación para cada desarrollador, a menos que presentemos desarrolladores que no tengan acceso directo directo y necesiten que se revise todo su código. En cuyo caso, nos gustaría instituir una política como esa, solo para esos desarrolladores. Entonces, ¿cuál es mejor? ¿Todos los desarrolladores en un solo repositorio, o una bifurcación para todos?

Depende de la escala de tu equipo, supongo. Solía trabajar en un equipo pequeño donde solo teníamos un repositorio único y las características tenían sus propias sucursales dentro de ese repositorio. Eso funcionó bien para nosotros.

Sin embargo, ahora contribuyo regularmente a un proyecto de código abierto más grande donde unas pocas docenas de personas tienen acceso al repositorio central. Todavía realizamos todo el desarrollo importante en repositorios personales y enviamos relaciones públicas para las funciones para que el código pueda ser revisado, aunque las correcciones de errores se pueden insertar directamente. El repositorio principal solo lleva las ramas maestras y de liberación, manteniéndolo libre de desorden. Las ramas de las características están en repositorios personales, por lo que aún pueden ser vistas por otras personas (hacer PRs anticipadas para ellas alertará a otras personas en el equipo de que el trabajo en una característica está en marcha). Puedo recomendar este flujo de trabajo para cualquier proyecto con más de un puñado de desarrolladores; el único inconveniente es tener que trabajar con varios controles remotos.

    
respondido por el Fred Foo 04.04.2012 - 12:54
2

El enfoque fork-por-desarrollador es un muy buen enfoque si usted valora las revisiones y la calidad del código. Lo bueno de usar solicitudes de extracción es que transfiere la responsabilidad del mantenedor al desarrollador.

El desarrollador desea ingresar su código a la rama principal y solicita su inclusión.

Este es un contexto muy diferente al modelo antiguo en el que las personas se comprometen, y luego el crítico tuvo que decirles "oh, esto que hiciste hace unas semanas no era tan bueno, arréglalo ahora".

Utilizamos este modelo en nuestra empresa. Las solicitudes de extracción hicieron que las solicitudes de código fueran viables, fomentaron la discusión del código de otras personas y, en general, ayudaron con la calidad del código, incluso con los desarrolladores que estaban en primer lugar en contra de la nueva herramienta. Siento que también hizo que las personas tomen las revisiones de código más seriamente, porque el revisor tiene que fusionar activamente el código en la rama principal, en lugar de simplemente decir "ok" o "no ok" después de que el código ya estaba comprometido.     

respondido por el Wilbert 29.05.2013 - 16:54
1

No haría toda la bifurcación y bifurcación de todo. Ese es un buen modelo para gemas de código abierto en github, pero su modelo está dentro de una organización que normalmente tendría un mayor nivel de confianza sobre los cambios.

Un punto importante del control de fuente es que puede ver, retroceder, revertir, etc. los cambios. Hacer un gran número de tenedores y sucursales en su situación es un exceso IMHO.

Reservaría sucursales para cosas como: actualizaciones de versión, cambio de una de las piezas de tecnología, trabajo en un submódulo durante 3 meses que tiene poco en común con la base principal.

Es posible que no se bifurque en absoluto dentro de una organización. Ese modo parece más adecuado para proyectos de código abierto que son diferentes en naturaleza a los de la casa.

Cambiaría tu enfoque a pruebas y revisiones de código. ¿La gente está escribiendo pruebas? ¿Están ellos bien? ¿Se realizan revisiones de código?

    
respondido por el junky 28.02.2012 - 03:17

Lea otras preguntas en las etiquetas