Git para Novatos – Capítulo 8: Merge

Capítulo 8: Merge — Fusión de ramas, o cómo unificar tu trabajo

Tenés una rama `feature/licencia` con cambios que ya probaste y funcionan. Ahora querés traer eso a `main`. El proceso se llama **merge** (fusión).

Paso 1: Parate en la rama que va a recibir los cambios

Siempre te parás en la rama de destino antes de hacer el merge. En este caso, `main` recibe los cambios de `feature/licencia`:

git checkout main

Paso 2: Ejecutá el merge

git merge feature/licencia

Git responde algo como:

Updating a1b2c3d..a2b3c4d
Fast-forward
 LICENSE | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 LICENSE

Acá pasó un **fast-forward**. Como `main` no tuvo cambios nuevos desde que creaste la rama, Git simplemente avanzó la punta de `main` hasta donde está `feature/licencia`. Es el merge más limpio que existe.

Verificá:

git log --oneline

a2b3c4d (HEAD -> main, feature/licencia) Agrego licencia MIT al proyecto
a1b2c3d Primer commit: README inicial

`main` y `feature/licencia` apuntan al mismo commit.

Paso 3: Borrá la rama (opcional pero recomendado)

Una vez que el merge está hecho, la rama ya cumplió su función. La podés borrar:

git branch -d feature/licencia

Deleted branch feature/licencia (was a2b3c4d).

No perdés nada. Los commits siguen estando en `main`.

¿Y si main avanzó mientras tanto?

Ahí es donde se pone interesante. Suponé que vos trabajaste en `feature/login` y otro compañero (o vos mismo desde otra máquina) avanzó `main` con otros cambios. Cuando hacés el merge, Git no puede hacer fast-forward porque hay dos historias que divergieron.

En ese caso Git hace un **merge commit**. Crea un commit especial que tiene dos padres:

git checkout main
git merge feature/login

Git te abre el editor para que escribas el mensaje del merge commit. Por defecto algo como:

Merge branch 'feature/login'

Lo guardás y Git hace algo como esto:

Merge made by the 'ort' strategy.
  login.php | 10 ++++++++++
  1 file changed, 10 insertions(+)

Y el historial se ve así:

git log --oneline --graph

*   3c4d5e6 (HEAD -> main) Merge branch 'feature/login'
|| * b2c3d4e (feature/login) Agrego validacion de login
| * a2b3c4d Agrego formulario de login
* | 1a2b3c4 Corrijo typo en README
|/
* a1b2c3d Primer commit: README inicial

Ese gráfico muestra dos líneas que divergieron y se volvieron a juntar. Es hermoso y asusta a los novatos, pero es solo eso: dos caminos que se unieron.

Conflictos: cuando Git no puede solo

Si dos personas modificaron la misma línea del mismo archivo, Git no sabe cuál dejar. Te muestra:

Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

No entres en pánico. Abrí el archivo conflictivo y vas a ver algo como:

<<<<<<< HEAD
Este es mi proyecto con Git
=======
Este proyecto usa Git para control de versiones
>>>>>>> feature/login

Entre `<<<<<<< HEAD` y `=======` está lo que tiene `main`. Entre `=======` y `>>>>>>> feature/login` está lo que trae la rama. Decidí cuál dejar (o mezclalos manualmente), borrá los marcadores, guardá el archivo, y después:

git add README.md
git commit -m "Resuelvo conflicto en README.md"

Listo. El merge está completo.

Resumen del capítulo:

`git checkout main && git merge rama` — fusionás la rama en main

Fast-forward: cuando main no avanzó, Git solo adelanta la punta

Merge commit: cuando main y la rama divergieron

Conflictos: editás a mano, git add, git commit

En el próximo capítulo: clonar un repositorio desde el servidor en otra máquina.