Repositorios, problemas, múltiples desarrolladores y bifurcación de organizaciones de Github: mejores prácticas de flujo de trabajo

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

Tenemos una cuenta de organización en github con repositorios privados. Queremos usar los problemas nativos de github / características de solicitudes de extracción (las solicitudes de extracción son básicamente exactamente lo que queremos en cuanto a revisiones de código y discusiones de características). Encontramos el centro de herramientas de defunkt que tiene una pequeña característica genial de poder convertir un problema existente en una solicitud de extracción y asociar automáticamente su rama actual con él.

Me pregunto si es una buena práctica hacer 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 es básicamente lo que cada proyecto de código abierto en github), pero queremos estar seguros de que podemos rastrear problemas y extraer solicitudes de UNA fuente, el repositorio de la organización.

Entonces tengo algunas preguntas:

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

EDITAR
Hice algunas pruebas con problemas, bifurcaciones y solicitudes de extracción y encontré eso. Si crea un problema en el repositorio de su organización, luego bifurque el repositorio de su organización a su propia cuenta de github, realice algunos cambios, fusione con la rama maestra de su bifurcación. Cuando intenta ejecutar hub -i <issue #>se produce un error, User is not authorized to modify the issue. Entonces, aparentemente ese flujo de trabajo no funcionará.

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

Depende de la escala de tu equipo, supongo. Solía ​​trabajar en un pequeño equipo donde solo teníamos un único repositorio y las características tenían sus propias ramas 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 hacemos todo el desarrollo importante en repositorios personales y enviamos PR para funciones para que el código pueda ser revisado, aunque las correcciones de errores se pueden enviar directamente. El repositorio principal solo lleva ramas maestras y de liberación, manteniéndolo libre de desorden. Las ramas de características están en repositorios personales, por lo que aún pueden ser vistas por otros (hacer que los primeros RRPP para ellos alertarán a otros miembros del equipo que trabajan en una característica en curso). 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 múltiples controles remotos.

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

El desarrollador quiere obtener su código en la rama principal y solicita su inclusión.

Este es un contexto muy diferente al antiguo modelo donde la gente se compromete, y luego el revisor tuvo que decirles "oh, esto que hiciste hace unas semanas no fue tan bueno, arréglalo ahora".

Utilizamos este modelo en nuestra empresa. Las solicitudes de extracción hicieron viables las solicitudes de código, 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 estuvieron primero en contra de la nueva herramienta. Siento que también hizo que la gente tomara las revisiones de código más en serio, 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 se haya comprometido.

No haría toda la bifurcación y bifurcación de todo. 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, retroceder, etc. cambios. Hacer una gran cantidad de tenedores y sucursales en su situación es excesivo en mi humilde opinión.

Reservaría sucursales para cosas como: actualizaciones de versiones, cambiar una de las piezas tecnológicas, trabajar en un submódulo durante 3 meses que tiene poco en común con la base principal.

Puede que no bifurque en absoluto dentro de una organización. Ese modo parece más adecuado para proyectos de código abierto que son de naturaleza diferente a los internos.

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