Bases

  • El desarrollo de cada nueva funcionalidad se realizará en una rama dedicada en lugar de la rama maestra.
  • Se solicitará a los demás desarrolladores la revisión de la nueva funcionalidad antes de integrarla.
  • Una vez aceptada la nueva funcionalidad se fusionará en la rama maestra.

Resumen de uso

  • Descargar la rama principal
    git checkout master
    git fetch origin
    git reset --hard origin/master
  • Crear una rama para la nueva funcionalidad
    git checkout -b nueva-funcionalidad
  • Modificar, añadir y confirmar
    git status
    git add {archivo(s)}
    git commit
  • Subir la nueva rama al respositorio remoto
    git push -u origin nueva-funcionalidad
  • Solicitar la revisión del código al resto del equipo
  • Fusionar la funcionalidad en la rama master una vez acabado el desarrollo y resuelto los conflictos

Ventajas

  • Múltiples desarrolladores pueden trabajar en una característica particular sin alterar el código de la rama maestra.
  • La rama maestra siempre contiene código probado y estable, facilitando el desarrollo en entornos de integración continua.
  • No es necesario que cada revisión de código sea completamente funcional.
  • Se pueden solicitar revisiones del código también para pedir sugerencias en caso de bloqueo o dudas, facilitando al equipo comentar y participar en el trabajo de otros.
  • Puede usarse en otros flujos de trabajo. Por ejemplo, Git Flow y Git Forking lo usan en sus modelos de ramificación.
  • Es útil para cambios que no sean necesariamente nuevas funcionalidades; por ejemplo, para pruebas de concepto o cambios en el diseño que puedan afectar a la estabilidad del código.

Inconvenientes

  • Requiere fusiones frecuentes de la rama maestra en la rama de trabajo para minimizar los conflictos en la fusión final.
  • Puede requerir actualizaciones periódicas de la rama de trabajo en el repositorio remoto durante el desarrollo para evitar conflictos.
  • Es adecuado para equipos pequeños. Para equipos más grandes, considerar Git Flow.

Cómo funciona

Descargar la rama principal

Las nuevas ramas se crearán a partir del último código estable del proyecto, que esta guía asume que es la rama master. Primero se cambia el repositorio a la rama principal:

git checkout master

Se extraen las últimas confirmaciones:

git fetch origin

Y se restablece la copia local de la rama master para que coincida con la última versión (descartando cualquier confirmación que no esté en la rama principal):

git reset --hard origin/master

Crear una rama para la nueva funcionalidad

Elegir un nombre significativo para la rama que identifique perfectamente el propósito de la nueva funcionalidad. Por ejemplo funcionalidad-animar-items-menu o funcionalidad-#1061:

git checkout -b nueva-funcionalidad

A partir de este momento, cualquier cambio se realizará únicamente en esta nueva rama.

Modificar, añadir y confirmar

Se trabajará normalmente con Git, modificando, organizando y usando tantas confirmaciones como sea necesario:

git status
git add 
git commit

Subir la nueva rama al respositorio remoto

Es una buena idea subir la nueva rama al repositorio remoto, ya sea como copia de seguridad o, si se colabora con otros desarrolladores, para dar acceso a las actualizaciones de la nueva funcionalidad:

git push -u origin nueva-funcionalidad

Usando el argumento -u se asumen origin y nueva-funcionalidad como referencia. Las siguientes veces sólo habrá que ejecutar git push para mantener actualizada la rama en el repositorio remoto.

Revisión del código

Para recibir impresiones, comentarios, sugerencias o cambios sobre la nueva funcionalidad, realiza una solicitud de revisión del código en tu repositorio de GitLab, Bitbucket ó GitHub.

Resuelve localmente los cambios sugeridos por los miembros del equipo, confirma (commit) y envía (push) los cambios al repositorio remoto. Las actualizaciones aparecerán en la solicitud abierta de revisión del código.

Integrar la nueva funcionalidad

Antes de fusionar es posible que tengas que resolver conflictos debido a cambios realizados por otros desarrolladores en el repositorio.

Una vez aprobada la revisión del código y no haya conflictos por resolver, entonces se podrá fusionar en la rama master.

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *