Compara rebase y merge en un grafo de commits en vivo, planifica un rebase interactivo con pick, squash, fixup y drop, y aprende a abortar o deshacer con el reflog.
git rebase vuelve a aplicar los commits de tu rama encima de otro commit, lo que deja un historial lineal en lugar de un commit de merge. Ejecuta git rebase main desde tu rama de funcionalidad, resuelve los conflictos y luego git rebase --continue. Usa git rebase -i para combinar, reescribir o eliminar commits, y git rebase --abort para echarte atrás.
Los comandos de rebase que más vas a escribir
Rebase es el comando de git que más miedo da, sobre todo porque reescribe commits. El grafo de abajo muestra exactamente qué cambia al hacer merge o rebase, el planificador te permite probar un rebase interactivo con commits de ejemplo, y las últimas secciones tratan los conflictos, la única regla que protege a tus compañeros y cómo recuperar una rama cuando un rebase sale mal.
Merge conserva el historial real y añade un commit de merge, que es lo más seguro para ramas compartidas. Rebase da una línea recta más fácil de leer y de recorrer con bisect, ideal para tu propia rama de funcionalidad antes de la revisión. Muchos equipos hacen rebase en privado y merge en público.
Si todavía está en curso, git rebase --abort lo deja todo como estaba. Si ya terminó, ejecuta git reflog, busca la entrada justo anterior al inicio del rebase y haz git reset --hard a ese hash. ORIG_HEAD también apunta a la punta anterior justo después de un rebase, salvo que otro comando la haya cambiado.
No hagas rebase de commits sobre los que otras personas ya han basado su trabajo. El rebase crea commits nuevos con hashes nuevos, así que quien tenga los antiguos acaba con historial duplicado y conflictos confusos.
Los dos integran un commit en el de arriba. squash abre el editor para que combines ambos mensajes; fixup descarta el mensaje del commit integrado y conserva el anterior. fixup -C conserva en cambio el mensaje del commit integrado.
Cada commit se vuelve a aplicar sobre la nueva base, y un commit que tocó las mismas líneas que la base no se puede aplicar automáticamente. Edita el archivo, haz git add y ejecuta git rebase --continue. Puede que te encuentres un conflicto por cada commit reaplicado.
git rebase -i abre una lista de tareas con una línea por commit, el más antiguo arriba. Cambia la palabra al inicio de una línea, guarda y cierra el editor, y git ejecuta la lista de arriba abajo.
Comandos de la lista de tareas en git rebase -i
Haz fetch primero para que main esté al día, haz rebase, resuelve los conflictos y sube la rama reescrita de forma segura.
Busca la línea justo anterior al inicio del rebase y restablece la rama a ese punto.
--onto recibe tres puntos: la nueva base, la base antigua y la rama. Solo se mueven los commits posteriores a la base antigua.
feature-b se creó a partir de feature-a. Esto coloca solo los commits propios de feature-b encima de main.
Merge o rebase: qué le pasa al historial
Elige cómo combinar las ramas
Merge
Rebase
commit de merge
Merge deja F1 y F2 intactos y añade un commit nuevo con dos padres.
Rebase copia F1 y F2 sobre M3. Las copias (marcadas con ') tienen hashes nuevos; los originales quedan atrás.
Planificador de rebase interactivo
Elige una acción para cada commit, del más antiguo al más reciente, y mira la lista de tareas y el resultado.
Acción para el commit {n}
Lista de tareas que abre git
Historial después del rebase
La primera línea no puede ser squash ni fixup: no hay ningún commit encima en el que integrarla.
Se eliminaron todos los commits. La rama apuntaría a su base.
incluye {n} commit(s) integrado(s)
mensaje editado
Empieza gratis · Sin tarjeta de crédito