Ordenar el historial con rebase (y la regla de oro)
Este es el tema más confuso del curso, así que vamos a ir despacio. En la lección anterior vimos merge: una forma de combinar el trabajo de una rama, que deja un commit de merge y conserva las dos líneas tal como ocurrieron. Ahora conocemos una segunda forma, git rebase: 'reproduce' los commits de t
rebase es como tomar las páginas que escribiste y volver a copiarlas al final del cuaderno actualizado del equipo, como si las hubieras escrito ahí desde el principio. El resultado se ve prolijo y recto, pero son páginas nuevas. Por eso no vuelves a copiar páginas que ya le entregaste a otras personas: ellas todavía tienen las páginas viejas, y eso genera confusión.
- git rebase
- Reproduce los commits de la rama actual para que empiecen desde la punta de otra rama, creando un historial lineal. Los commits originales se reemplazan por commits nuevos con hashes nuevos.
- Historial lineal
- Un historial que es una sola línea recta de commits, sin bifurcaciones ni commit de merge: cada commit está justo encima del anterior.
- Regla de oro
- Nunca hagas rebase de commits que ya enviaste (push) o compartiste con otras personas. rebase reescribe los hashes, así que solo es seguro en trabajo local y privado.
- Hash del commit
- El identificador único de cada commit (una huella digital). Si algo del commit cambia, incluido su parent, recibe un hash nuevo, y así se convierte en un commit distinto.
- Reproducir (replay)
- La acción en la que rebase toma cada uno de tus commits y los vuelve a aplicar, uno por uno, encima de la punta de la otra rama; así es como se crean los commits nuevos.
