Flujo de trabajo de Git para equipos pequeños.

Estoy trabajando en un flujo de trabajo de git para implementar en un equipo pequeño. Las ideas centrales en el flujo de trabajo:

Hay un maestro de proyecto compartido en el que todos los miembros del equipo pueden escribir
Todo el desarrollo se realiza exclusivamente en ramas de características
Las ramas de características son revisadas por código por un miembro del equipo que no sea el autor de la rama
La rama de características finalmente se fusiona en el maestro compartido y el ciclo comienza nuevamente

El artículo explica los pasos en este ciclo en detalle:

https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md

¿Tiene sentido o me estoy perdiendo algo?

— janos
fuente

Respuestas:

Me gusta el modelo de ramificación git flow . La rama maestra se deja sola la mayor parte del tiempo, solo contiene versiones. La rama de desarrollo debe ser estable en todo momento, y las ramas de características pueden romperse.

También puede combinar esto con la integración continua combinando desarrollo en su rama de características y su rama de características en desarrollo. Por supuesto, solo debe fusionar algo en el desarrollo cuando esté seguro de que las cosas funcionan y no se rompen.

— Arjan
fuente

Según tengo entendido, git flow y la integración continua son formas alternativas de trabajo y realmente no se pueden combinar. En git flow, el código se fusiona para desarrollarse solo cuando se completa una característica. En la integración continua, todo el código se fusiona en una rama compartida al menos una vez al día, incluso si no proporciona ninguna característica nueva de inmediato.

— bdsl

Creo que te estás perdiendo el tema Integración continua. Debería ser parte de cada configuración de desarrollo.

Con las ramas de características tiene el problema, que no se integra continuamente, sino solo después de que se completa una característica.

Si la característica ramificada es de corta duración, esto podría ser aceptable, pero definitivamente es algo que uno debería considerar.

Otra alternativa es configurar compilaciones de CI para cada rama de características. Esto sí ayuda, pero no es integración. Esto se vuelve obvio una vez que encuentra su primer error que no aparece en la Característica A ni en la Característica B, sino en el momento en que integra la Característica A y B

Una tercera alternativa es hacer que la fusión en alguna rama de integración forme parte de la compilación de CI. Esta es una verdadera integración, y en realidad funciona razonablemente bien con git si el trabajo está algo separado, pero causa conflictos de fusión durante la compilación que resultan en compilaciones fallidas.

— Jens Schauder
fuente

La rama maestra se puede conectar con un CI para rechazar las fusiones de ramas de características si fallan las pruebas automáticas de no regresión. Gracias por el consejo, agregaré una sección de "Consejos" al final y mencionaré esto allí.

— Jan

Claro, pero como se dijo, esto no es una integración continua sino una integración al final de una característica que podría ser buena, pero no es lo mismo

— Jens Schauder

Creo que las ramas de características son muy útiles, ya que no necesitan ser estables. Eso significa que puede comprometerse con frecuencia en lugar de tener una gran confirmación.

— Arjan

Un proceso de compilación automatizado que se ejecuta en un horario (sistema CI) es indispensable. Debe ejecutarse con frecuencia para que los problemas de compilación se puedan encontrar y solucionar rápidamente. Los equipos de desarrollo deberían dar a las fallas de compilación la máxima prioridad Es mucho más fácil solucionar este tipo de problemas cuando surgen por primera vez.

— Nathan Pilling

Para nuestros proyectos que usan CI (tenemos un par de proyectos heredados que no pueden usarlo en este momento), comprometemos TODO a dominar para un verdadero CI, para nuestros proyectos heredados usamos el modelo de ramificación git flow. Las ramas de funciones son un bloqueador de CI si me lo preguntas, hacen que sea más difícil CONTINUAR (no solo cuando está terminado) integrarse. Seguimos trabajando en las funciones y la tarea final es activarlo básicamente, pero el código siempre está en el proyecto.

— Elliot Blackburn

Puedes inspirarte en gitflow o Twgit .

gitflow resume su enfoque como:

Extensiones Git para proporcionar operaciones de repositorio de alto nivel para el modelo de ramificación de Vincent Driessen.

Twgit se describe a sí mismo de la siguiente manera:

Twgit es una herramienta de asistencia gratuita y de código abierto para administrar funciones, revisiones y lanzamientos en repositorios de Git. Proporciona comandos simples de alto nivel para adoptar el modelo de ramificación que se describe en nuestra documentación. SO compatible: Debian / Ubuntu Linux, Mac OS X.

Ambas herramientas están disponibles en github .

— Durán
fuente