Cómo dominar el flujo de trabajo de git para un pequeño equipo

Preguntándose si este es un enfoque razonable para usar git con un pequeño equipo:

  1. Tenemos la twig "maestra". Git crea esta twig para nosotros de forma pnetworkingeterminada.
  2. El desarrollador A y B clonan "master" a sus máquinas locales.
  3. El desarrollador A ejecuta: [git branch devA] para crear una sucursal local. Se cambian a él ejecutando: [git checkout devA].
  4. El desarrollador B ejecuta: [git branch devB] para crear una sucursal local. Se cambian a él ejecutando: [git checkout devB].
  5. Para que el Desarrollador A convierta su sucursal local en una sucursal remota, ejecutarían: [git push origin devA]. El desarrollador B hace lo mismo con su sucursal local.
  6. Ahora si usa GitHub, veríamos estas dos twigs remotas en nuestra página de proyecto.
  7. Ambos desarrolladores realizan cambios en sus sucursales locales, y al ejecutar [git push] enviarán sus commits a sus respectivas sucursales remotas (veríamos esto reflejado en github).

Eso me parece un flujo de trabajo razonable. Ahora llega el momento de que los desarrolladores fusionen todo su trabajo para el lanzamiento de la aplicación en la que están trabajando. Mi entendimiento:

  1. El Desarrollador A desea get los cambios del Desarrollador B en su sucursal. El desarrollador A se ejecutará: [git pull origin devB].
  2. Podríamos crear otra twig remota llamada "dev" que actúa como un repository central para los cambios de todos: [git branch dev], [git push origin dev].
  3. Uno de los desarrolladores cambia a la twig "dev". Toman los cambios de todos en: [git pull origen devA], [git pull origen devB]. Todos los conflictos son fijos, etc.
  4. Después de que todos los conflictos se hayan solucionado en "dev", pasamos a la twig "master" y tiramos de "dev" en ella: [git branch master], [git pull origin dev].

Entonces, la idea es que todos los desarrolladores trabajen en sus propias sucursales locales, y periódicamente fusionen cosas en "dev". Solo en el momento del lanzamiento, alguien saca los cambios de "dev" a "maestro". Entonces "maestro" siempre contiene el último código liberado.

¿Eso parece razonable?

¡Gracias!

Este flujo de trabajo probablemente estaría bien, aunque tiene algunos puntos en los que es posible que desee pensar.

No refleja una filosofía común de Git de que cada twig represente una "característica" o "tema" -valor del trabajo (véase, por ejemplo, Junio ​​Hamano sobre el propósito de las twigs ). Sin embargo, eso no evitaría que sea un flujo de trabajo viable para su equipo.

Un flujo de trabajo popular que refleja esta filosofía es git flow .

Otro flujo de trabajo popular es el flujo de trabajo que utiliza el equipo de desarrollo de GitHub, que va directamente en contra de lo que escribe Junio ​​sobre fusionar el máster en twigs de características, a favor de mantener el model mental más simple y evitar tener que explicar sobre rebase a los desarrolladores.

Otro problema es que este flujo de trabajo desalienta las integraciones frecuentes. Entonces devA y devB pueden divergir significativamente y los desarrolladores pueden tener que trabajar mucho para fusionarse cuando llegue el momento.

A Git en sí no le importa, así que si tus desarrolladores están contentos, entonces lo que propones parece factible.

Suponiendo que tiene más de dos desarrolladores, ¿desea que un desarrollador pueda get cambios de otro desarrollador específico, pero no include los cambios de todos los demás desarrolladores? Si no, no veo la necesidad de crear twigs de desarrollador en absoluto. Todos se registran en master en su propio repository; todos presionan para dominar el origen; todos obtienen cambios impulsados, fusionados con todos los desarrolladores, en cada extracción.

En cuanto a la twig maestro vs. dev en el origen, podrías hacer eso; más típicamente, creo, master es un trabajo continuo, y cada versión estable tiene su propia twig.