Ahora que hemos estado trabajando de manera más activa con ramas y con Pull Requests para poder procesar la información, lo ideal es que puedas integrar tus cambios y tus ramas de manera normal, sin embargo, cuando las cosas suceden de manera diferente. Puede suceder que un conflicto aparezca y cuando eso sucede por primera vez en un repositorio puede suceder que git te permita seleccionar la estrategia adecuada, una estrategia que quizá puede ser confusa si no estamos listos para ello.
En la imagen puedes ver que git está ofreciéndote tres opciones para poder hacer la fusión entre las ramas, estas tres opciones son:
git config pull.rebase false: Esta estrategia es la que git utilizará por defecto, la que git sugiere siempre, se encargará de fusionar la rama local y la remota, lo ideal es usarla para mantener el historial de cambios y francamente la más sencilla.
git config pull.rebase true: Esta opción hará que Git intente hacer un rebase que es exactamente como suena, la rama remota va a rebasar a las locales sobreescribiendo sus cambios haciendo que si la rama local quiere subir sus cambios entonces deberá hacerlos de nuevo, con una buena constancia de cambios esta estrategia es la más práctica.
git config pull.ff only: Esta opción se refiere a un fast-forward, esto ocurre cuando la rama local está por detrás en los cambios de la rama remota y los commits de esta última rama pueden aplicarse sin crear un commit de fusión. Demasiado complicado ¿no? En otras palabras, se trata de poner los cambios de la rama local por encima de los de la remota, lo que no es la mejor idea porque podría afectar los cambios de otros miembros del equipo.
Como puedes ver, cada estrategia es diferente y se adapta perfectamente a diferentes escenarios. ¿Quieres un tip final? Si tu equipo no tiene una política acerca de esto, lo ideal es que consideren usar la mecánica por defecto para así adaptarse a lo que ya sabrán que va a suceder en todos los casos.
Al fin entendí qué hacer cuando me sale ese aviso.
Jajajaja no sabes los dolores de cabeza que me dió cuando lo aprendí.
Me gustaría compartirle dos imágenes que me ayudaron a entender las dos opciones extras que no son las regulares.
La primera es relacionado al rebase true:
Esta es relacionado al pull.ff only:
Siempre dejaba la por defecto, aunque no entendiera el rebase, pero si funciona... seguia la regla del "no lo toques" jajaja
Git Rebase: Qué es y Cómo Usarlo 🚀
📌 ¿Qué esgit rebase?
git rebase es un comando en Git que se usa para reaplicar cambios de una rama sobre otra, reescribiendo el historial de commits. Se usa principalmente para mantener un historial limpio y evitar merges innecesarios.
🔄 Diferencia entregit mergeygit rebase
Característicagit mergegit rebaseFusión de ramasSí (genera un commit de merge)Sí (reaplica commits)Historial limpioNo (mantiene bifurcaciones)Sí (reescribe el historial)ConflictosPuede haber conflictos en el mergePuede haber conflictos al reaplicar commitsUso recomendadoCuando se necesita un historial detalladoCuando se quiere un historial lineal
📌 Ejemplo Visual:
Antes de merge
A---B---C (main)
\
D---E (feature)
Después de git merge feature en main
A---B---C---M (main)
\ /
D---E (feature)
Después de git rebase main en feature
A---B---C---D'---E' (feature)
🛠️ ¿Cómo usargit rebase?
1️⃣ Rebase interactivo (git rebase -i)
Se usa para modificar, reordenar o combinar commits.
git rebase -i HEAD~3 # Modificar los últimos 3 commits
Opciones en el editor:
pick → Mantener el commit
reword → Editar el mensaje del commit
edit → Modificar el commit
squash → Combinar commits
drop → Eliminar un commit
2️⃣ Rebase sobre otra rama
git checkout feature
git rebase main # Aplica los commits de feature sobre main
3️⃣ Resolver conflictos en rebase
Si hay conflictos, Git pausa el proceso. Debes solucionarlos manualmente:
git add .
git rebase --continue
Si deseas cancelar el rebase:
git rebase --abort
🚀 Cuándo Usargit rebase
✅ Para mantener un historial de commits limpio y lineal.
✅ Antes de fusionar una rama feature en main o develop.
✅ Para actualizar una rama sin crear commits de merge innecesarios.
⚠️ ¡Precaución! No hagas git rebase en ramas compartidas con otros desarrolladores, ya que reescribe el historial.
💡 "Usagit rebasepara un historial limpio, pero con cuidado en ramas compartidas." 🚀
Muchas gracias por tu aporte :)
Que buena lectura, Gracias Profesor, Gracias Platzi.
Estrategias de Fusión:
Merge: une las dos ramas y preserva el historial de ambas ramas
Squash Merge: Combina todos los commits de una rama en uno solo y lo trae a main.
Rebase: mueve los commits de la rama feature adelante de main, reescribe la historia. Solo se recomienda en ramas que utilizó de forma independiente.
Se cayo la imagen :(
Pregunte a Claude:
Hay errores importantes en las últimas dos:
pull.rebase false ✅ Correcto (con matiz) Git no "siempre lo sugiere" — de hecho, en versiones recientes Git te advierte que configures explícitamente una de las tres opciones. Lo demás es correcto.
pull.rebase true ❌ Descripción invertida El rebase no sobreescribe los cambios locales. Lo que hace es tomar tus commits locales y reaplícarlos encima de los commits remotos. Es decir: la historia queda lineal, como si hubieras empezado a trabajar desde el último commit remoto. Tus cambios locales no se pierden, se "mueven" al final de la línea.
pull.ff only ❌ Explicación incorrecta Fast-forward ocurre cuando no hay commits locales divergentes — Git simplemente avanza el puntero de tu rama local al mismo commit de la remota, sin crear commit de fusión. Con ff only, si hay divergencia (tienes commits locales que el remoto no tiene), Git falla en lugar de mergear o rebasear. No tiene que ver con "poner cambios locales por encima de los remotos".
Resumen correcto:
OpciónResultado
rebase false
Merge commit (historial con bifurcaciones)
rebase true
Tus commits locales se reaplican sobre los remotos (historial lineal)
ff only
Solo avanza si no hay divergencia; falla si hay commits locales nuevos
Las estrategias de fusión de ramas en Git permiten integrar cambios de diferentes ramas de forma organizada, facilitando el trabajo colaborativo y el control adecuado de versiones en los proyectos. ✨👍
Dame ejemplos reales para cada estrategia
Imagina que trabajas en un proyecto grupal. La estrategia por defecto (false) es como anotar cada edición en un diario: conservas el rastro exacto de quién hizo qué y cuándo. Es ideal para auditorías o equipos grandes donde la trazabilidad es ley.
¿En qué tipo de proyecto o equipo crees que sería más valioso mantener ese historial detallado en lugar de una línea de tiempo limpia?
Dame ejemplos reales para la estrategia git config pull.rebase true y git config pull.ff only
pull.rebase true es tu mejor aliado cuando trabajas solo en una rama de funcionalidades: mantiene tu historial lineal, como si nunca hubieras tenido que actualizarte con el remoto. Es limpieza pura.
pull.ff only es el freno de mano de seguridad: te obliga a actualizar tu rama antes de subir nada, evitando commits de fusión innecesarios. ¿Cuándo preferirías que Git te bloquee un pull en lugar de intentar resolverlo automáticamente?
¿Cómo evito arruinar el trabajo de mi equipo?
Para mantener la paz en tu equipo, la regla de oro es nunca forzar la sobreescritura del historial público. Estrategias mal aplicadas, como forzar un avance rápido poniendo tus cambios locales por encima de los remotos de forma agresiva, pueden borrar literalmente el código que tus compañeros acaban de subir. La mejor manera de evitar desastres es comunicarte y establecer un estándar. Si no hay un acuerdo previo, apégate siempre a la fusión tradicional (pull.rebase false). Esta opción respeta el trabajo de todos al crear un registro claro de cómo se combinaron las diferentes aportaciones. Además, acostúmbrate a hacer git fetch antes de integrar nada; esto te permite observar el panorama del servidor remoto de forma segura antes de tomar una decisión que afecte el repositorio central.
Clase 39
Me pareció muy clara la explicación de las tres estrategias de fusión y cuándo tiene sentido usar cada una para manejar conflictos entre ramas. Algo que me llevo a la práctica es la importancia de definir una política de equipo (aunque sea usar la opción por defecto al inicio) para evitar sorpresas en el historial y mantener un flujo de trabajo más predecible
Si me quedo todo claro:
git config pull.rebase true hará que la rama remota sobreescriba a main convirtiendo la version definitiva (main) tal y como es la rama remota con la que se quiere fusionar, dejando atras cualquier cosa que pudo tener main en el pasado diferente.
git config pull.ff only hará que si nuestra rama local (la que hemos estado trabajando) este atrasada en comparacion a la remota (o main para mi percepción) se haga un pull fast, o un pull rapido, es decir que si no hay conflictos fast-forward se realizará y nuestra rama local quedará actualizada, si provoca conflictos y no se puede realizar este fast-forward por supuesto fusionaremos las ramas pero despues de haber solucionado los conflictos manualmente
¿Esto es asi, verdad?
La transcripción indica que git config pull.rebase true hace que la rama local se actualice con cambios de la rama remota, requiriendo que los cambios locales sean re-aplicados. Y git config pull.ff only no fusiona, solo actualiza la rama local si está atrasada y sin conflictos, sin crear commit de fusión.
Si, es correcto (lo tuve que leer como tres veces para imaginar el escenario! Jajajaja)
