Ramas y estrategias de ramificación
Las en Git te permiten separarte de la línea principal de desarrollo 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 rama que se crea siempre al inicializar un repositorio nuevo.
Las ramas son, simplemente, punteros a commits. Hay otro puntero llamado HEAD que apunta al commit que tienes actualmente en tu directorio de trabajo, normalmente el último commit de una rama. Cuando creas un commit nuevo, el puntero de la rama avanza hasta ese commit, igual que HEAD. Cuando cambias de rama, HEAD se mueve al último commit de la nueva rama.
Ahora pasemos a las estrategias de ramificación, que forman parte del . Una estrategia de ramificación 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 con 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 da a los proyectos complejos con varias versiones un camino claro desde desarrollo hasta producción. Eso sí, es bastante complejo y puede ser excesivo para proyectos pequeños. -
Flujo con forks. Cada desarrollador tiene su propio y envía pull requests al repositorio principal, donde alguien con acceso de escritura revisa y fusiona 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 trabaja en una copia propia, y el proyecto principal solo acepta cambios revisados.
No existe una estrategia de ramificación 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 ramificación, vamos a crear nuestra primera rama de funcionalidad.
Haz el curso como estaba pensado: progreso en pequeñas dosis, un orden lineal y sin distracciones, y entradas de Gitopedia que se desbloquean poco a poco. Continúa con Git real en VS Code/Cursor/Antigravity/Windsurf cuando quieras.
pero requiere iniciar sesión