¿Qué flujo de git es el mejor para un pequeño equipo donde todos los desarrolladores trabajan en todos los proyectos?

Somos un pequeño equipo de 5 desarrolladores. Acabamos de pasar de Subversion a Git y tenemos problemas para encontrar el flujo de trabajo adecuado para nosotros.

Intentamos seguir desde el principio hasta el flujo de trabajo de gitflow siguiendo un artículo exitoso de model de ramificación de git, pero, francamente, parece abrumador para los proyectos pequeños en los que trabajamos y para algunos tenemos dificultades para seguirlo estrictamente ya que es bastante diferente del model de subversión que somos Acostumbrado a.

Por lo tanto, en este momento no estamos utilizando las twigs de publicación para hacer lanzamientos porque parece innecesario, aunque mantenemos limpio nuestro maestro. De la misma manera, no estamos utilizando funciones de twigs sino que trabajamos directamente en el desarrollo en su lugar.

No estoy seguro de los lanzamientos, pero creo que DEBERÍAMOS usar twigs de características, es solo que no sé cómo trabajar con ellas. En el artículo mencionado, así como en otros que hemos leído, recomienda mantener las características locales y aplastar las confirmaciones en ellas antes de fusionarlas para desarrollarlas. Parece sencillo si solo un desarrollador está trabajando en esa function, pero nuestro escenario es que cualquiera en cualquier momento puede querer / necesitar llevar el proyecto a su estado actual y continuar trabajando en él. Por lo tanto, los proyectos cambian mucho de manos y todo el trabajo debe enviarse al server, incluso si aún no se ha finalizado, de modo que cualquier persona puede aprovecharlo y seguir trabajando.

Entonces, con todo nuestro trabajo en remoto, nos resulta difícil mantener las cosas limpias, nuestra historia es una larga list de pequeños compromisos, pero, por lo que yo entiendo, no podemos aplastarlos o volver a establecer una base de ninguna twig porque eso cambiará la historia pública.

Queremos hacerlo bien pero no más complicado de lo necesario. Entonces, cualquier idea de qué flujo de trabajo sería el mejor para nosotros y cómo podemos implementarlo, ¿verdad?

Puede seguir trabajando en las twigs de rebase con compromisos pequeños y solo rebase y / o squash antes de fusionarse para develop sucursal. A partir de ahí, la twig de características no tiene relevancia, por lo que estropear su historial no es necesariamente un problema.

  • crear una twig de características
  • hacer el trabajo, comprometer empuje en la twig de características
  • otros desarrolladores pueden tomar el control y hacer más trabajo
  • cuando esté listo, rebase el desarrollo, networkinguzca los pequeños commits y vuelva a fusionarlo

Resuelve el problema de no "contaminar" la historia con commits pequeños. El único problema con este enfoque es que no actualiza su twig de funciones muy a menudo, por lo que terminará teniendo fusiones más grandes.

En mi experiencia, lo mejor es apuntar a twigs de características de vida muy cortas con el uso de características alternadas. De esta forma, puede fusionar twigs de características incompletas pero no rotas, eliminando enormes luchas de fusión.

Tener un historial de compromiso real no es malo. Ayuda a las revisiones y hace que sea más fácil seleccionarlas si es necesario y ayuda con las fusiones también. Tu maestro debe mantenerse limpio: uno se compromete por lanzamiento. Desarrollar puede ser un poco less limpio, un compromiso por cada característica / sucursal. Sin embargo, la twig de function puede contener el historial correctamente.

Además, si desea mantener el gráfico de compromiso un poco más fácil de seguir, puede volver a establecer una base con frecuencia sobre el desarrollo y el empuje. No se recomienda alterar la historia pública porque si no todo el mundo está consciente de esto, podría ocasionar problemas. Sin embargo, si en algún momento solo uno, o solo unos pocos desarrolladores están trabajando en la misma twig, es aceptable siempre y cuando todos los que estén trabajando en esa twig específica estén al tanto de la rebase (puede ser algo progtwigdo, o una cosa que haces cada time después de que se actualice la twig de desarrollo)