Saltar a contenido

Capítulo 6. Ramas (Branches): desarrolla sin miedo

Introducción

Hasta este punto del libro, el trabajo se ha realizado sobre una sola línea principal de desarrollo. Esa forma de avanzar resulta útil para aprender la base de Git, pero tiene una limitación importante: cualquier cambio nuevo afecta directamente la versión actual del proyecto, incluso cuando todavía está incompleto o en prueba. En proyectos reales, esa situación se vuelve riesgosa muy rápido.

Las ramas resuelven precisamente ese problema. La documentación oficial de Git define git branch como el comando para listar, crear o eliminar ramas, y presenta a las ramas como referencias que apuntan a líneas de desarrollo dentro del historial. Gracias a ello, un desarrollador puede abrir caminos de trabajo independientes para crear nuevas funcionalidades, corregir errores o experimentar, sin alterar de inmediato la versión principal del proyecto.

En este capítulo se continuará utilizando el mismo proyecto iniciado en el Capítulo 2. No se crearán repositorios nuevos. Toda práctica se realizará sobre ese repositorio, generando nuevas ramas para construir funcionalidades separadas y luego integrarlas correctamente a main mediante merge.

El propósito central es que el lector aprenda a trabajar sin miedo. Eso no significa trabajar sin cuidado, sino desarrollar con aislamiento, criterio y control. Una rama bien utilizada permite probar ideas con libertad porque el proyecto estable sigue protegido mientras la nueva funcionalidad evoluciona por separado.

6.1 ¿Qué es una rama?

Una rama, o branch, es una línea independiente de desarrollo dentro del mismo repositorio. En términos prácticos, Git permite que el historial del proyecto continúe por diferentes caminos sin perder la relación entre ellos, y después ofrece mecanismos para integrarlos cuando sea conveniente.

Una analogía sencilla

Imagina que estás escribiendo un libro técnico y quieres reescribir completamente un capítulo, pero no deseas tocar todavía la versión aprobada. En lugar de editar el documento principal directamente, haces una copia de trabajo y experimentas ahí. Si el resultado es bueno, luego incorporas ese contenido al documento oficial. Si no funciona, simplemente descartas la copia.

Eso mismo hacen las ramas en Git. No duplican el proyecto de forma torpe ni crean un caos de carpetas manuales; más bien crean una nueva línea de trabajo que parte de un punto concreto del historial. Esa línea permite hacer commits propios, avanzar con independencia y mantener intacta la rama estable mientras el trabajo nuevo todavía no está listo.

Otra analogía útil: laboratorio y versión estable

También puede pensarse en una rama como un laboratorio. main sería la versión estable que debe permanecer confiable, mientras que una rama de trabajo sería una mesa de experimentación donde se prepara una funcionalidad nueva. Si el experimento funciona, se incorpora. Si todavía no está listo, no afecta la versión principal.

Esta idea cambió profundamente el desarrollo de software porque permitió dejar atrás flujos mucho más frágiles, en los que todo se hacía sobre una sola línea de código y cualquier cambio en progreso podía romper el estado estable del proyecto. Con ramas, varias tareas pueden avanzar de manera paralela dentro del mismo repositorio sin pisarse entre sí.

Qué representa realmente una rama

Aunque al principio parezca una “copia del proyecto”, una rama no debe entenderse como una duplicación completa en sentido tradicional. Desde la perspectiva de Git, una rama es una referencia móvil a un commit dentro del historial. Cuando se crean nuevos commits sobre esa rama, la referencia avanza para apuntar al commit más reciente de esa línea de trabajo.

Esto explica por qué las ramas en Git son tan prácticas: no se trata de clonar carpetas manualmente, sino de mover referencias dentro de una historia compartida. El resultado para el usuario se siente como un espacio independiente de trabajo, pero con una estructura mucho más eficiente y controlada.

Qué problema resuelven

Las ramas resuelven varios problemas cotidianos del desarrollo:

  • Permiten probar una nueva funcionalidad sin romper la versión estable.
  • Facilitan trabajar en varias tareas distintas dentro del mismo repositorio.
  • Ayudan a mantener un historial más limpio, porque cada línea de trabajo puede tener su propio conjunto de commits.
  • Hacen posible integrar cambios cuando ya están listos, en lugar de mezclar todo desde el principio.

Comparación: trabajar con y sin ramas

Antes de profundizar en comandos, conviene visualizar la diferencia entre modificar directamente la rama principal y hacerlo mediante una rama separada.

flowchart LR
    A[Sin ramas: trabajar siempre en main] --> B[Cada cambio afecta la versión estable]
    B --> C[Mayor riesgo de romper el proyecto]

    D[Con ramas: crear branch de trabajo] --> E[Desarrollo aislado]
    E --> F[Integración solo cuando está listo]

En el primer caso, el proyecto principal queda expuesto desde el inicio. En el segundo, la rama actúa como una zona de seguridad entre la idea en construcción y la versión estable. Esa separación es una de las razones por las que Git transformó la manera de organizar el desarrollo profesional.

Ejemplo aplicado al proyecto del libro

Supón que el proyecto del libro ya tiene una página principal funcional y ahora se desea agregar una nueva sección de contacto. Si esa modificación se hace directamente sobre main, cualquier error de estructura, estilos o enlaces afectará la rama principal desde el primer momento. En cambio, si se crea una rama como feature/contacto, todo el desarrollo puede ocurrir ahí, con sus propios commits, hasta que la funcionalidad quede lista para integrarse.

Error conceptual frecuente

Error común

Pensar que una rama es “otro repositorio”. No lo es. Sigue siendo el mismo proyecto y el mismo historial general, pero con una línea de desarrollo distinta dentro de ese historial.

Consejo

Cuando una tarea implique riesgo, experimentación o cambios todavía incompletos, crea una rama. Es más fácil descartar una línea de trabajo que limpiar una rama principal mal cuidada.

Conclusión de la sección

Una rama es una línea independiente de desarrollo que permite trabajar con seguridad dentro del mismo repositorio. Gracias a ellas, Git hizo posible experimentar, construir funcionalidades en paralelo e integrar cambios con mucho más control que en los modelos de desarrollo lineal tradicionales.

6.2 La rama principal (main)

La rama main representa la línea principal del proyecto. Es el punto de referencia estable sobre el que se apoyan nuevas funcionalidades, correcciones e integraciones posteriores. En muchos repositorios modernos, main es la rama por defecto y suele considerarse la versión base más confiable del trabajo en curso.

Qué representa main

main no es “la rama donde se hace todo”, sino la rama donde debe vivir el estado más estable del proyecto. Esa estabilidad no significa perfección absoluta, pero sí un nivel razonable de consistencia: archivos organizados, cambios ya revisados y evolución comprensible del historial.

En el proyecto del libro, main debe representar la versión principal del sitio o aplicación tal como se ha ido consolidando desde el Capítulo 2. Si el lector necesita construir una nueva página, agregar un formulario o refinar una sección completa, la idea profesional no es tocar main directamente, sino partir desde ahí hacia una rama nueva de trabajo.

Por qué debe mantenerse estable

La estabilidad de main tiene un valor técnico y también organizativo. Si main se llena de cambios incompletos, pruebas sueltas o funcionalidades a medio construir, deja de ser una base confiable para continuar trabajando. Además, cualquier integración posterior se vuelve más difícil de entender porque desaparece la frontera entre lo estable y lo experimental.

Mantener main estable produce varios beneficios:

  • Facilita saber cuál es el estado principal del proyecto.
  • Reduce el riesgo de dañar la base del trabajo diario.
  • Hace más claras las integraciones desde ramas de funcionalidad.
  • Permite que el historial principal represente avances ya consolidados.

Cuándo debe modificarse

En el contexto de este capítulo, main debe modificarse principalmente cuando una rama de trabajo ya terminó su objetivo y está lista para integrarse. Esa integración ocurre mediante merge, que incorpora a la rama actual los cambios de otra línea de desarrollo.

Esto significa que main sí cambia, pero debería hacerlo en el momento adecuado: cuando una funcionalidad ya fue desarrollada, revisada y confirmada con commits claros en su propia rama. No debe ser la zona donde se improvisa el primer borrador de una idea.

Buenas prácticas para main

Práctica Por qué conviene
Usar main como base estable Mantiene un punto principal confiable.
Crear ramas para cada funcionalidad Evita mezclar trabajo en progreso con la versión principal.
Hacer merge solo cuando el cambio está listo Protege la claridad del historial.
Evitar pruebas improvisadas en main Reduce errores y retrabajo
Verificar la rama actual antes de editar Evita trabajar por accidente donde no corresponde.

Diagrama: estructura básica de ramas

Antes de practicar, conviene observar la relación entre main y una rama de trabajo típica.

gitGraph
    commit id: "Base estable"
    branch feature-contacto
    checkout feature-contacto
    commit id: "Diseño formulario"
    commit id: "Validación inicial"
    checkout main
    commit id: "Ajuste menor estable"

Este diagrama muestra una idea central: desde un mismo punto de partida pueden salir líneas distintas de desarrollo. main continúa existiendo como referencia principal, mientras la rama feature-contacto avanza por su cuenta con commits específicos de esa funcionalidad.

Relación con el proyecto del libro

En el proyecto que viene construyéndose, main debe verse como la versión que siempre podría mostrarse como base de trabajo. Si el lector va a agregar una nueva página de contacto, una sección adicional o una hoja de estilos específica, esa evolución debe empezar en una rama nueva. Solo cuando la funcionalidad quede coherente y completa se integrará a main.

Ejemplo correcto e incorrecto

Correcto:

  1. Estar en main.
  2. Crear feature/contacto.
  3. Desarrollar ahí la nueva sección.
  4. Hacer varios commits.
  5. Volver a main.
  6. Integrar con merge.

Incorrecto:

  1. Estar en main.
  2. Empezar a crear la nueva sección directamente ahí.
  3. Dejar código incompleto mezclado con la versión principal.
  4. Seguir acumulando pruebas y correcciones sobre la misma rama.

El segundo flujo parece más rápido al inicio, pero normalmente termina siendo más desordenado y arriesgado.

Buenas prácticas

Trata main como una mesa limpia de presentación. Si el trabajo todavía está en construcción, no pertenece ahí todavía.

¿Sabías que...?

Git permite listar ramas, mostrar la rama actual y ver cuáles ya fueron fusionadas mediante opciones de git branch como --show-current y --merged. Eso ayuda a mantener ordenada la relación entre main y las ramas de trabajo.

Conclusión de la sección

La rama main representa la base principal y estable del proyecto, por lo que debe modificarse con intención y no como espacio de experimentación. Cuando el lector entiende este rol, trabajar con ramas deja de ser un truco opcional y se convierte en una disciplina profesional.

6.3 Creando una nueva rama

Crear una rama es el primer paso para aislar una nueva funcionalidad. Git ofrece varias formas de hacerlo, y comprender sus diferencias evita confusiones desde el inicio. La documentación oficial distingue con claridad entre crear una rama, listar ramas, cambiar de rama y combinar ambos pasos en un solo comando.

git branch

El comando git branch sirve para listar, crear o eliminar ramas. Cuando se utiliza con un nombre nuevo, crea la rama, pero no cambia automáticamente a ella.

Ejemplo:

git branch feature/contacto

Después de ejecutar ese comando, la rama existe, pero el trabajo sigue ubicado en la rama actual. Esto es importante porque muchos principiantes creen que crear una rama basta para empezar a trabajar en ella. No es así. Si después de git branch feature/contacto se edita un archivo sin cambiar de rama, esos cambios seguirán ocurriendo en la rama anterior.

git switch -c

La documentación oficial de git switch indica que la opción -c crea una nueva rama y cambia inmediatamente a ella. Git la describe como el equivalente transaccional de ejecutar primero git branch <nueva-rama> y luego git switch <nueva-rama>.2

Ejemplo:

git switch -c feature/contacto

Este comando resulta especialmente cómodo para el trabajo diario porque une en una sola instrucción dos acciones que normalmente van juntas: crear la rama y empezar a trabajar en ella.

git checkout -b

La documentación oficial de git checkout también admite la creación y cambio inmediato de rama mediante la opción -b. En términos prácticos, cumple la misma idea operativa que git switch -c: crea una rama nueva y mueve el trabajo a esa rama en el mismo paso.

Ejemplo:

git checkout -b feature/contacto

Diferencias entre estos comandos

Aunque los tres comandos pueden participar en el inicio de una nueva línea de trabajo, no hacen exactamente lo mismo.

Comando Qué hace ¿Cambia de rama?
git branch feature/contacto Crea la rama. No
git switch -c feature/contacto Crea la rama y cambia a ella. Sí
git checkout -b feature/contacto Crea la rama y cambia a ella. Sí

Cuándo usar cada uno

  • Usa git branch cuando quieras crear una rama sin abandonar todavía la actual.
  • Usa git switch -c cuando quieras crear la rama y comenzar a trabajar en ella inmediatamente.
  • Usa git checkout -b cuando trabajes en entornos o materiales donde aún se use checkout como comando multifunción, o cuando debas interpretar documentación más antigua.

switch y checkout: una distinción importante

Git introdujo git switch para separar con mayor claridad la operación de cambio de ramas respecto al uso más amplio y ambiguo de git checkout. checkout puede operar sobre ramas, commits y archivos, mientras que switch está enfocado específicamente en cambiar ramas o crear una nueva durante el cambio.

Eso hace que, para fines didácticos y para el trabajo diario centrado en ramas, git switch sea más expresivo y menos propenso a confusión. Sin embargo, git checkout sigue siendo válido y muy frecuente en documentación, cursos y proyectos heredados.

Crear una rama desde un punto de partida específico

La documentación de git branch y git switch también permite crear ramas a partir de un punto concreto del historial, no solo desde el HEAD actual. En este capítulo no se explorarán casos avanzados, pero es útil saber que una rama puede nacer desde otra rama o desde un commit específico cuando el flujo lo requiere.

Ejemplo guiado: crear ramas en el proyecto del libro

Supón que el proyecto del libro está en main y ahora se quieren preparar dos mejoras independientes:

  • una nueva página de contacto;
  • una mejora visual del pie de página.

Primera opción, paso a paso, con creación y cambio separados:

git branch feature/contacto
git switch feature/contacto

Segunda opción, más directa:

git switch -c feature/footer

Tercera opción, equivalente clásica:

git checkout -b feature/formulario

En todos los casos, la idea profesional es la misma: cada funcionalidad vive en su propia rama, no en main.

Error común: crear la rama y seguir trabajando en la anterior

Error común

Ejecutar git branch feature/contacto y comenzar a editar archivos de inmediato, sin hacer git switch feature/contacto. En ese caso, la rama nueva existe, pero los cambios siguen ocurriendo en la rama donde ya estabas.

Consejo

Si el objetivo es empezar a trabajar de inmediato en la nueva rama, git switch -c suele ser la opción más clara y menos propensa a olvidos.

Conclusión de la sección

Crear ramas en Git es sencillo, pero la diferencia entre crear una rama y cambiar a ella debe quedar completamente clara. Dominar git branch, git switch -c y git checkout -b permite iniciar nuevas funcionalidades con orden y sin contaminar la línea principal del proyecto.

6.4 Cambiando entre ramas

Crear ramas es solo la mitad del trabajo. La otra mitad consiste en moverse entre ellas de forma segura, entendiendo qué cambia en el directorio de trabajo, cómo saber dónde se está trabajando y qué precauciones conviene tomar antes de cambiar de contexto.

git switch

La documentación oficial describe git switch como el comando para cambiar a una rama especificada. Al hacerlo, el árbol de trabajo y el índice se actualizan para coincidir con esa rama, y todos los nuevos commits se agregarán a la punta de esa línea de desarrollo.

Ejemplo:

git switch main

Si se ejecuta ese comando estando en una rama de funcionalidad, Git mueve el contexto de trabajo hacia main y actualiza los archivos rastreados para reflejar el estado almacenado en esa rama.

git checkout

git checkout también puede usarse para cambiar de rama. Cuando se utiliza con el nombre de una rama, Git actualiza el directorio de trabajo para que coincida con el contenido de esa rama y registra que los nuevos commits pertenecerán a esa línea.

Ejemplo:

git checkout feature/contacto

Aunque sigue siendo válido, checkout es más amplio y más ambiguo que switch, ya que también puede usarse para revisar commits o manipular archivos. Por eso, en un capítulo enfocado en ramas, switch suele ser más legible.

Cómo desplazarse entre ramas

El cambio cotidiano entre ramas suele seguir este patrón:

  1. Verificar en qué rama se está trabajando.
  2. Confirmar o resguardar cambios pendientes si hace falta.
  3. Ejecutar git switch nombre-rama o git checkout nombre-rama.
  4. Revisar que el contexto haya cambiado correctamente.

Git también permite regresar rápidamente a la rama anterior usando git switch -, como indica la documentación oficial de git switch. Esta pequeña opción es muy útil cuando se alterna entre main y una rama de trabajo durante revisiones o integraciones cortas.

Qué ocurre con los archivos al cambiar de rama

Cuando se cambia de rama, Git actualiza el directorio de trabajo y el índice para reflejar el contenido de la rama de destino. Esto significa que algunos archivos pueden cambiar, aparecer o desaparecer según la historia de cada rama.

En el proyecto del libro, por ejemplo, si la rama feature/contacto contiene una nueva página contacto.html y main todavía no la tiene, al volver a main ese archivo dejará de formar parte del estado activo del directorio rastreado. Cuando se regrese a feature/contacto, volverá a aparecer como parte de esa línea de trabajo. Este comportamiento suele sorprender al principio, pero es precisamente la señal de que Git está mostrando el estado de cada rama como una versión coherente del proyecto.

Qué pasa si hay cambios pendientes

La documentación oficial de git switch aclara que cambiar de rama no requiere necesariamente un directorio completamente limpio, pero la operación se aborta si el cambio pudiera provocar pérdida de modificaciones locales, salvo que se usen opciones específicas. Para este capítulo, la regla práctica debe ser sencilla: antes de cambiar de rama, conviene confirmar o dejar en un estado seguro el trabajo actual.

Esa disciplina evita situaciones confusas, sobre todo en etapas tempranas de aprendizaje. No se trata de memorizar todos los casos especiales, sino de adoptar un hábito limpio: terminar una unidad de trabajo, hacer commit y luego moverse a otra rama.

Cómo verificar la rama actual

La documentación oficial de git branch incluye la opción --show-current, que imprime el nombre de la rama actual. También puede usarse git branch a secas para listar ramas, donde la rama actual aparece destacada y marcada con un asterisco.

Ejemplos:

git branch

git branch --show-current

Estos comandos son pequeños, pero muy valiosos. Muchos errores en Git no se deben a comandos complejos, sino a trabajar en la rama equivocada por no verificarla antes.

Tabla: switch y checkout

Comando Enfoque principal Ventaja didáctica
git switch rama Cambiar entre ramas. Más claro para trabajo con ramas
git checkout rama Cambiar entre ramas, commits o archivos. Muy común en documentación previa
git switch - Volver a la rama anterior. Muy práctico para alternar contextos

Ejemplo guiado: alternando entre ramas del proyecto

Imagina esta secuencia en el repositorio del libro:

  1. Estás en main.
  2. Creas feature/contacto.
  3. Agregas avances a la nueva página de contacto y haces un commit.
  4. Quieres volver a main para revisar la versión estable.

Comandos posibles:

git switch main

Después, para regresar a la rama anterior:

git switch -

Y para verificar la rama activa:

git branch --show-current

Este flujo sencillo demuestra algo importante: moverse entre ramas debe sentirse normal, no peligroso, siempre que se haga con cambios bien controlados.

[Ilustración: captura de terminal y editor mostrando el cambio entre ramas del proyecto del libro; en la terminal debe verse la ejecución de git switch main y git branch --show-current, mientras en el explorador de archivos del editor se aprecia que ciertos archivos aparecen o desaparecen según la rama activa, reforzando la idea de que cada rama tiene su propio estado del proyecto.]

Error común: olvidar cambiar de rama

Error común

Crear una rama para una funcionalidad nueva y luego seguir desarrollando directamente en main por no haber hecho el cambio efectivo de rama. Este error suele detectarse tarde, cuando ya existen varios commits donde no deberían estar.

Buenas prácticas

Antes de editar archivos importantes, verifica la rama actual. Un segundo de comprobación puede evitar una sesión completa de correcciones después.

Conclusión de la sección

Cambiar entre ramas en Git significa cambiar el contexto activo de trabajo y actualizar los archivos para reflejar la línea de desarrollo elegida. Cuando el lector domina git switch, entiende qué pasa con el directorio de trabajo y acostumbra verificar la rama actual, empieza a moverse con verdadera seguridad dentro del repositorio.

6.5 Desarrollando una funcionalidad

El valor real de las ramas se comprende cuando se usan para construir algo concreto. En esta sección, el proyecto del libro incorporará una nueva funcionalidad: una página de contacto con su estructura inicial y una hoja de estilos asociada. Todo el trabajo se realizará dentro de una rama independiente, de principio a fin.

Objetivo de la funcionalidad

La nueva característica consistirá en agregar al proyecto:

  • un archivo contacto.html;
  • una sección con información de contacto;
  • un formulario básico de estructura;
  • estilos iniciales en css/contacto.css.

Lo importante no es la complejidad del resultado, sino el flujo profesional con el que se desarrolla: crear rama, trabajar ahí, hacer varios commits y mantener main intacta hasta la integración final.

Paso 1. Partir desde main

Antes de abrir una nueva línea de trabajo, conviene situarse en la rama principal y verificar que se parte de una base clara.

git switch main
git branch --show-current

Ese pequeño gesto evita crear una rama desde el lugar equivocado. En Git, una rama nueva se crea apuntando al HEAD actual si no se indica otro punto de inicio. Por eso, la rama debe nacer desde la base correcta del proyecto.

Paso 2. Crear una rama para la funcionalidad

Ahora se crea una rama específica para esta mejora.

git switch -c feature/contacto

Con este comando, Git crea la rama y cambia de inmediato a ella. Desde este momento, todos los nuevos commits quedarán registrados en feature/contacto, no en main.

Paso 3. Construir la primera versión

En esta rama se puede comenzar con una primera versión mínima de la nueva funcionalidad. Por ejemplo:

  • crear contacto.html;
  • agregar un encabezado con el título “Contacto”;
  • incluir una breve introducción;
  • enlazar una nueva hoja css/contacto.css.

En este punto conviene guardar archivos y revisar el estado:

git status
git branch --show-current

Aunque este capítulo está orientado a ramas, sigue siendo importante conservar los buenos hábitos aprendidos en capítulos anteriores: revisar cambios, preparar con intención y hacer commits claros.

Paso 4. Primer commit de la funcionalidad

Una vez creada la estructura inicial, se prepara y se confirma.

git add contacto.html css/contacto.css
git commit -m "Agrega estructura inicial de la página de contacto"

La documentación oficial de git commit indica que el commit crea una nueva confirmación con el contenido actual del índice y el mensaje proporcionado.4 Ese principio sigue intacto dentro de una rama: la diferencia es que el historial avanza ahora en una línea de desarrollo separada.

Paso 5. Continuar con mejoras incrementales

En lugar de hacer un único commit enorme, el flujo profesional recomienda avanzar por partes. Por ejemplo:

  • añadir campos al formulario;
  • incorporar una sección de correo y teléfono;
  • aplicar estilos básicos de espaciado y color;
  • corregir textos o etiquetas.

Ejemplo de siguientes commits:

git add contacto.html
git commit -m "Agrega campos principales al formulario de contacto"

git add css/contacto.css
git commit -m "Define estilos base para la sección de contacto"

Este enfoque produce una historia mucho más clara que un único commit con veinte cambios mezclados. Si después se revisa el historial, será fácil entender cómo evolucionó la funcionalidad paso a paso.

Diagrama: línea temporal de commits en una rama

El siguiente diagrama muestra cómo una funcionalidad puede crecer con varios commits dentro de su propia rama.

gitGraph
    commit id: "main estable"
    branch feature-contacto
    checkout feature-contacto
    commit id: "Estructura inicial"
    commit id: "Campos del formulario"
    commit id: "Estilos base"

Cada commit representa una unidad comprensible de avance. En vez de ocultar todo dentro de un bloque gigante, el historial cuenta una historia técnica ordenada, lo que facilita revisar y luego integrar el trabajo.

Paso 6. Verificar aislamiento respecto a main

Una de las mejores formas de comprender las ramas es comprobar que main sigue intacta mientras la nueva funcionalidad avanza. Para hacerlo:

git switch main

Al volver a main, la nueva página y sus cambios dejarán de aparecer como parte del estado activo si todavía no han sido integrados. Después, para continuar el desarrollo:

git switch feature/contacto

Este ida y vuelta demuestra con claridad el aislamiento entre ramas. La funcionalidad existe, pero vive solo donde debe vivir: en su propia línea de trabajo.

Ejemplo correcto e incorrecto

Correcto:

  • Crear feature/contacto.
  • Hacer varios commits pequeños dentro de esa rama.
  • Volver a main solo para revisar o integrar después.

Incorrecto:

  • Empezar la página en feature/contacto.
  • Olvidar cambiar de rama.
  • Seguir editando en main parte de la misma funcionalidad.
  • Mezclar commits repartidos entre ramas distintas.

Ese segundo caso rompe la principal ventaja del modelo: la separación limpia del trabajo.

Error frecuente: una rama para varias cosas distintas

Error común

Crear una sola rama y aprovecharla para meter varias funcionalidades no relacionadas, por ejemplo contacto, cambios visuales generales y correcciones de navegación. Eso vuelve más difícil revisar, integrar o descartar el trabajo después.

Consejo

Una rama debe responder a un objetivo claro. Si aparece una tarea diferente, normalmente merece su propia rama.

Conclusión de la sección

Desarrollar una funcionalidad en una rama independiente permite avanzar con orden, crear varios commits claros y proteger la estabilidad de main mientras el trabajo todavía está en construcción. Ese aislamiento es la base del uso profesional de ramas en Git.

6.6 Integrando los cambios

Una rama de trabajo cumple su propósito cuando llega el momento de incorporar sus cambios a la línea principal del proyecto. Para eso existe git merge, comando que la documentación oficial describe como la herramienta para unir dos o más historiales de desarrollo.3 En este capítulo se utilizará en su forma básica: integrar una rama de funcionalidad terminada en main.

Qué hace git merge

git merge toma los cambios de otra rama y los incorpora a la rama actual. Este detalle es esencial: el merge no se ejecuta “sobre la rama que se quiere traer”, sino sobre la rama que recibirá los cambios.

Eso significa que, si se quiere integrar feature/contacto en main, primero debe activarse main y después ejecutar el merge de la rama de funcionalidad.

Ejemplo:

git switch main
git merge feature/contacto

Qué ocurre durante un merge

Durante la fusión, Git compara las historias involucradas y trata de combinar los cambios en una única línea coherente. Si la integración puede resolverse de manera directa, el proceso termina automáticamente y el contenido de la rama de funcionalidad pasa a formar parte de main.

En términos prácticos, si feature/contacto agregó archivos nuevos como contacto.html y css/contacto.css, y main no hizo cambios incompatibles en esas mismas áreas, Git podrá incorporar todo sin dificultad.

Qué sucede con el historial

El historial conserva la relación entre ambas líneas de trabajo. Dependiendo de la situación, Git puede avanzar la rama receptora o crear un commit de merge para unir explícitamente ambas trayectorias. Para el nivel de este capítulo, basta con comprender que el merge no “borra” la historia de la rama, sino que la integra en la línea principal.

Cuándo un merge es automático

Un merge puede ser automático cuando Git logra combinar los cambios sin encontrar incompatibilidades que exijan intervención manual. En otras palabras, si las dos líneas de trabajo no compiten por modificar de forma incompatible la misma parte del proyecto, Git puede resolver la integración por sí mismo.

Este es justamente el escenario ideal para un flujo ordenado con ramas pequeñas y bien enfocadas. Cuanto más clara sea una rama y más concreto su objetivo, más probable será que su integración sea directa.

Lo que no se verá todavía

En ocasiones, Git no puede integrar automáticamente una rama porque detecta cambios incompatibles en archivos o fragmentos coincidentes. Ese tema corresponde al siguiente capítulo. Aquí solo se trabajará con merges simples o automáticos, donde el lector pueda concentrarse en entender el flujo general sin entrar todavía en resolución manual de conflictos.

Diagrama: Branch → Merge

Antes de ejecutar la integración, conviene observar el recorrido completo de una funcionalidad desde su creación hasta su incorporación a main.

flowchart TD
    A[main estable] --> B[Crear branch]
    B --> C[Desarrollar funcionalidad]
    C --> D[Hacer commits]
    D --> E[Volver a main]
    E --> F[git merge rama-funcionalidad]
    F --> G[main con la mejora integrada]

Este flujo muestra que una rama no es un callejón sin salida. Es un espacio temporal de desarrollo que eventualmente se reintegra a la línea principal cuando el trabajo ya está listo.

Evolución visual del historial

También es útil ver la integración desde el punto de vista del historial.

gitGraph
    commit id: "Base"
    branch feature-contacto
    checkout feature-contacto
    commit id: "Estructura contacto"
    commit id: "Formulario y estilos"
    checkout main
    commit id: "Ajuste estable en main"
    merge feature-contacto id: "Merge contacto"

En esta representación, feature-contacto desarrolla varios commits propios y luego se fusiona con main. El historial conserva la narrativa de que esa funcionalidad nació aparte y fue integrada después, en lugar de aparecer como una mezcla indistinta desde el comienzo.

Ejemplo guiado: integrar la funcionalidad del proyecto

Supón que feature/contacto ya contiene tres commits:

  • estructura inicial de contacto.html;
  • formulario principal;
  • estilos base de css/contacto.css.

Flujo de integración:

  1. Verifica que todo el trabajo esté confirmado en la rama de funcionalidad.
  2. Cambia a main.
git switch main
  1. Ejecuta el merge.
git merge feature/contacto
  1. Revisa el estado del proyecto.
git status
  1. Abre los archivos del proyecto y confirma que la nueva funcionalidad ahora forma parte de main.

En este momento, main ya incorpora la nueva página de contacto. El laboratorio quedó integrado en la versión principal.

Error frecuente: intentar hacer merge desde la rama equivocada

Error común

Estar en feature/contacto y ejecutar git merge main pensando que eso “manda” la funcionalidad a la rama principal. En realidad, ese comando trae main hacia la rama actual, no al revés. La dirección del merge depende de la rama activa.

Error frecuente: integrar trabajo incompleto

Otro error común es hacer merge demasiado pronto, cuando la funcionalidad todavía tiene archivos temporales, textos de prueba o partes a medio terminar. La existencia de ramas no elimina la necesidad de criterio; al contrario, la hace más visible. La rama protege a main, pero no justifica integrar antes de tiempo.

Buenas prácticas

Haz merge cuando la funcionalidad cumpla su objetivo, tenga commits claros y no necesite todavía trabajo experimental básico.

Conclusión de la sección

git merge permite unir una rama de funcionalidad con la línea principal del proyecto, preservando la lógica del historial y consolidando el trabajo terminado. Entender que el merge se ejecuta sobre la rama que recibirá los cambios es clave para integrar con seguridad y sin confusiones.

6.7 Eliminando ramas

Una vez que una rama ya cumplió su propósito y sus cambios fueron integrados correctamente, mantenerla indefinidamente suele aportar poco valor. Git permite eliminar ramas locales con git branch -d o forzar su eliminación con git branch -D. Aprender cuándo y cómo hacerlo forma parte de un flujo limpio y profesional.

git branch -d

La documentación oficial indica que git branch -d elimina una rama, pero solo si esa rama ya fue fusionada completamente con su rama ascendente o con HEAD si no tiene upstream configurado. Este comportamiento es una protección útil: evita borrar por accidente una línea de trabajo que todavía contiene commits no integrados.

Ejemplo:

git branch -d feature/contacto

Este comando debe ejecutarse desde una rama diferente. Git no permite eliminar la rama actual activa, por lo que antes conviene estar en main o en otra rama que no sea la que se desea borrar.

git branch -D

La opción -D es el atajo de borrado forzado. La documentación de git branch la presenta como combinación de --delete y --force.1 En otras palabras, elimina la rama aunque no esté completamente fusionada.

Ejemplo:

git branch -D feature/prueba-visual

Este comando es útil en situaciones concretas, por ejemplo cuando una rama experimental ya no se necesita y se sabe con certeza que su trabajo puede descartarse. Sin embargo, debe usarse con mucha más precaución porque elimina la protección que normalmente ofrece -d.

Cuándo eliminar una rama

Eliminar una rama suele ser razonable cuando:

  • la funcionalidad ya fue integrada correctamente en main mediante merge;
  • el objetivo de la rama ya terminó;
  • no se necesita seguir desarrollando esa línea por separado;
  • se quiere mantener el repositorio local más ordenado.

Cuándo no conviene eliminarla todavía

No conviene borrar una rama cuando:

  • todavía no se integró a main;
  • contiene trabajo que podría retomarse pronto;
  • no se ha verificado aún que el merge produjo el resultado esperado;
  • se tienen dudas sobre si todos sus commits ya fueron incorporados.

Tabla: diferencia entre -d y -D

Comando Comportamiento Uso recomendado
git branch -d rama Borra solo si la rama ya fue fusionada. Opción habitual y segura
git branch -D rama Borra incluso si no fue fusionada. Solo cuando se quiere forzar el descarte

Buenas prácticas al eliminar ramas

  • Haz el merge primero y verifica el resultado en main.
  • Cambia a otra rama antes de borrar la rama terminada.
  • Prefiere -d como opción normal.
  • Usa -D solo cuando entiendas que estás descartando trabajo no fusionado.
  • Revisa la lista de ramas con git branch antes y después de la eliminación.

Ejemplo guiado: eliminar una rama del proyecto

Supón que feature/contacto ya fue integrada con éxito en main.

Flujo recomendado:

git switch main
git branch -d feature/contacto

Después, verifica el resultado:

git branch

Si la rama ya no aparece en la lista, su ciclo local quedó cerrado. La funcionalidad ya vive en main, por lo que la rama temporal deja de ser necesaria.

Ciclo de vida de una rama

La eliminación tiene más sentido cuando se observa la rama como un elemento temporal dentro del trabajo.

flowchart LR
    A[Crear rama] --> B[Desarrollar]
    B --> C[Hacer commits]
    C --> D[Merge en main]
    D --> E[Verificar resultado]
    E --> F[Eliminar rama]

Este ciclo muestra que una rama no está pensada para vivir para siempre. Su propósito es encapsular una tarea y desaparecer cuando esa tarea ya quedó incorporada o descartada.

Error frecuente: eliminar una rama prematuramente

Error común

Borrar una rama apenas “parece lista”, sin haber comprobado que su merge realmente quedó correcto en main. Esa prisa puede obligar a reconstruir trabajo innecesariamente.

Error frecuente: usar -D por costumbre

Otro error habitual es usar git branch -D como si fuera la forma normal de borrar ramas. Eso elimina una protección muy valiosa de Git y aumenta el riesgo de perder líneas de trabajo no integradas.

Consejo

Si git branch -d se niega a borrar una rama, no lo tomes como una molestia. Tómalo como una advertencia útil para revisar si realmente esa rama ya terminó su vida.

Conclusión de la sección

Eliminar ramas después del merge ayuda a mantener el repositorio ordenado y refuerza la idea de que una rama de funcionalidad es un espacio temporal de trabajo. Usar -d como opción normal y reservar -D para casos conscientes es una práctica simple, pero muy importante.

6.8 Flujo profesional de trabajo

El trabajo con ramas no es una colección de comandos aislados, sino un flujo coherente. Cuando ese flujo se repite con disciplina, Git deja de sentirse como una herramienta intimidante y se convierte en una estructura de trabajo confiable para el desarrollo diario.

El modelo recomendado para este capítulo es el siguiente:

main

↓

Crear Branch

↓

Desarrollar

↓

Commit

↓

Merge

↓

Eliminar Branch

Esta secuencia resume una idea profesional muy poderosa: la rama principal permanece estable, mientras cada tarea nace, crece y se integra mediante una rama temporal específica.

Etapa 1. main

Todo empieza en una base estable. main actúa como punto de partida para crear la nueva línea de trabajo y como destino final para integrar la funcionalidad cuando esté terminada.

Etapa 2. Crear Branch

Desde main, se abre una rama nueva para una tarea concreta. Puede ser una nueva página, una mejora visual, un formulario o una corrección delimitada del proyecto del libro.

Etapa 3. Desarrollar

Dentro de la rama, el desarrollador trabaja con libertad. Puede hacer pruebas, ajustes, correcciones y evolución progresiva sin comprometer todavía el estado de main.

Etapa 4. Commit

A medida que la funcionalidad avanza, se realizan commits pequeños y descriptivos. Eso convierte la rama en una historia técnica clara, no en un bloque opaco de cambios acumulados.

Etapa 5. Merge

Cuando la funcionalidad ya está lista, se vuelve a main y se integran los cambios con git merge. La rama deja de ser un experimento aislado y pasa a formar parte de la línea principal del proyecto.

Etapa 6. Eliminar Branch

Después del merge y de la verificación correspondiente, la rama puede eliminarse para cerrar su ciclo. Así el repositorio mantiene un inventario más limpio de líneas activas.

Diagrama: flujo profesional con ramas

El siguiente diagrama resume el ciclo completo de forma visual.

flowchart TD
    A[main] --> B[Crear branch]
    B --> C[Desarrollar funcionalidad]
    C --> D[Realizar commits]
    D --> E[Volver a main]
    E --> F[Merge]
    F --> G[Eliminar branch]

Este recorrido es simple, pero extremadamente poderoso. Separa la versión estable del trabajo en progreso, obliga a pensar en unidades claras de cambio y mejora la calidad del historial del proyecto.

Diagrama: comparación entre trabajo lineal y trabajo con ramas

También conviene contrastar este modelo con un desarrollo sin ramas.

flowchart LR
    A[Trabajar siempre en main] --> B[Cambios mezclados]
    B --> C[Mayor riesgo]
    C --> D[Historial menos claro]

    E[Trabajar con ramas] --> F[Tareas aisladas]
    F --> G[Commits más ordenados]
    G --> H[Integración controlada]

La diferencia principal no está solo en la técnica, sino en la calidad del proceso. Las ramas ayudan a pensar mejor el trabajo, no únicamente a ejecutarlo de otra forma.

Práctica guiada del capítulo

Para consolidar el flujo, realiza la siguiente práctica usando el mismo proyecto del libro.

  1. Sitúate en main y verifica la rama actual.
  2. Crea una rama feature/contacto para una nueva página de contacto.
  3. Desarrolla esa funcionalidad con varios commits pequeños.
  4. Regresa a main y realiza el merge.
  5. Verifica que los cambios ahora formen parte de la línea principal.
  6. Elimina la rama ya integrada con git branch -d.
  7. Repite el proceso con otra rama independiente, por ejemplo feature/footer o feature/formulario.

Con esta práctica, el lector no solo crea una rama y la fusiona una vez; aprende a repetir el ciclo completo, que es exactamente lo que ocurre en el desarrollo diario profesional.

Errores comunes dentro del flujo

Error común

Trabajar directamente sobre main “solo por esta vez”. Esa excepción suele convertirse en costumbre y termina debilitando toda la disciplina del flujo.

Error común

Crear una rama nueva, pero usarla para varias tareas no relacionadas. Una rama desordenada produce merges más confusos y un historial mucho menos útil.

Buenas prácticas

Nombra las ramas de forma descriptiva, mantén su objetivo acotado, realiza varios commits claros y ciérralas cuando su trabajo ya esté integrado.

Relación con el trabajo profesional real

En equipos y proyectos serios, este flujo es valioso porque distribuye el riesgo. La rama principal conserva estabilidad, mientras las nuevas ideas maduran en líneas separadas de desarrollo. Incluso cuando una sola persona programa, el beneficio sigue siendo enorme: permite pensar mejor, experimentar con tranquilidad y mantener el proyecto más ordenado a largo plazo.

Conclusión de la sección

El flujo profesional basado en ramas convierte a Git en una herramienta de trabajo segura, escalable y clara: partir de main, crear una rama, desarrollar, hacer commits, integrar con merge y eliminar la rama cuando ya cumplió su objetivo. Repetir este ciclo con disciplina es una de las señales más claras de madurez en el uso de Git.

Cierre del capítulo

Las ramas representan uno de los mayores aportes de Git al desarrollo moderno. Permiten construir nuevas funcionalidades sin comprometer de inmediato la versión principal del proyecto, favorecen la experimentación segura y organizan el trabajo en líneas de desarrollo comprensibles e integrables.

A lo largo de este capítulo se estudió qué es una rama, cuál es el papel de main, cómo crear y cambiar ramas, cómo desarrollar funcionalidades aisladas, cómo integrarlas con merge y cómo cerrar su ciclo eliminándolas cuando ya no son necesarias. Más importante todavía, se construyó un flujo profesional que el lector puede repetir diariamente sobre el mismo repositorio del libro.

Dominar ramas no consiste solo en aprender comandos como git branch, git switch o git merge. Consiste en adoptar una forma de trabajo más segura y más inteligente: proteger la base estable, aislar cada tarea y convertir el historial del proyecto en una secuencia clara de decisiones técnicas.

Notas al pie

Para profundizar

  1. Git. git-branch Documentation. https://git-scm.com/docs/git-branch ↩

  2. Git. git-switch Documentation. https://git-scm.com/docs/git-switch ↩

  3. Git. git-merge Documentation. https://git-scm.com/docs/git-merge ↩

  4. Git. git-commit Documentation. https://git-scm.com/docs/git-commit ↩