flujo de trabajo del equipo github: ¿bifurcar o no?

Somos un pequeño equipo de desarrolladores web que actualmente usa Subversion, pero pronto vamos a cambiar a Github.

Estoy viendo diferentes tipos de flujos de trabajo de github, y no estamos seguros de si el concepto completo de bifurcación en github para cada desarrollador es una buena idea para nosotros.

Si usamos bifurcaciones, entiendo que cada desarrollador tendrá sus propios repositorios privados remotos y locales. Me preocupa que haga que los cambios sean difíciles y demasiado complejos. Además, mi mayor preocupación es que obligará a cada desarrollador a tener 2 controles remotos: origen (que es la bifurcación remota) y un flujo ascendente (que se utiliza para "sincronizar" los cambios desde el repositorio principal). No estoy seguro si es una manera tan fácil de hacer las cosas.

Esto es similar al flujo de trabajo explicado aquí: https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow

Si no usamos bifurcaciones, probablemente podamos hacerlo bien usando un repositorio central creando una rama para cada tarea en la que estamos trabajando, y fusionándolos en la rama de desarrollo en el mismo repositorio. Significa que no podremos restringir la fusión de ramas y podría ser un poco complicado tener muchas ramas en el repositorio central.

¿Alguna sugerencia de los equipos que probaron ambos flujos de trabajo?

Creo que su miedo a la bifurcación proviene de la fusión menos estelar de SVN, porque no es la bifurcación la que causa el problema, es la fusión.

Sumérgete, ¡encontrarás que es realmente genial! No necesita bifurcar en exceso (no bifurcar por cada cambio en cada archivo), pero puede bifurcar las características y fusionarlas nuevamente.

Piense en GitHub como varias versiones que vale la pena mejorar en muchos de los conceptos centrales en el control de código fuente.

El concepto de una rama "estable" y una bifurcación de "desarrollo activo" también cubre muchos de estos problemas si tiene dudas sobre la bifurcación. :PAGS

Hemos probado ambos, con desarrolladores que están muy a gusto en svn. Y si son un grupo de desarrolladores que ya trabajan juntos y confían entre sí con derechos de compromiso, probablemente les resulte más fácil mantener un único repositorio central en git y agregarlos a todos como colaboradores que ese repositorio.

Todavía hacemos ocasionalmente tenedores privados, pero eso es típicamente para cambios exóticos o pruebas de 1 persona en las que el resto generalmente no está interesado, pero que de todos modos deseamos almacenar de forma remota.

Comenzaría con un único repositorio central y solo trabajaría con git por un tiempo. Tal vez el tenedor privado crecerá en ti, tal vez no. Cualquiera esta bien.

En git, un tenedor es realmente solo otra rama. Con el flujo de trabajo de la bifurcación para cada desarrollador, está exigiendo efectivamente que cada desarrollador tenga una sucursal pública (remota) para rastrear sus cambios de desarrollo. Esto es útil para poder colaborar directamente (peer-to-peer) entre desarrolladores. En cualquier caso, tendrá que fusionar los cambios de cada desarrollador en el repositorio central, por lo que no creo que esto agregue demasiados gastos generales.

Para un pequeño equipo de 2-3 desarrolladores, está bien usar la ramificación en el repositorio para administrar correcciones y características. El problema es cuando tienes más desarrolladores que eso y más características y correcciones que se están desarrollando.

Cuando ese sea el caso, su repositorio principal en Github tendrá cientos de sucursales; algunos serán viejos, olvidados y no fusionados.

También tendrá problemas con la colaboración donde alguien está presionando a la fuerza en una rama compartida que está en el repositorio. Eso significa que nadie puede colaborar adecuadamente en esa rama ya que un empuje forzado es una reescritura de la historia.

Bifurcar un repositorio hace que sea más fácil rastrear qué ramas están en progreso y cuáles son buenas para ir. Mantiene el repositorio principal más limpio.

Sin embargo, su infraestructura de prueba puede depender del uso del repositorio principal, por lo que puede ser más difícil probar los cambios en su repositorio bifurcado a menos que haya empujado la rama hacia arriba. Puede ser complicado descubrir cuándo es mejor bifurcar y bifurcar, pero en general, cuando el equipo tiene más de 4 personas y hay muchas correcciones y características, bifurcar es la mejor opción.