Índice del artículo
- En 30 segundos
- Explicado fácil: un borrador con historial
- Del borrador al cambio aprobado
- La inmobiliaria: quién decide qué
- No lo confundas con
- El error típico: creer que todo queda dentro de la rama
- Integrar y publicar son decisiones distintas
- Qué pedir en tu siguiente cambio
- Dudas sobre ramas, respuestas cortas
En 30 segundos
Una rama de Git es una línea de trabajo dentro de un proyecto que permite preparar cambios por separado antes de decidir si se incorporan a la rama principal.
Separar no es aislar: la rama organiza el trabajo guardado en Git; los datos reales, los permisos y la publicación necesitan su propia configuración.
Explicado fácil: un borrador con historial
Piensa en el borrador de un documento que revisas antes de incorporarlo al documento bueno. La comparación ayuda a entender la decisión: preparar una propuesta, leerla y aceptar lo que sirva. Git, el programa que guarda el historial de cambios de un proyecto, permite mantener esa propuesta como una línea de trabajo. No duplica toda la carpeta al crearla. El repositorio es el proyecto con ese historial; dentro de él pueden convivir distintas ramas.
Ejemplo ilustrativo: una inmobiliaria de Valladolid quiere cambiar el texto y el orden de las fichas de viviendas de su web. La responsable necesita ver la propuesta antes de aprobarla. Encarga a un agente, un programa de IA que realiza tareas usando herramientas, que prepare los cambios sobre textos de muestra. Los casos de este artículo no describen clientes ni resultados medidos. Lo que quiere comparar es el contenido propuesto, sin alterar los anuncios del sistema real.
Del borrador al cambio aprobado
- Preparar
- Revisar
- Integrar
- Publicar
Rechazar también es una salida: puedes dejar la propuesta sin integrar. El recorrido distingue decisiones; los automatismos del proyecto pueden enlazar pasos. Conviene conocerlos antes de empezar.
La inmobiliaria: quién decide qué
El agente entrega una propuesta. Trabaja en una rama aparte con el texto y el orden de las fichas de muestra. Deja los cambios guardados para que puedan compararse. La responsable de la inmobiliaria lee el contenido: comprueba si dice lo que quiere comunicar y si el orden le sirve. Un técnico revisa el funcionamiento. Son comprobaciones distintas: que una frase sea adecuada no demuestra que el cambio funcione bien en la web. La entrega debe permitir localizar qué se ha tocado, sin tener que deducirlo solo de una captura. Puedes pedir una revisión de diferencias, llamada diff, que muestra lo añadido y lo eliminado. Así la conversación se centra en la propuesta concreta. Si usáis GitHub, el servicio para compartir y revisar proyectos de Git, el agente puede preparar una solicitud de cambios. La responsable no tiene que memorizar órdenes para entender qué está aprobando.
No lo confundas con
Commit
Un commit es un punto guardado del historial. La rama identifica la línea de trabajo que avanza con esos puntos; no son dos nombres para lo mismo.
Worktree
Un worktree añade otra carpeta de trabajo del mismo repositorio. Puedes mantener distintas ramas abiertas a la vez sin editar la misma carpeta. Crear una rama no crea esa carpeta adicional.
Entorno de pruebas
El entorno de pruebas prepara dónde probar y con qué datos o servicios. Tener una rama no configura esa separación ni decide a qué sistema se conecta tu proyecto.
El error típico: creer que todo queda dentro de la rama
Los cambios pendientes pueden acompañarte al cambiar de rama si todavía no están guardados en un commit. Por eso puedes ver una modificación en otra rama sin haberla integrado. Antes de cambiar, pide que se compruebe el estado del trabajo y se guarde lo que corresponda. Git puede frenar el cambio si provocaría pérdida de modificaciones locales; no fuerces la operación para quitar el aviso. Crear una rama y empezar a trabajar en ella son acciones distintas. Confirma cuál está activa antes de editar. El nombre escrito en el encargo no demuestra que el agente se haya cambiado a ella.
Separar tareas no evita los conflictos. Al reunir líneas de trabajo puede haber cambios incompatibles que Git no sepa combinar. La integración se detiene y alguien debe resolverlos y comprobar el resultado. No basta con que cada persona haya usado su propia rama. Evita empezar esa integración con modificaciones relevantes sin guardar: volver atrás puede no reconstruir ese estado previo. Si hay otra tarea abierta, una carpeta de trabajo adicional permite atenderla por separado. En una tienda de recambios de Zaragoza, puedes corregir una errata mientras preparas un catálogo nuevo; después tendrás que revisar cómo encajan ambos trabajos.
Integrar y publicar son decisiones distintas
La principal es una convención del proyecto. No tiene que llevar un nombre concreto ni coincidir con la web publicada. Integrar reúne cambios del historial en la rama de destino. Publicar depende de cómo esté preparado el proyecto. En GitHub, subir cambios puede activar automatizaciones incluso desde otra rama; también pueden configurarse filtros para decidir cuáles las activan. Pregunta al técnico qué ocurre al subir la propuesta y qué ocurre al integrarla. La respuesta debe referirse a ese proyecto, porque el nombre de la rama no permite deducirlo.
La revisión necesita reglas y permisos. Git local no exige por sí solo que el dueño apruebe un cambio. En GitHub, una solicitud de cambios presenta la propuesta para revisarla antes de incorporarla. Las protecciones de ramas pueden exigir revisiones y comprobaciones cuando el plan y el repositorio lo permiten. Hay que configurar también las excepciones para administradores y otros roles autorizados. No publiques el código de tu empresa para conseguir una función de protección. Acuerda con quien mantiene el proyecto quién puede integrar y quién puede saltarse una regla.
Qué pedir en tu siguiente cambio
Pide una entrega que puedas revisar: «Prepara el cambio en una rama aparte y enséñame qué has modificado. No lo integres ni publiques todavía. Usa datos de muestra y no cambies los servicios reales». Adapta el encargo a una tarea concreta, como el texto de las fichas de la inmobiliaria.
Revisa qué se ha añadido y eliminado con ayuda de la explicación de cómo leer un diff. Acuerda dónde se hará la prueba y con qué datos; la explicación de qué es un entorno de pruebas te ayuda a distinguir esa preparación de la rama. Para practicar el trabajo sobre proyectos con un agente, sigue con Claude Code a fondo.
Dudas sobre ramas, respuestas cortas
¿Una rama es una copia del proyecto?
La analogía del borrador sirve, pero Git no duplica toda la carpeta al crear una rama. Es una referencia que avanza con los commits de esa línea de trabajo. Si necesitas otra carpeta para mantener dos tareas abiertas, eso lo aporta un worktree.
¿Necesito GitHub para crear una rama?
Git puede usarse en tu ordenador sin contratar GitHub. Sus ramas forman parte del programa. GitHub añade alojamiento y colaboración, como las solicitudes para revisar cambios. Elegir ese servicio es una decisión distinta de crear una línea de trabajo local para preparar una propuesta.
¿Borrar la rama deshace lo que he aprobado?
Borrar no deshace lo integrado. Después de incorporar la propuesta, eliminar esa rama no elimina los cambios que ya entraron en el historial. Tampoco revierte correos, cobros o modificaciones en servicios externos. Si el cambio ya se publicó, necesitas revisar cómo corregirlo; borrar su rama no restaura la web anterior.
¿Borrar una rama en GitHub la borra también de mi ordenador?
No. La rama local y las referencias remotas se gestionan por separado. Borrar una rama en GitHub no equivale a limpiar todas las referencias de tu ordenador. Pide al técnico que compruebe cuáles quedan y qué debe retirar; no des por hecho que el borrado en el servidor lo resuelve todo.
Fuentes
Fuentes oficiales, consultadas el 4 de noviembre de 2026
- Git · Qué es una rama
- Git · Crear y borrar ramas
- Git · Cambiar de rama y modificaciones pendientes
- Git · Integración y conflictos
- Git · Carpetas de trabajo adicionales
- Git · Programa de control de versiones
- GitHub · Proponer, revisar e integrar
- GitHub · Protección de ramas y excepciones
- GitHub · Automatizaciones al subir cambios
Cómo lo comprobamos. Fuentes oficiales consultadas el 4 de noviembre de 2026. Ciade no ha realizado una nueva demostración de ramas o publicación ni ha probado protecciones, publicación automática, conflictos o separación de bases de datos.
Qué ha cambiado.
- 4 de noviembre de 2026: Reescritura v2: separación de cambios, revisión, límites de la rama y guion de grabación actualizado.
Términos relacionados
Aprende a usar la IA en tu trabajo, con criterio.
El nivel 0 es gratis: cuarenta minutos para entender qué pedirle a la IA y qué revisar. El programa completo enseña a implementarla en tu propio negocio, tarea a tarea.
