¿Cómo está estructurando su flujo de trabajo del repositorio Git?

Question

Hemos visto y visto los videos sobre cuán grandes equipos distribuidos están usando Git, pero ¿qué pasa con aquellos de nosotros que no estamos distribuidos y que trabajamos en la oficina con el resto de nuestro equipo? ¿Cómo deberíamos estructurar nuestro repositorio (s) y nuestro flujo de trabajo?

Piense en la oficina tradicional que ha estado usando Subversion o CVS como el único punto de autoridad. Ciertamente, estos equipos podrían mantener su propio repositorio de Git y empujar / tirar entre sí según sea necesario, lo que rápidamente se convertiría en una pesadilla en muchas situaciones. O bien, cada uno podría mantener su propio repositorio y sincronizarlo con un único repositorio que se conoce como el "maestro". para el equipo. O bien, podría haber cualquier combinación de flujos de trabajo con las posibilidades de que se abra un DVCS.

¿Cómo funciona tu equipo? ¿Qué ha encontrado que sea un flujo de trabajo útil?

Answer 1

Me gusta la forma en que Yahoo! El equipo de la interfaz de usuario (YUI) parece estar trabajando. No estoy en Yahoo, ni tampoco en ese equipo, pero sus registros de git commit revelan mucho sobre su proceso.

El equipo de YUI mantiene un repositorio central donde todos los miembros del equipo tienen acceso de confirmación. Periódicamente, después de comprometerse con este repositorio (puede ser después de cada impulso, pero no lo creo), el sistema de compilación se dispara, reconstruye YUI y empuja un compromiso recién etiquetado a github, donde la comunidad puede bifurcar el código y trabajar en él .

Estoy a favor del repositorio central que representa el "oficial". estado del proyecto. Ciertamente, si quiero compartir código con un compañero de trabajo, puedo hacer arreglos para que me saquen una rama, y ??podemos colaborar de esa manera.

El "maestro" El repositorio también ofrece otras ventajas, como la facilidad de integración continua, ya que los disparadores push / pull se pueden configurar en el repositorio 'maestro' para disparar las pruebas unitarias y el sistema de construcción. También garantiza que todos sepan dónde se encuentra la versión más reciente del repositorio "conocido bueno", de modo que si el proyecto necesita ser construido, publicado o probado, puede haber garantías razonables de que el repositorio "maestro" está listo para eso. .

Git admitirá casi cualquier flujo de trabajo que se te ocurra, pero incluso entre un equipo pequeño, no quieres que haya una pregunta sobre dónde está el repositorio 'oficial'. La pesadilla de mantenimiento que podría provocar, especialmente a medida que se acerca un lanzamiento, sería desagradable.

Answer 2

eche un vistazo al buen blog http://nvie.com/git-model y comente

Answer 3

Eche un vistazo a un flujo de trabajo que el equipo de github usa:

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

Requiere usar github, pero también es bastante sencillo y limpio.