Componentes del flujo de GitHub

  • 8 minutos

En esta unidad, se revisarán los siguientes componentes del flujo de GitHub:

  • Ramas
  • Confirmaciones
  • Solicitudes de incorporación de cambios
  • El flujo de GitHub
  • Flujo de Git

Componentes de GitHub Flow

Antes de entrar en flujos de trabajo específicos de GitHub, resulta útil comprender que Flow de GitHub se compila directamente en los conceptos fundamentales de Git.

Git proporciona herramientas para realizar un seguimiento y administrar los cambios en el código a lo largo del tiempo. GitHub se basa en esto, lo que facilita el uso de esas herramientas con características como ramas, confirmaciones, solicitudes de incorporación de cambios e interfaces visuales para la colaboración. Empecemos examinando cómo funcionan estos conceptos en GitHub.

Qué son las ramas

En la última sección, creamos un nuevo archivo y una nueva rama en el repositorio.

Las ramas son una parte esencial de la experiencia de GitHub. Permiten realizar cambios sin afectar a la rama predeterminada.

La rama es un lugar seguro para experimentar con nuevas características o correcciones. Si comete un error, puede revertir sus cambios o insertar más cambios para subsanarlo. Los cambios no se actualizarán en la rama predeterminada hasta que combine la rama.

Nota

Como alternativa, puede crear una nueva rama y extraerla del repositorio usando Git en un terminal. El comando sería git checkout -b newBranchName

¿Qué son las confirmaciones?

En la unidad anterior, agregó un nuevo archivo al repositorio insertando una confirmación. Revisemos brevemente qué son las confirmaciones.

Una confirmación es un cambio en uno o varios archivos de una rama. Cada confirmación se realiza mediante un identificador único, una marca de tiempo y un colaborador, independientemente de si se realiza a través de la línea de comandos o directamente en la interfaz web de GitHub. Las confirmaciones proporcionan un registro de auditoría claro para todas las personas que revisen el historial de un archivo o un elemento vinculado, como una incidencia o una solicitud de incorporación de cambios.

Puede crear una confirmación mediante Git en el terminal con:

git commit -m "Add a helpful commit message"

Recorte de pantalla de una lista de las confirmaciones de GitHub en una rama principal.

Dentro de un repositorio de Git, un archivo puede existir en varios estados válidos durante su paso por el proceso de control de versiones. Los estados principales de un archivo de un repositorio de Git son Untracked y Tracked.

Sin seguimiento: Estado inicial de un archivo cuando aún no forma parte del repositorio de Git. Git desconoce su existencia.

Seguimiento: Un archivo con seguimiento es aquel que Git está supervisando activamente. Puede estar en uno de los siguientes subestados:

  • Sin modificar: Se realiza un seguimiento del archivo, pero no se ha modificado desde la última confirmación.
  • Modificado: el archivo ha cambiado desde la última confirmación, pero estos cambios aún no están almacenados provisionalmente para la siguiente confirmación.
  • Staged: El archivo se ha modificado y los cambios se han agregado al área de preparación (también conocida como índice). Estos cambios están listos para confirmarse.
  • Comprometido: El archivo se encuentra en la base de datos del repositorio. Representa la versión confirmada más reciente del archivo.

Estos estados ayudan a su equipo a comprender el estado de cada archivo y dónde se encuentra en el proceso de control de versiones.

¿Qué son las solicitudes de incorporación de cambios?

Una solicitud de incorporación de cambios es un mecanismo que sirve para indicar que las confirmaciones de una rama están listas para combinarse en otra.

El miembro del equipo que envía el pull request pide a uno o varios revisores que comprueben el código y aprueben la fusión. Estos revisores podrán comentar los cambios, agregar otros o usar la solicitud de incorporación de cambios para realizar un análisis más exhaustivo.

GitHub también admite borradores de solicitudes de incorporación de cambios, lo que le permite abrir una solicitud de incorporación de cambios que aún no está lista para su revisión.

Una vez que los cambios se han aprobado (si es necesario), la rama de origen de la solicitud de incorporación de cambios (la rama de comparación) se combina con la rama base.

Captura de pantalla de una solicitud de incorporación de cambios y un comentario dentro de la solicitud de incorporación de cambios.

Ahora que ha visto cómo funcionan las ramas, las confirmaciones y las solicitudes de incorporación de cambios, veamos cómo se unen en GitHub Flow.

El flujo de GitHub

Captura de pantalla que muestra una representación visual del flujo de GitHub en un formato lineal que incluye una nueva rama, confirmaciones, solicitud de incorporación de cambios y combinación de los cambios a main en ese orden.

El flujo de GitHub es un flujo de trabajo sencillo que le ayuda a realizar y compartir cambios de forma segura. Es excelente para probar ideas y colaborar con su equipo mediante ramas, solicitudes de incorporación de cambios y combinaciones.

Nota

El flujo de GitHub es uno de los flujos de trabajo más populares. Otros incluyen el flujo de Git y el desarrollo basado en troncos.

Ahora que conocemos los conceptos básicos de GitHub, podemos recorrer el flujo de GitHub y sus componentes.

  1. Empiece por crear una rama para que los cambios, características o correcciones no afecten a la rama principal.
  2. A continuación, realice las actualizaciones en la rama. Si el flujo de trabajo lo admite, puede implementar cambios de esta rama para probarlos antes de combinarlos.
  3. Ahora, abra una solicitud de incorporación de cambios para invitar a comentarios y comience una revisión.
  4. A continuación, revise los comentarios y realice las actualizaciones necesarias en función de los comentarios de su equipo.
  5. Por último, una vez que esté seguro de los cambios, obtenga la aprobación y combine la solicitud de incorporación de cambios en la rama principal.
  6. Después, elimine la rama para mantener el repositorio limpio y evitar el uso de ramas obsoletas.

Flujo de Git

Diagrama que ilustra el flujo de trabajo de Flujo de Git con carriles paralelos para ramas de características, desarrollo, ramas de versión, revisiones y maestros. Muestra cómo se combinan las características en desarrollo, las ramas de versión se crean a partir de desarrollo, las revisiones se bifurcan a partir del patrón y todos los cambios se combinan finalmente en maestro y se desarrollan con versiones etiquetadas.

Aunque GitHub Flow es un flujo de trabajo ligero diseñado para la entrega continua, el flujo de Git es un modelo de bifurcación más estructurado que se suele usar en entornos controlados por versiones. El flujo de Git ha estado alrededor de más tiempo que El flujo de GitHub, y es posible que siga viendo el término master usado en lugar de main como la rama predeterminada.

Tipos de rama de flujo de Git

El flujo de Git usa varias ramas temporales y de larga duración:

  • master: siempre refleja el código listo para producción.
  • develop: contiene el trabajo de desarrollo más reciente para la próxima versión.
  • feature/*: se usa para crear nuevas características; bifurcado de develop y combinado de nuevo cuando se complete.
  • release/*: prepara una nueva versión de producción desde develop; permite pruebas finales y correcciones de errores menores.
  • revisión/*: se usa para aplicar revisiones rápidas a los problemas de producción; bifurcado desde master.

Funcionamiento del proceso de flujo de Git

  1. Los desarrolladores crean ramas de características desde develop para crear nuevas funcionalidades.
  2. Cuando es el momento de una versión, se crea una rama de versión a partir de develop. Esto aísla el trabajo de preparación de la versión para que el desarrollo pueda continuar sin interrupciones.
  3. Las correcciones de errores se pueden agregar a la rama de versión, pero las características principales deben esperar a una versión futura.
  4. Una vez lista, la rama de versión se combina master y se etiqueta con un número de versión. GitHub puede usar estas etiquetas para ayudarle a generar notas de la versión.
  5. La misma rama de versión se debe combinar de nuevo en develop para mantenerla sincronizada.
  6. Si surge un error crítico de producción, se crea una rama de revisión a partir de master. Una vez corregido, se combina en y masterdevelop.

Cuándo usar el flujo de Git

  • Más adecuado para proyectos con versiones programadas o con versiones
  • Útil si mantiene varias versiones de producción (por ejemplo, ramas de soporte técnico a largo plazo)
  • Ideal para ciclos de desarrollo más lentos y estructurados (por ejemplo, entornos empresariales o regulados)
  • Se considera más "peso pesado" que GitHub Flow debido a la administración adicional de ramas

Nota

El flujo de Git supone confirmaciones de combinación para la integración de ramas. El uso de combinaciones de rebase o squash puede interferir con su estructura de rama y el seguimiento del historial.

Para muchos equipos que usan GitHub, GitHub Flow es más sencillo y rápido. Sin embargo, si el equipo valora la previsibilidad y necesita más planeamiento de versiones, el flujo de Git puede ser una mejor opción.

¡Felicidades! Acaba de recorrer el flujo completo de GitHub y ha explorado cómo el flujo de Git ofrece una alternativa estructurada para los proyectos controlados por versiones.

Vamos a pasar a la siguiente sección donde trataremos las diferencias entre incidencias y discusiones.