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
masteruna 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 masterSe extraen las últimas confirmaciones:
git fetch originY 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/masterCrear 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-funcionalidadA 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 «archivo(s)»
git commit «archivo(s)»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-funcionalidadUsando 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.
Referencias
- Git Feature Branch Workflow de los tutoriales de Atlassian
- Apartado 1 de 5 Git workflow best practices you’ve got to use
- Git Feature Branches
- My Git Feature-Branch Workflow
- Simple Git feature branch workflow
Otras referencias
Última revisión: 27/06/2020
Dejar un comentario
¿Quieres unirte a la conversación?Siéntete libre de contribuir!