Ramas y estrategias de ramas
Las en Git te permiten abrir una línea de desarrollo aparte y trabajar de forma independiente sin afectar a la base de código principal. Es como tener tu propio universo paralelo donde puedes experimentar, desarrollar funcionalidades nuevas o corregir errores sin tocar la versión estable del proyecto.
Empecemos listando todas las ramas de tu repositorio. Puedes hacerlo usando el comando sin argumentos.
Usa el comando git branch para listar todas las ramas.
Si no has hecho experimentos secretos por tu cuenta, deberías ver solo una rama: tu rama predeterminada main. Es la que se crea al inicializar un repositorio nuevo.
Las ramas son, simplemente, punteros a commits. Hay otro puntero llamado HEAD, que señala el commit activo en tu directorio de trabajo; normalmente, el último de una rama. Cuando creas un commit, tanto el puntero de la rama como HEAD avanzan hasta él. Al cambiar de rama, HEAD se mueve al último commit de la nueva rama.
Ahora pasemos a las estrategias de ramas, que forman parte del . Una estrategia de ramas es un conjunto de reglas y pautas para crear, nombrar y gestionar ramas en un proyecto. En un proyecto grande con muchos desarrolladores puede haber cientos de ramas, y una buena estrategia ayuda a mantenerlo todo organizado y manejable. Estos son algunos flujos de trabajo habituales con Git:
-
Flujo centralizado. Todos los desarrolladores trabajan en una sola rama, normalmente la rama
main. Este flujo es el más sencillo, pero complica el trabajo en paralelo porque todo el mundo modifica la misma rama. Lo suelen usar equipos que antes trabajaban con los antiguos sistemas centralizados de control de versiones. -
Flujo con ramas de funcionalidad. Cada funcionalidad nueva se desarrolla en su propia rama y, cuando está terminada, se fusiona en la rama
main. Es el flujo de trabajo más habitual para equipos que usan Git. Permite que los desarrolladores trabajen en varias funcionalidades a la vez sin estorbarse entre sí. -
Flujo Gitflow. Gitflow usa ramas de larga duración como
mainydevelop, además de ramas de corta duración para funcionalidades, lanzamientos y correcciones urgentes (feature,releaseyhotfix). Este flujo ofrece a los proyectos complejos con varias versiones un proceso claro para pasar del desarrollo a producción. Eso sí, es bastante complejo y puede ser excesivo para proyectos pequeños. -
Flujo con forks. Cada desarrollador tiene su propio (copia) del repositorio y abre pull requests al repositorio principal, donde alguien con acceso de escritura revisa y hace un merge de los cambios. Este flujo es común en proyectos de código abierto, donde las personas que contribuyen no tienen acceso de escritura al repositorio principal. Cada contribución se prepara en una copia propia, y el proyecto principal solo acepta cambios revisados.
No existe una estrategia de ramas universal que sirva para todo. El mejor enfoque depende del tamaño y la complejidad del proyecto, del número de personas que contribuyen y del ciclo de publicación.
Ahora que ya conoces las estrategias de ramas, ¡vamos a crear nuestra primera rama de funcionalidad!
Haz el curso como se pensó: avanza poco a poco y en orden, sin distracciones, mientras desbloqueas nuevas entradas de Gitopedia. Cuando quieras, continúa practicando con Git de verdad en VS Code, Cursor o Antigravity IDE.
pero requiere iniciar sesión