Flujos de trabajo de Git para profesionales: una buena guía de Git

Git puede respaldar su proyecto no solo con el control de versiones, sino también con la colaboración y la gestión de versiones. Comprender cómo los patrones de flujo de trabajo de Git pueden ayudar o dificultar un proyecto le brindará el conocimiento para evaluar y adaptar los procesos de Git de su proyecto de manera efectiva.

A lo largo de esta guía, aislaré los patrones del proceso de desarrollo de software que se encuentran en los flujos de trabajo comunes de Git. El conocimiento de estos lo ayudará a encontrar una dirección al unirse, crear o hacer crecer un equipo de desarrollo. Los pros y los contras de ciertos tipos de proyectos o equipos se destacarán en los ejemplos de flujo de trabajo que exploramos, para que pueda elegir lo que podría funcionar bien para su escenario.

Esta no es una introducción al uso de Git. Ya existen guías fabulosas y documentación para esto. Se beneficiará de esta guía de flujo de trabajo de Git si ya tiene experiencia dentro de un equipo de desarrollo de aplicaciones y se ha enfrentado a inconvenientes de flujo de trabajo, implosiones de integración o git-tastrophes; estos patrones pueden arrojar algo de luz sobre cómo evitar esas situaciones en el futuro.

Colaboración

En términos del proceso de Git, la colaboración a menudo consiste en ramificar flujos de trabajo. Pensar con anticipación en cómo entrelazará los árboles de compromiso lo ayudará a minimizar los errores de integración y respaldará su estrategia de administración de versiones.

Rama de Integración

Use una rama de integración con equipos de desarrollo de software que trabajen para implementar una colección de contribuciones en producción como una sola entidad. Esto se opone a los equipos que se enfocan en implementar características individualmente. A menudo, los equipos pueden querer hacer lo segundo, pero las limitaciones prácticas imponen un proceso que agrupa sus esfuerzos, y el equipo termina haciendo lo primero, así que asegúrese de revisar su uso real de Git para ver si se beneficiaría de usar este tipo de colaboración. patrón.

Este patrón de flujo de trabajo es un punto de partida útil para cuando el riesgo de integrar varias sucursales es lo suficientemente alto como para justificar probar las contribuciones combinadas como un todo.

Una rama de integración generalmente consta de una característica principal y varias contribuciones más pequeñas que se implementarán juntas. Ponga una rama de integración a través del proceso de su equipo de desarrollo (preguntas y respuestas y pruebas de aceptación, por ejemplo). Empuje confirmaciones menores para acercarlo a la producción y luego use una rama de entorno o una rama de lanzamiento (discutido a continuación) para prepararlo para la implementación.

Tenga en cuenta que las contribuciones en la rama de integración deben fusionarse en la siguiente etapa de lanzamiento antes de que otra función importante pueda fusionarse en la rama de integración; de lo contrario, está mezclando funciones en diferentes etapas de finalización. Esto inhibirá su capacidad de liberar lo que está listo.

Ramas temáticas

Los equipos querrán usar ramas de temas si es importante mantener sus árboles de confirmación en un estado que se pueda leer fácilmente o revertir características individuales. Las ramas de temas significan que las confirmaciones se pueden sobrescribir (mediante una inserción forzada) para limpiar su estructura y reducirse a una confirmación de características.

Las ramas de temas a menudo son propiedad de un colaborador individual, pero también pueden ser un espacio designado para que un equipo desarrolle una característica. Otros colaboradores saben que este tipo de rama podría tener su árbol de confirmación reescrito en cualquier momento, y no deberían intentar mantener sus ramas locales sincronizadas con él.

Sin utilizar ramas de temas en su flujo de trabajo de Git, está restringido a apegarse a las confirmaciones que envía a una rama remota. Forzar la inserción de un nuevo árbol de confirmación en una rama remota podría enojar a otros colaboradores que confían en la integridad mantenida de la rama con la que se sincronizan.

Lo más probable es que ya utilice este patrón de flujo de trabajo sin darse cuenta, pero vale la pena tener un conjunto compartido de definiciones entre los equipos para reforzar las prácticas detrás de ellos. Por ejemplo, puede encontrar que la convención de anteponer el nombre de la rama con las iniciales del creador de la rama ayuda a señalar cuáles son ramas temáticas. De cualquier manera, depende de su equipo decidir sobre las convenciones internas.

NO use ramas de temas en repositorios públicos, causa una gran cantidad de conflictos para cualquier persona que haya sincronizado sus ramas locales con una rama de tema que ha tenido su árbol de confirmación reescrito.

Tenedor

Los proyectos de código abierto prosperan con esta característica originada en Github. La bifurcación empodera a los mantenedores del repositorio con una puerta de enlace forzada en lugar de empujar directamente a una rama del repositorio de origen, pero lo que es más importante, facilita la colaboración. ¡Guau!

Es posible que se encuentre en el escenario en el que la creación de una bifurcación de un repositorio privado también se adapte a sus necesidades. Establecer el repositorio de origen en solo lectura para los contribuyentes del repositorio de bifurcación y continuar con las solicitudes de extracción le brinda los mismos beneficios que la experiencia de la comunidad de código abierto. Los equipos de diferentes organizaciones pueden trabajar de manera efectiva utilizando una bifurcación que puede ser la plataforma para la comunicación y el cumplimiento de la política del proyecto.

El patrón de flujo de trabajo de la bifurcación brinda a los equipos su propio espacio para trabajar de la forma en que están acostumbrados con un único punto de integración entre los dos repositorios: una solicitud de extracción. La sobrecomunicación es imperativa dentro de la descripción de la solicitud de extracción. Los equipos han tenido flujos de comunicación separados antes de que se emita una solicitud de extracción, y resaltar las decisiones que ya se han tomado acelerará el proceso de revisión.

Por supuesto, un beneficio del flujo de trabajo de la bifurcación es que puede dirigir los comentarios a los colaboradores del repositorio de origen, ya que los permisos descienden en cascada. Desde el punto de vista del repositorio de origen, tienes el control para eliminar las bifurcaciones cuando ya no se necesitan.

Asegúrese de estar utilizando una herramienta que facilite la bifurcación y las solicitudes de extracción para aprovechar este patrón. Estas herramientas no se limitan a Github: otras opciones populares son Bitbucket y GitlLab. Pero hay bastantes otros servicios de alojamiento de flujos de trabajo de Git que tendrán estas características (o similares). Elija qué servicio funciona mejor para usted.

NO use una bifurcación de un repositorio privado para cada miembro de un equipo. Los numerosos repositorios bifurcados pueden dificultar que varios miembros colaboren en la misma rama de características, y mantener todos estos repositorios sincronizados puede volverse propenso a errores debido a la gran cantidad de partes móviles. Los proyectos de código abierto tienen miembros del equipo central con acceso push al repositorio de origen que reducen esta sobrecarga.

Clon

Una estrategia común de subcontratación es tener “puestos” de contribución en un proyecto que pueden ser ocupados por múltiples desarrolladores de software. Depende de la empresa de subcontratación administrar su flujo de recursos para entregar las horas contratadas, los problemas que enfrentan son cómo incorporar, capacitar y mantener un grupo de desarrolladores para los proyectos de cada cliente.

El uso de un clon del repositorio del proyecto establece un terreno aislado de capacitación y comunicación para que el equipo subcontratado administre sus contribuciones, haga cumplir las políticas y aproveche el intercambio de conocimientos, todo bajo la atenta mirada del equipo de desarrollo del cliente. Una vez que se considera que una contribución cumple con los estándares y está lista para el repositorio principal, puede enviarse a una de las sucursales remotas de los repositorios de origen e integrarse como de costumbre.

Algunos proyectos tienen grandes expectativas de seguir sus convenciones de codificación y estándares definidos de flujo de trabajo de Git para contribuir a su repositorio. Puede ser desalentador trabajar en este entorno hasta que haya aprendido las reglas, así que trabajen juntos como equipo para optimizar el tiempo de ambas partes.

NO cree una copia alojada del repositorio del cliente sin su permiso, podría estar rompiendo un acuerdo contractual, verifique por adelantado que esta práctica beneficiará el proyecto con el cliente.

Gestión de la liberación

Los pasos entre pasar de la colaboración al lanzamiento comenzarán en diferentes puntos dentro del proceso de desarrollo de cada equipo. Por lo general, no querrá usar más de un patrón Git de administración de versiones. Desea tener el flujo de trabajo más simple posible que le permita a su equipo entregar de manera efectiva.

Sucursales de Medio Ambiente

Su proceso de desarrollo de software puede estar respaldado por varios entornos para ayudar con el control de calidad antes de implementarlo en producción. Las ramas de entorno imitan las etapas de este proceso: cada etapa corresponde a una rama, y ​​las contribuciones fluyen a través de ellas en una canalización.

Los equipos que ejecutan estos procesos a menudo tienen entornos de aplicación configurados para cada etapa de la canalización, por ejemplo, "Control de calidad", "Puesta en escena" y "Producción". En estos casos, la infraestructura está lista para respaldar al personal responsable de aprobar una característica o contribución para su porción de lo que significa estar listo para la producción (por ejemplo, pruebas exploratorias, control de calidad, pruebas de aceptación), antes de pasarlo a la siguiente persona. escenario. Esto les brinda su propio lugar para implementar, probar y evaluar según sus requisitos, con un flujo de trabajo de Git para registrar su viaje a través del túnel de aprobación.

Tener una rama para cada etapa del proceso está bien para equipos pequeños que pueden trabajar en una versión como una unidad. Desafortunadamente, una tubería como esta puede embotellar o agruparse con demasiada facilidad y dejar brechas. Acopla su proceso de Git a su infraestructura, lo que puede causar problemas cuando la función exige una aceleración y ambos procesos necesitan escalar.

NO use este patrón sin considerar primero los beneficios a largo plazo de otros patrones.

Ramas de lanzamiento

Un equipo que envía una colección de contribuciones a su aplicación de producción como una unidad en sprints sucesivos puede encontrar que las ramas de lanzamiento encajan favorablemente.

Una colección de compromisos casi "listos para producción" reciben correcciones de errores menores en una rama de lanzamiento. Use una rama de integración para combinar y probar las funciones antes de mover su árbol de confirmación a una rama de lanzamiento. Limite la responsabilidad de una rama de lanzamiento a ser una verificación final antes de la implementación en la aplicación de producción.

Las ramas de versión se diferencian de las ramas de entorno en que tienen una vida útil corta. Las ramas de lanzamiento se crean solo cuando es necesario y se destruyen después de que su árbol de confirmación se haya implementado en producción.

Intente evitar acoplar las ramas de lanzamiento a su hoja de ruta de desarrollo de software. Restringirse a seguir un plan predeterminado retrasa la implementación de una versión hasta que todas las características planificadas estén listas para la producción. No asignar un número de versión a la hoja de ruta antes de crear una rama de lanzamiento puede aliviar este tipo de demoras, al permitir que las funciones que están listas para producción se coloquen en una rama de lanzamiento y se implementen.

Use una convención de nomenclatura de número de versión para el nombre de la rama de lanzamiento para que sea obvio qué versión del repositorio se ha implementado en producción.

Implemente la rama principal y no la rama de versión. Para fomentar la realización de correcciones menores en las ramas de lanzamiento antes de la fusión con la rama principal, use un enlace de Git en la rama principal para activar después de que se haya producido una fusión para implementar automáticamente el árbol de confirmación actualizado en producción.

Permitir que solo exista una rama de versión en un momento determinado garantiza que evitará la sobrecarga de mantener varias ramas de versión sincronizadas entre sí.

NO utilice ramas de lanzamiento con varios equipos trabajando en el mismo repositorio. A pesar de que las ramas de lanzamiento son de corta duración, si la verificación final lleva demasiado tiempo, impide que el otro equipo lance. Es probable que un equipo que se apoya en la rama de lanzamiento de otro equipo introduzca errores y provoque retrasos para ambos equipos. Mire el patrón de lanzamiento con marca de tiempo a continuación, que funciona mejor para un mayor número y grupos de colaboradores.

Lanzamientos con marca de tiempo

Las aplicaciones con restricciones de infraestructura suelen programar sus implementaciones durante períodos de poco tráfico. Si su proyecto se enfrenta a colas regulares de funciones listas para implementarse, puede beneficiarse del uso de versiones con marca de tiempo.

Un lanzamiento con marca de tiempo se basa en el proceso de implementación para agregar automáticamente una etiqueta de marca de tiempo a la última confirmación en la rama principal que se implementó en producción. Las ramas de temas se utilizan para poner una función en el proceso de desarrollo antes de fusionarse con la rama maestra para esperar la implementación.

La etiqueta de marca de tiempo debe incluir una marca de tiempo real y una etiqueta para indicar que representa una implementación, por ejemplo: deployed-201402121345 .

La inclusión de metadatos de implementación, en forma de etiqueta de marca de tiempo dentro del árbol de confirmación de la rama maestra, lo ayudará a depurar las regresiones liberadas en la aplicación de producción. Es poco probable que la persona encargada de buscar la causa del problema sepa mucho sobre todas y cada una de las líneas que se implementan en la aplicación de producción. Ejecutar un comando git diff en las dos últimas etiquetas puede brindar rápidamente una instantánea de qué confirmaciones se implementaron por última vez y quiénes son los autores de confirmaciones que podrían ayudar a resolver el problema.

Las ramas con marca de tiempo son más de lo que parecen en la superficie. Un mecanismo simple para registrar una implementación de funciones en cola requiere una sorprendente cantidad de buenos procesos para impulsarlo. El proceso es uno que puede escalar y funciona bien con un pequeño equipo de colaboradores también.

Para que este patrón de flujo de trabajo de Git sea verdaderamente efectivo, necesita que la rama maestra siempre se pueda implementar. Eso podría significar cosas diferentes para su equipo, pero esencialmente todas las confirmaciones deben haber pasado por el proceso de desarrollo de sus proyectos antes de terminar en la rama principal.

Las nuevas confirmaciones que aterrizan en la rama maestra se realizarán varias veces al día. Este es un problema para las ramas de temas que han pasado por el proceso de desarrollo y no se han sincronizado con la rama maestra durante este tiempo. Desafortunadamente, tal escenario puede introducir regresiones en la rama maestra cuando los conflictos de combinación se tratan incorrectamente.

Si surgen conflictos de combinación entre una rama de tema y la rama maestra, entonces el riesgo de introducir un nuevo error debe discutirse con su equipo antes de actualizar la rama maestra remota. Si hay alguna duda de que podría ocurrir una regresión, la rama de tema puede volver a pasar por el proceso de control de calidad con los conflictos de combinación resueltos.

Para reducir los errores de integración, los desarrolladores que están trabajando en partes relacionadas del repositorio pueden colaborar en el mejor momento para fusionar y sincronizar sus ramas temáticas con la rama maestra. Las ramas de integración también funcionan bien para resolver conflictos de ramas de temas relacionados; estas deben someterse al proceso de prueba antes de fusionarse en la cola en la rama maestra pendiente de implementación.

Los proyectos de desarrollo de software con muchos colaboradores tienen que lidiar con procesos de gestión de versiones y colaboración con enfoques prácticos y eficientes. Los metadatos adicionales en el árbol de confirmaciones que obtenemos al usar lanzamientos con marca de tiempo son un indicador de la previsión de los equipos que se están preparando para responder a los problemas de producción.

Rama de versión

Si tiene un repositorio que no solo ejecuta en producción, sino que otros usan para sus propias aplicaciones alojadas, el uso de ramas de versión puede brindarle a su equipo la plataforma para brindar soporte a los usuarios que no se mantienen al tanto de los desarrollos de su aplicación, o no pueden hacerlo. .

Un repositorio que use ramas de versión tendrá una rama por versión menor de la aplicación. Las versiones principales, secundarias y de parches se explican en la documentación de versiones semánticas. Las ramas de versión normalmente siguen una convención de nomenclatura para incluir la palabra "estable" y eliminar el número de parche de la versión de la aplicación: por ejemplo 2-3-stable para que su propósito y confiabilidad sean obvios para los usuarios finales.

Las etiquetas de Git se pueden aplicar hasta el número de versión del parche de la aplicación, pero las ramas de la versión no son tan detalladas. Una rama de versión siempre apuntará a la confirmación más estable para una versión secundaria compatible.

Cuando aparezcan los parches de seguridad o la necesidad de respaldar la funcionalidad, reúna las confirmaciones necesarias para que funcionen con las versiones anteriores de la aplicación que admite, e insértelas en las ramas de su versión, respectivamente.

NO use ramas de versión a menos que admita más de una versión de su repositorio.

Resumen

Cuando tu equipo cambie de tamaño, o tu proyecto desarrolle sus procesos a través de una evaluación continua, no dejes de evaluar también tu proceso Git. Utilice los patrones de este tutorial como punto de partida para guiarlo por el camino de la justicia en el flujo de trabajo de Git.

El patrón en esta guía puede ayudarlo a armarse con cierta previsión para adaptar su sistema de control de versiones distribuidas para que funcione para usted. Si desea leer sobre los flujos de trabajo de Git, asegúrese de consultar Gitflow, Github Flow y, lo que es más importante, ¡la increíble documentación de git-scm!