Flujo de trabajo GIT para desarrollo web

Hace mucho tiempo, el pequeño equipo de desarrolladores web con el que trabajo comenzó a usar git para el desarrollo web. En aquel entonces, solo nos comprometimos a organizar o masterizar directamente y luego nos fusionamos con frecuencia entre los dos. Era mejor que nada, pero también era un desastre.

No hace mucho tiempo adoptamos el flujo de trabajo de gitflow. Si bien es ciertamente mejor que el caos que vino antes, parece algo engorroso y excesivamente orientado a la liberación / hitos. Mis compañeros de desarrollo con frecuencia me piden que aclare cómo se supone que funciona y qué debería fusionarse y qué no. En general, parece poco adecuado para el trabajo de desarrollo web donde implementamos código con frecuencia y sin rastrear hitos específicos para su lanzamiento.

Por sugerencia reciente de un amigo, comencé a mirar GitHub Flow . Leer la publicación de Scott Chacon aquí golpea el punto de dolor perfectamente con esto:

Entonces, ¿por qué no usamos git-flow en GitHub? Bueno, el problema principal es que implementamos todo el tiempo. El proceso git-flow está diseñado principalmente en torno a la "liberación". Realmente no tenemos "lanzamientos" porque implementamos en producción todos los días, a menudo varias veces al día.

FWIW, también he visto este resumen de los flujos de trabajo en el sitio de Atlassian: https://www.atlassian.com/git/workflows#!workflow-feature-branch

Sin embargo, TODOS parecen malas opciones para el desarrollo web en un equipo pequeño y nuevamente orientados a lanzamientos de aplicaciones importantes, no frecuentes / lanzamientos diarios.

La pregunta sobre SE pide comparar git-flow con github-flow /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -fluir

Esa es una buena respuesta en general, pero como mencioné en mi comentario a continuación meta.programmers.SE parece indicar que las preguntas sobre las mejores prácticas generales de flujo de trabajo pertenecen aquí y esperaba una lista más amplia de posibles respuestas que solo git-flow y github -flow, siendo específico para el desarrollo web. Por lo tanto, creo que merece una nueva pregunta aquí.

Con eso, ¿cuál considera que es el flujo de trabajo basado en git mejor / preferido para un pequeño equipo de desarrollo web que trabaja en proyectos con una implementación bastante continua? ¿Es github-flow o algo más?

Primero, me gustaría hacer un pequeño resumen de los diferentes flujos de trabajo que ha examinado y cree que no son adecuados para el tipo de desarrollo en el que está trabajando:

• Centralizado ( fuente ): más o menos como el flujo de trabajo SVN pero ahora en un entorno distribuido. Cada desarrollador trabaja en una copia personal mastery empuja los cambios origin/masterdirectamente o mediante solicitud de extracción.

• Característica rama ( Fuente ): Bueno, eso. Cada desarrollador que trabaje en una característica particular debe trabajar en una rama específica dedicada solo a esa característica. Esta rama de características se debe crear desde mastero desde otra rama de características. Finalmente, todo se fusionó de nuevo master.

• Gitflow ( Fuente ): Dos ramas principales rastrean el historial de un proyecto, developy master. Otros 3 ramas llamados hotfix, releasey featurecambios retención aplicada directamente a masterpara la fijación de errores críticos de producción, cambio de número de versión y otros detalles antes de una liberación o trabajar en una característica particular, como rama de la característica , respectivamente.

• Flujo de GitHub ( Fuente ): los desarrolladores crean una featurerama de master. Los cambios se envían mediante solicitud de extracción. Los cambios aceptados para master ser implementados inmediatamente por el bot GitHub Hubot.

Para la parte de desarrollo de su pregunta, la respuesta depende de los antecedentes de su equipo. ¿Vienen de un entorno SVN? Entonces deberías optar por el enfoque centralizado, ya que es el que más se parece a SVN. ¿Se sienten cómodos trabajando con Git? Entonces, tal vez no debería tratar de adaptar el flujo de trabajo de su equipo a ninguno de ellos, sino implementar el suyo propio, diseñado para satisfacer sus necesidades, que si entendí bien son la flexibilidad de desarrollo y la implementación rápida.

También creo que deberías enfocarte en mejorar esto último. ¿Cómo se compone su canalización de implementación ? En " Entrega continua: lanzamientos confiables de software a través de la automatización de compilación, prueba y despliegue ", los autores identifican las posibles causas de despliegues poco frecuentes, algunos de los cuales son:

• El proceso de implementación no está automatizado.
• La prueba lleva mucho tiempo.
• La gente no entiende el proceso de compilación / prueba / implementación.
• Los desarrolladores no están siendo disciplinados para mantener la aplicación funcionando haciendo pequeños cambios incrementales, y tan frecuentemente rompen la funcionalidad existente

¿Alguno de esos suena como algo que podrías mejorar? Quizás podría contarnos un poco más sobre cómo usted y su equipo manejan esta parte del proyecto.