GitHub Flow se implementa en producción antes de fusionarse con master: ¿una segunda característica no anulará la primera?

En la comprensión de GitHub Flow, como se ve aquí , una característica, después de la revisión del código, primero se implementa en producción, luego se fusiona en master.

Si hay una segunda característica ramificada de la misma confirmación que la primera característica, y que también se implementa directamente en producción, entonces la producción ya no contendrá la primera característica.

hecho en learngitbranching.js.org

Una vez que se implementa c2, ¿cómo se puede implementar c3 antes de fusionarse con c2 o c4?

¿Cómo maneja GitHub Flow este problema?

Una solución obvia sería exigir que una característica se vuelva a crear en el maestro antes de implementarla en producción. Sin embargo, esto es propenso a errores humanos. Si uno olvida cambiar la base, ahora a la producción le falta una característica.

Agradecería especialmente las respuestas de aquellos que tienen experiencia en el uso de GitHub Flow. ¿Cómo no tienes este problema?

¡Buenas noticias! ¡GitHub tiene un artículo al respecto!

Identifican tres medidas de seguridad:

• Asegúrese de que pase sus pruebas. Con suerte, esto forma parte de la mayoría de los flujos de trabajo de implementación. Pero, es una de las medidas de "seguridad" que enfatizan.
• "Bloquee" la canalización de implementación según sea necesario: cuando una rama de características se implementa o verifica en producción, nadie más puede iniciar una implementación.
• Asegúrese de que cada rama implementada contenga todos los conjuntos de cambios ya implementados. Cómo se hace esto es un poco más complicado. Esto es lo que dicen:

Utilizamos la API de GitHub para verificar este requisito. Un punto final en la aplicación github.com expone el SHA1 que se está ejecutando actualmente en producción. Enviamos esto a la API de comparación de GitHub para obtener la "base de fusión", o el ancestro común, del maestro y el SHA1 de producción. Luego podemos comparar esto con la rama que estamos intentando implementar para verificar que la rama esté atrapada. Al usar el ancestro común de maestro y producción, el código que solo existe en una rama se puede eliminar de la producción, y los cambios que se han colocado en el maestro pero que no se han implementado aún no requerirán que las ramas los fusionen antes de implementarlos.

Si resulta que la rama está detrás, el maestro se fusionará automáticamente. Hacemos esto usando la nueva ✨Merging API✨ que ponemos a disposición hoy. Esta fusión inicia una nueva compilación de CI como cualquier otro evento de estilo push, que comienza una implementación cuando pasa.

La API de fusión básicamente realiza una fusión estándar, pero lo hace del lado del servidor.

Su solución probablemente no necesita ser tan sofisticada. Al final del día, solo necesita una seguridad razonable de que:

• Las pruebas pasan
• Solo una persona se despliega a la vez
• El maestro se fusiona en ramas de características antes de la implementación

¿Te ha sucedido este problema o es una pregunta teórica?

Git es "lo suficientemente inteligente" cuando se fusiona para presionar solo el código modificado, si hay "problemas", le dará un conflicto de fusión.

Cada nueva característica se basa en la rama de desarrollo, no basamos las características en otras características.

Una cosa que hacemos para minimizar los conflictos de fusión es fusionar con frecuencia y antes de comenzar una función, siempre obtenga el último desarrollo. (nunca nos comprometemos con master sino con una rama de desarrollo, que se fusionará de vez en cuando con la rama master)