Fotos del proyecto, ramas que se juntan

Trabajo, preparación y repositorio

Git es un sistema de control de versiones: guarda la historia de un proyecto como una serie de commits, cada uno una foto completa de los archivos en un momento, con un mensaje que explica qué cambió, su autor y el commit anterior. Con esa historia puedes volver atrás, ver quién cambió qué y trabajar en paralelo sin pisarte con nadie.

Un archivo pasa por tres lugares:

• Directorio de trabajo: los archivos que editas normalmente.
• Área de preparación (staging o index): lo que entrará en el próximo commit. Lo llenas con git add.
• Repositorio: los commits ya guardados, dentro de la carpeta oculta .git.

La preparación existe para que decidas qué va en cada commit: si arreglaste un error y además empezaste otra cosa, puedes guardar solo el arreglo. Un buen commit hace una cosa y su mensaje dice cuál, en presente: «Corrige el total del carrito».

git init                       # convierte la carpeta en repositorio
git status                     # qué cambió y qué está preparado
git add index.html             # prepara un archivo (git add . prepara todo)
git commit -m "Agrega portada" # guarda lo preparado como un commit
git log --oneline              # la historia, un commit por línea
git diff                       # lo que cambiaste y aún no preparas
git restore --staged archivo   # lo saca de la preparación

Un puntero que avanza

Una rama no es una copia de los archivos: es solo un nombre que apunta a un commit. Cada commit nuevo hace avanzar a la rama en la que estás, y HEAD indica cuál es. Crear una rama es instantáneo y sirve para trabajar en algo sin tocar main hasta que esté listo.

git switch -c carrito      # crea la rama carrito y te pasa a ella
git switch main            # vuelve a main (los archivos cambian a como estaban ahí)
git branch                 # lista las ramas; la tuya lleva *
git merge carrito          # trae a main lo hecho en carrito
git branch -d carrito      # borra el nombre (los commits quedan en main)

Al hacer merge pueden pasar dos cosas. Si main no avanzó desde que creaste la rama, Git solo mueve el puntero hacia adelante: es un avance rápido (fast-forward). Si las dos ramas avanzaron, Git combina ambos lados y crea un commit de merge con dos padres.

Conflictos

Git combina solo los cambios que no se tocan. Si las dos ramas cambiaron la misma parte del mismo archivo de forma distinta, no puede adivinar cuál quieres: se detiene y marca el archivo así:

<<<<<<< HEAD
<h1>Tienda La Esquina</h1>        ← lo que tiene tu rama
=======
<h1>La Esquina · ofertas</h1>    ← lo que trae la otra rama
>>>>>>> ofertas

Resolverlo es editar el archivo hasta dejar la versión correcta (una de las dos, una mezcla o algo nuevo), borrar las tres marcas, y luego git add y git commit. Si te arrepientes, git merge --abort deja todo como estaba antes del merge.

Merge contra rebase

git rebase main, ejecutado desde tu rama, toma tus commits y los vuelve a aplicar uno por uno encima de la punta actual de main, como si hubieras empezado tu trabajo hoy. El resultado es una historia en línea recta, sin commit de merge; después, integrar en main es un avance rápido.

El precio: los commits rebasados son commits nuevos (otro identificador), aunque tengan el mismo mensaje. Por eso la regla es no rebasar commits que otras personas ya descargaron; rebasar tu rama local antes de compartirla es seguro. El merge, en cambio, nunca reescribe nada: conserva la historia tal como pasó, a cambio de commits de merge.

Antes de leer la respuesta