¿Qué diferencia hay entre git merge y git rebase? ¿En qué situación no deberías hacer rebase?

Ambos integran cambios de una rama en otra, pero de forma distinta:

• merge: crea un commit de merge que une las dos historias. No reescribe nada, conserva el contexto real de cuándo se integró cada rama. La contra es un historial con más bifurcaciones.
• rebase: toma tus commits y los vuelve a aplicar encima de la punta de la otra rama. El resultado es un historial lineal, pero los commits son nuevos (cambian sus hashes).

git checkout feature
git rebase main      # reaplica feature sobre main
# o bien
git checkout main
git merge feature    # crea commit de merge

Cuándo no hacer rebase: sobre commits que ya están publicados y que otras personas usan como base. Si reescribís esa historia y hacés push forzado, tus compañeros quedan con commits huérfanos y conflictos difíciles de entender. La regla práctica es: rebase para ordenar tu rama local antes de abrir el PR, merge para integrar ramas compartidas.

Si tenés que forzar el push sobre tu propia rama de feature, conviene usar git push --force-with-lease, que falla si alguien subió algo que no tenés, en lugar de pisarlo. También es útil git rebase -i para limpiar commits (squash, reword) antes de pedir revisión.

En conflictos: con merge los resolvés una vez; con rebase puede tocar resolverlos commit por commit, y siempre podés abortar con git rebase --abort.

Decir que rebase 'es mejor' sin mencionar que reescribe hashes. Recomendar git push --force sobre main o ramas compartidas. Confundir rebase con squash.