Git Rebase: reorganizando el trabajo realizado

rebase reescribe la historia del repositorio, cambia la historia de donde comenzó la rama y solo debe ser usado de manera local.

Rebase
Es el proceso de mover o combinar una secuencia de confirmaciones en una nueva confirmación base. La reorganización es muy útil y se visualiza fácilmente en el contexto de un flujo de trabajo de ramas de funciones. El proceso general se puede visualizar de la siguiente manera.

Para hacer un rebase en la rama feature de la rama master, correrías los siguientes comandos:

git checkout feature
git rebase master

Esto trasplanta la rama feature desde su locación actual hacia la punta de la rama master:

Ahora, falta fusionar la rama feature con la rama master

git checkout master
git rebase feature

# No reorganices el historial público

Nunca debes reorganizar las confirmaciones una vez que se hayan enviado a un repositorio público. La reorganización sustituiría las confirmaciones antiguas por las nuevas y parecería que esa parte del historial de tu proyecto se hubiera desvanecido de repente.

¿Sabían que el comando:
git checkout -
cambia del actual branch al anterior branch en el que hubieran estado?

Comparto algunos apuntes adicionales

Además comparto una comparación entre Git Merge y Git Rebase:

Cuando usas Rebase

Cuando se usa git rebase

La verdad en esta clase me perdi :c
Lo que me alivia es que esto no se debe hacer y pues no pierdo nada jaja

Rebase sirve también para cambiar la historia de nuestros commits en la misma rama, si tienen muchos commits con cambios pequeños estos se pueden unificar para hacer que su log se vea mas limpio.
Les recomiendo buscar git rebase interactive

**Evitar hacer rebase en el repositorio remoto a menos que tengan claro que están haciendo.

Tenía entendido que hacer rebase es “buena práctica” si no lo hacemos en la rama master (o cual sea nuestra rama principal), si no, al contrario.

**Por ejemplo: **

• Tenemos la rama “master” y nuestra rama “hotfix”
• Tenemos un montón de tiempo trabajando en nuestro _hotfix _y queremos mantenerlo actualizado con lo que está en “master”
• Guardamos nuestros cambios actuales en “hotfix” (git commit -am…)
• git checkout master + git pull origin master (nos movemos y actualizamos a nuestra rama master)
• git checkout hotfix
• git rebase master (esto nos traerá los cambios -commits- que están en master que no tenemos en nuestro hotfix, integrará dichos commits en la historia de nuestro hotfix, como si siempre hubiesemos trabajado en una rama actualizada)
• Puede que hayan conflictos durante el rebase (al igual que cuando hacemos un merge), los solucionamos.

Que opinan al respecto?

Un pequeño truco antes de continuar, para ver las ramas así, si su alias no se guarda, cómo es mi caso, recuerden la palabra A DOG
$ git log –all –decorate –oneline –graph

# avancemos en master. Insertar "master 1" en historia.txt
$ git commit -am "Master 1"

# crear rama experimento
$ git branch experimento
$ git checkout experimento

# insertar "exp 1" en historia.txt
$ git commit -am "exp 1"
# insertar "exp 2" en historia.txt
$ git commit -am "exp 2"

# hecho lo anterior, vuelvo a master y sigo avanzando
$ git checkout master
$ git commit -am "Master 2"

# la base de la rama experimento esta un commit atras de master.
# hago primero rebase en experimento para que parezca que nacio en el ultimo commit de master y no en el penultimo
$ git checkout experimento
$ git rebase master

# ahora si la rama experimento parece haber nacido en el ultimo commit de master.
# puedo hacer rebase ahora pero a master, para integrar los cambios hechos en la rama experimento
$ git checkout master
$ git rebase experimento

# con lo anterior todos los cambios quedan como si se hubieran hecho linealmente en master.
# aparece primero el commit de master que le hacia falta a experimento
# aparecen luego los dos commits que habia hecho en experimento
# con lo anterior ya me sobra la rama experimento, asi que la borro
$ git branch -D experimento
$ git branch
$ git pull origin master
$ git push oorigin master

Un caso de uso que se me ocurre para rebase es cuando creo una branch, trabajo en ella… y por cuestiones de la vida no me doy cuenta que creé la branch con faltas de ortografía jajaja.

Entonces creo otra branch con el nombre correcto, luego los rebase y listo. Nadie se da cuenta en la historia del repositorio que cree una branch con faltas de ortografía jajajaja

Aquí difiero completamente, aunque estoy de acuerdo en:

• Es una mala practica, siempre y cuando se haga rebase de una rama compartida, que mas de 1 developer lo trabaje.
• Es costosa, ya que el developer tiene que resolver conflictos en X commits y depende de los conflictos es tedioso. En caso de merge sin rebase, el conflicto se resuelve una vez.
• Agrega un step extra al proceso.

Ahora doy mis razones de por que me gusta el rebase:

• Primero admito que fue el primer proceso que use en el trabajo, y es un poco sentimental.
• Crea una claridad tremenda de los features. Si trabajamos con feature branching, cada rama mergueada luego de un rebase crea un trazo claro. Ejemplo, el proyecto que dejo como imagen final.
• Se da responsabilidad al developer de actualizar siempre su rama al ultimo cambio, se corre test de integracion (al menos sanity tests).

Aquí mi ejemplo, como ven se ve claramente las ramas y que cambios tiene cada bloque, cosa que en un grafo donde solo se hace mergue es confuso. Los commits de merge, muestran el total de archivos modificados y sus cambios.

Link: https://ibb.co/z8p44Gs

Es decisión de cada equipo, y al menos en el que yo trabajo, pues es una practica muy util que nos ayuda mucho en el proces.

Las buenas prácticas nos indican que solamente hay que hacerlo en nuestro repositorio local
</br>
La documentación oficial es muy clara
</br>
Nunca reorganices confirmaciones de cambio (commits) que hayas enviado (push) a un repositorio público.
Siguiendo esta recomendación, no tendrás problemas. Pero si no la sigues, la gente te odiará y serás despreciado por tus familiares y amigos.

Como esto es una mala practica me quedo con el merge.

En git existen dos formas que nos permiten unir ramas, git merge y git rebase. La forma mas conocida es git merge, la cual realiza una fusión a tres bandas entre las dos últimas instantáneas de cada rama y el ancestro común a ambas, creando un nuevo commit con los cambios mezclados.

Git rebase básicamente lo que hace es recopilar uno a uno los cambios confirmados en una rama, y reaplicarlos sobre otra. Utilizar rebase nos puede ayudar a evitar conflictos siempre que se aplique sobre commits que están en local y no han sido subidos a ningún repositorio remoto. Si no tienen cuidado con esto último y algún compañero utiliza cambios afectados, seguro que tendrá problemas ya que este tipo de conflictos normalmente son difíciles de reparar.
.
Punto de partida
.

.
Ejempo de mezcla de ramas con git merge

.

git checkout master
git merge prueba

.

.
Ejempo de mezcla de ramas con git rebase
.
git checkout master
git rebase prueba

.

.
Utilizando git rebase conseguimos un log de commit mas sencillo y como veis es muy fácil utilizarlo, pero como he comentado antes, cuidado con usarlo con commits que están en servidores remotos.

¿Qué hay del caso en el que trabajamos en una rama basada en dev o master? Mantener actualizada dicha rama en local con git pull --rebase es algo que ayuda un montón porque evita conflictos a la hora de hacer un PR/MR y no vuelve de la secuencia de commits a mezclar un espagueti. Satanizar el rebase está mal. #Shame

Para mayor información visiten: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

REBASE

Rebase y merge se diferencian en que merge mezcla dos puntos finales de dos snapshots y rebase aplica cada uno de los cambios a la rama en la que se hace el rebase. No lo uses en repos publicos con mas colaboradores, porque todos los demas tendrán que hacer re-merges

git checkout <una rama>
git rebase master # aplica todos los cambios de <una rama> a master
git merge master # hay que hacer un merge de tipo fast forward
Tenemos 3 ramas, master, client y server, en server y client tenemos varios commit y queremos mezclar client en master pero dejar server intacta:
    git rebase --onto master server client # adivina los patches del antecesor común de las ramas server y client y aplica los cambios a master.
    git checkout master
    git merge client # fast-forward. Client y master en el mismo snapshot

Si se quiere aplicar también los cambios de server, basta con:
    git rebase master server
    git checkout master
    git merge server

git rebase [basebranch] [topicbranch] # sintaxis de rebase

git rebase -i # Rebase interactivo

Fuente: El baul del programador

Primero se le hace el REBASe a la rama que desaparecera.
Despues se le hace REBASE a la rama principal.

Ese es el orden.

A mi me paso que hubo un conflicto a pesar que lo hice parecido al ejemplo pero en el mensaje que te sale acontinuación, te explica que tienes que hacer pero por si acaso les pase, aquí los pasos a seguir:

1. Primero editar en tu editor de codigo, el error que te salga.
2. Luego guarda CTRL + S.
3. Regresa a GIT y escribe git add historia.txt + ENTER.
4. seguido de esto, git rebase --continue.

Con esto ya estas listo, de ahi si puedes abrir arbolito para ver lo editado 🔥🔥🔥 Espero les ayude mijines 🔥🔥🔥

Un rebase es hacer cambios silenciosos en una rama y esa rama pegarla en la rama principal como si no hubiera existido la rama de los cambios. Se le hace rebase primero a la rama que cambia y luego a la rama final.

Por error mis cambios entre experimento y master generaron conflictos que implicaron aceptar cambios, guardar y hacer un nuevo commit, y el rebase quedó en suspensión mientras solucionaba estos problemas, para lo cual al final tuve que hacer un

git rebase --continue

y todo funcionó bien.

Git Rebase descripcion grafica
![](

git merge: fusión.
git rebase: Reorganización.

Rebase es algo así como para cuando hiciste alguna travesura y después te invadieron los sentimientos de culpa y a borrar toda pista.

no se vosotros pero yo esto me lo tengo que dejar bien apuntado por que lo voy a usar tan poco que se me olvida fijo xd.

No se recomienda hacer Rebase ,porque se pierde la historia de los cambios, y en general son malas practicas, si aún así se requiere realizar esto, se debe hacer rebase a la rama que tiene los cambios, y posteriormente a master ❤️ .

*Borrar branch
git branch -D 'Nombre de la rama"

Encontre este video. Espero que les sirva
https://www.youtube.com/watch?v=CEtqad1jM2E

Holaaa, comparto la forma gráfica de lo que se hizo en clases:

Si quieren poner pause aquí está el vídeo:
https://i.imgur.com/9JWaz4c.mp4

La herramienta es esta:
https://learngitbranching.js.org/?NODEMO=&locale=es_ES
La encontré en comentarios más abajo 😁

Esta clase me gustó mucho porque todo salió a la perfección 🤩
Git Rebase: reorganizando el trabajo realizado

$ pwd //Nos muestra la ruta donde nos encontramos.
$ git commit -am "Master 1" //Hacemos el Commit
$ git branch experimento //Creamos una nueva rama 
$ git checkout experimento //Nos pasamos a esa rama
$ git commit -am "Exp 1" //Hacemos el commit
$ arbolito //Para ver todo los Hash
$ git commit -am "Exp 2" //Otro commit
$ git checkout main //Retornamos a la rama principal
$ git checkout experimento //Cambiamos a la rama que queremos traer los cambios
$ git rebase main //Aplicamos rebase para traer los cambios de la rama que queremos
$ git checkout main //Regresamos a la rama principal   para agregar otro commit
$ git commit -am "Master 2" //Hacemos commit para      guardar
$ git checkout experimento //Volvemos a la rama experimento
$ git rebase main // Para juntar todo los cambios de la rama experimento
$ arbolito //Ver todo los Hash
$ git rebase experimento //Se copio todo los cambios en la rama principal Main
$ git pull origin main //Traemos la ultima version del GitHub 
$ git push origin main //Para enviar todo los cambios a GitHub
$ git branch -D experimento //Verificamos que la rama  experimento se borro no existe
$ arbolito //No paso nada 

Como vetaja se pude decir que genera un historial de proyecto perfectamente lineal: se puede ir desde el extremo de la rama feature hasta el inicio del proyecto sin encontrar ninguna bifurcación. Así es más fácil navegar por el proyecto con comandos como git log, git bisect y gitk.

Sin embargo, este historial de confirmaciones tiene dos desventajas: la seguridad y la trazabilidad. Si no sigues la regla de oro de la reorganización, reescribir el historial del proyecto puede tener consecuencias catastróficas para el flujo de trabajo de colaboración. Y, aunque menos importante, también se pierde el contexto que proporciona la confirmación de fusión: no se puede ver cuándo se han incorporado los cambios de nivel superior a la función.

Realmente no tiene tanta utilidad el rebase. Incluso es muy buena practica tener el historial de las ramas features/bugfix para ver en el tiempo que fue lo que se hizo allí. Se puede también borrar las ramas con branch -D. Incluso si usan Gitlab (que me gusta 1000 veces más que Github), da la posibilidad de gestionar las ramas de una manera más comoda y de eliminar la rama del feature o bugfix después de hacer merge y de esa manera te queda el repositorio bastante limpio y bonito. Esto lo digo por mi experiencia laboral.

No se si a alguien le sirva, pero yo me hice una bola porque me surgieron conflictos en medio del rebase. Lo que hice fue seguir las instrucciones que aparecían en la consola: solucionar los conflictos manualmente, usar el comando

git add <nombre del archivo>

para agregar los conflictos solucionados y luego dar el comando

git rebase --continue

para terminar de hacer el rebase

Resumen de Rebase:

• Es una forma de hacer cambios silenciosos
• Es mala práctica, porque cambia la historia de dónde arrancó el branch
• En caso de ejecutarlo, solo debería hacerse en repositorios locales
• Se ejecuta primero desde la rama que se va a desaparecer (la que cambia ) y luego en la rama final

En resumen practica con rebase PERO NUNCA LO HAGAS EN TU VIDA PROFESIONAL ES MUY MALA PRÁCTICA

📌 Rebase permite integrar cambios de una rama a otra, no es recomendable usarlo.

con eso del rebase se me vino a la mente la serie de Netflix Dark, es como si viajaras en el tiempo para arreglar un error que ocurrió en el presente.

Apuntes 🙂

Que enredo es si no haces el procedimiento bien, para salir tienes que utilizar:
git rebase --abort
git rebase --skip
git rebase --continue
Por si a alguien le paso lo mismo.

Me puse a trastear con el comando rebase y me di cuenta que cuando utilizamos el comando gitk en background, es decir colocándole un & al final (sin espacio), es posible notar como se va dibujando los commits gráficamente a medida que vamos trabajando en el proyecto. Es muy útil para tener siempre presente en donde estamos parado con respecto a los commits y las ramas

Para los que les genera conflicto(REBASE 1/2) como a mí sólo les digo que utilicen el archivo de Freddy <historia.txt> y no tendrán problemas. Yo estuve dos días sin saber el porqué del esto y creo que el problema era que mis textos los generaba en la última línea del archivo (los textos “Master 1”, “Experimento 1”, etc.). Así que solo utilicen el archivo de Freddy y no tendrán ningún inconveniente.

El Rebase no se recomienda hacerlo,porque no es buena practica.Lo que realiza rebase es modificar la historia de git el alguna rama especifica ejemplo en máster esta rama sacamos otra rama ejemplo experimento realizamos la modificaciones después se realiza la unión primero se corre
el rebase en la rama experimento cuando ya fueran hecho todos los cambios se realiza rebase a la rama máster donde va quedar los cambio definitivamente

git rebase + nombre de la rama : apenas se corra este comando se realiza la combinación automáticamente

Combina dos ramas. (En una queda el registro de que existió la rama pero que no se aplico ningún cambio desde el branch)
Es muy mala practica hacerlo con repositorios remotos ya que en los remotos tiene que quedar registro de la historia del branch y en este caso la historia es modificada.
Es útil para arreglar un accidente de manera local.

Primero se debe aplicar el rebase desde la rama que se quiere eliminar su historia y con referencia hacia la rama donde se va a fucionar:

git rebase master

Luego se aplica desde la otra rama

git rebase experiment

Las dos quedan fucionadas. Experiment traslada sus commits a master y sigue existiendo pero sin commits

Git rebase en definitiva es una muy mala práctica, al momento de fusionar en experimento mi rama master me generó muchísimos conflictos, al final quedé con una línea repetida, la del experimento 1

Git rebase básicamente lo que hace es recopilar uno a uno los cambios confirmados en una rama, y reaplicarlos sobre otra. Utilizar rebase nos puede ayudar a evitar conflictos siempre que se aplique sobre commits que están en local y no han sido subidos a ningún repositorio remoto. Si no tienen cuidado con esto último y algún compañero utiliza cambios afectados, seguro que tendrá problemas ya que este tipo de conflictos normalmente son difíciles de reparar.

Git Rebase: reorganizando el trabajo realizado
Rebase, esto es básicamente agarrar una rama entera y pegarla de regreso a la rama maestra (Esto es una muy mala practica enviándolo a repositorios remotos, esto solamente debería hacerse internamente) en general la historia en los repositorios remotos debería mantenerse intacta, rebase es solo para repositorios locales porque rebase reescribe la historia del repositorio (es un parche) funciona en ciertos casos, es bueno preguntar a los compañeros de trabajo pero igual debemos tener mucho cuidado al hacer rebase.

(Esto es una mala practica porque cambia la historia de donde arranco el branch pero es útil si estamos haciendo un cambio local).

Primero se le hace git rebase #branchMaster a la rama que voy a desaparecer (Parado en la rama ‘experimento’) de la historia y luego se le hace git rebase #branchlExperimento (parado en la rama principal ‘Master’), sino se hace así se entra en un conflicto.

(Rebase la que cambia y luego Rebase a la rama final)

Después al hacer un git branch -D experimento notaremos que esta rama fue eliminada y al ver la historia de commits veremos que esa rama “Nunca existió”

Al hacer esto en la historia se ve como si los commits de la rama experimento y los commits de la rama master fueran el mismo commit.

Un rebase es una forma de hacer cambios silenciosos en otras ramas y volver a pegar la historia de esa rama a una rama anterior.

Me queda claro:
No usar Rebase a menos que sea realmente necesario
Mala práctica hacer rebase en el repo remoto
Si es necesario hacer rebase es mejor solo hacerlo en local

Yo dañe ese branch jajaja

~/proyecto1 (experimento|REBASE 1/2)

Me salio esto solo le di git rebase --abort y me aburrí

Rebase:

El comando rebase es una muy mala práctica y no debe ser usado, en el peor de los casos solo en tu repositorio local. Con el comando rebase puedes sobre-escribir tu rama master con cualquier otra que necesites, en el espcio justo dónde empieza tu rama y dónde termina. En sintezis, reescribes la historia de tu repositorio.

Primero, este comando se utiliza sobre la rama exterior dónde realizaste los cambios que deseas integrar. Luego, debes hacer el rebase en tu rama principal. Es importante este orden.

Con este comando no queda historia de la rama creada, se entiende como cambios silenciosos.

Siempre me salieron conflictos. No lo pude hacer limpio como Freddie pero se entendió el concepto.

si por x o y razón no le hacen caso a freedy pueden hacer esto para detener el rebase

git rebase --abort

entiendo que es practico a nivel local debido a que se puede realizar cambios ultra rapidos/silenciosos sin problemas y ya al final cuando se realice el push esto queda transparente para el repositorio online (github en este caso) y de igual forma entiendo que trae un gran numero de problemas realizar algo asi en el repositorio online, pero nunca esta de mas aprenderlo y como utlizarlo en el mundo real, never stop, never stopping… learning 😄

El primer rebase es en la rama que va a desaparecer(experiment) y después nos movemos a la rama final y haces rebase de experiment.

a demás de ser una mala practica, si rebase les da conflictos, deben usar algunas de las ayudas git rebase --continue, git rebase --skipe, git rebase --continue o git rebase --abort

Rebase

• Se sugiere usar rebase de manera LOCAL
• Reescribe la historia del repositorio
• Cambia la historia de dónde comenzó el branch
• Primero se le hace rebase a la rama que voy a desaparecer de la historia y luego se le hace rebase a la rama principal
  -> (en experimento) git rebase master
  -> (en master) git rebase experimento

Por cierto, he tratado de traducir del inglés la palabra rebase y la única traducción que me ayuda a entender su significado es una relacionada con el mundo de la odontología desde el conocido diccionario de significados Merrian-Webster:
Modificar la base de una dentadura luego de un período inicial de uso para producir un buen ajuste.
Hay quienes me han dicho que rebase significa “rebasar” los cambios. En mi opinión, esa interpretación resulta ser más bien un falso cognado en inglés (es decir, palabras en inglés y español que se asemejan en su sintáxis pero que tienen significados diferentes).

En conclusión, y luego de apreciar lo enseñado en este vídeo, pienso que rebase se trata de realizar cambios substanciales en una rama para combinar y reemplazar la historia de dicha rama con la de master que, tal como lo indica Freddy, es mejor hacerlo en local y NUNCA en producción a menos que se tenga intenciones de realizar un acto suicida.

El comando rebase es una mala práctica, nunca se debe usar, pero para efectos de curso te lo vamos a enseñar para que hagas tus propios experimentos. Con rebase puedes recoger todos los cambios confirmados en una rama y ponerlos sobre otra.

git checkout experiment

git rebase master

IMPORTANTE Rebase reescribe la historia del respositorio, cambia la historia de donde comenzo la rama y solo debe ser usado de manera local. Primero se le debe hacer rebase a la rama que queremos eliminar de la historia y luego a la rama principal. Esta practica se debe hacer unicamente en la parte local.

buenas nochex comunidad tengo el siguiente error no se como repararlo

al momento de generar el rebase se me generaron conflictos en el VS code y eso desajusto un poco la terminal, pero me senti como un plomero intentando identificar la fuga al trackear los errores escondidos, fue gratificante utilizar todo lo que he aprendido hasta el momento para resolver todo

Problemas de rebase:

• No queda historia
• No se sabe realmente quién hizo modificaciones
• Se deben arreglar los conflictos manualmente cuando la rama master tiene demasiados cambios.

rebase y reset, son cosas que uno hace solo en privado ._.

Creo que rebase solo sirve cuando quieres ocultar tus desastres :v

Hay que tener mucho cuidado de este comando y además evitar usarlo.

Pero no entiendo, para que queres hacer un cambio silencioso, si es lo mismo un merge

02:06 git rebase: Es la manera de unificar una rama entera y pegarla en la rama master, se recomienda hacerlo en los repositorios locales, es como por decirlo un parche

lo bueno de que es una mala practica, es que nunca me funciono… tuve que darte --abort 5 veces🙄

Creo que hemos usado mal el reabse en mi equipo de trabajo ¬¬

Me perdí en está clase

Esta página ayuda a entender a fondo el “rebase” incluso explica el “rebase interactivo” que es buenísimo para limpiar y ordenar el historial rápido.

Para los que se perdíeron un poco imaginando las ramas, acá les dejo una página para practicar un poco a la vez que vemos GRÁFICAMENTE lo que va sucediendo

Hice el mismo ejemplo en mi maquina y al hacer el rebase me saco errores por conflicto 😅. Pero seguí los pasos que git me indico:

Resolve all conflicts manually, mask them as resolved with: git add/rm <conflicted_files>", then run “git rebase --continue”

Basicamente lo que dice es que hay que:

1. resolver los conflictos manualmente

2. una vez resueltos añadirlos con git add (no dar commit porque entra en una especie de limbo)

3. luego correr el comando git rebase --continue

para sintetizar y después de haber visto este video varias veces, practicado etc… podemos decir que un rebase es como un merge con la salvedad que NO dejamos rastro en la historia, es decir al hacer git log, o arbolito, no veremos la historia de esa rama o ese arreglo, sino que se verá como si todo hubiese ocurrido dentro del master

Nota: No hacer rebase en el repositorio remoto, y como buena practica tampoco en la rama master aunque sea local.

Git Rebase: reorganizando el trabajo realizado
Rebase es una forma de hacer cambios silenciosos en una rama y volver a pegar todos los cambios realizados a la rama principal sin dejar registro de la otra rama en donde se hicieron los cambios.
Rebase solamente se debe de usar en nuestro repositorio local, nunca se deberia de utilizar en repositorios remotos ya que borra el historial de las otras ramas y no queda registro de quien hizo que cosa.
La forma correcta de utilizar rebase es primero situarnos en la rama donde hicimos los cambios y desde esa rama ejecutar el comando git rebase + rama_principal, esto nos traerá todos los commits que se hayan echo en la rama principal y luego nos movemos a la rama principal utilizando el comando git checkout + rama_principal, y desde ahí volvemos a ejecutar rebase pero en esta ocasión utilizaremos el nombre de la rama donde ejecutamos el rebase previamente y de esta manera se traerán todos los commits de la otra rama y se pegaran a nuestra rama principal y no habrá registro de lo que ocurrió en aquella rama, de hecho podemos borrar esa rama y no pasaría nada.
No considero que utilizar rebase sea del todo una mala practica pero coincido con Freddy de que si no se utiliza de una manera adecuada puede causar grandes problemas.

****REESCRIBIR LA HISTORIA DE UN COMMIT:

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

rebase interactivo:
git rebase -i HEAD~3 ----permite cambiarle el mensaje de commit y otras muchas funciones a tus ultimos 3 commits.

si quieres juntar commits, en el rebase interactivo cambiar la palabra pick por la palabra squash y podrás juntar
los últimos 3 commits en uno solo, ahí están reescribiendo la historia de tus commits, sirve para llevar a produccion.

saben que con

git chekaut -b (name branch) 

pueden hacen una nueva branch y se van a la rama con todos tus cambios que estés haciendo

rebase no estará en la lista de mis favoritos, prefiero mantener todo el historial, antes pensé que podía usarse como una forma de limpiar commits y dejar digamos una rama de tantos commits en un solo commit pero no.

No es un copy paste, es un cut y paste

Entonces el rebase es como el modo incognito de google ???

Está bueno saberlo, pero para la práctica profesional no suma

Me costo, pero entendí el rebase jajaja

Esto es como tratar de entender las paradojas del tiempo de Volver al Futuro.

Se hace rebase en experimento (rama creada, distinta a master), luego checkout a master. Estando en master se hace rebase experimento

Me parece interesante

No sé por qué, pero siento que muchos se van a equivocar aquí. Primero hay que hacer un rebase a la rama que ignorarás y luego un rebase a la rama que quedará al final

Primero rebase a la que cambia, luego rebase a la rama final

Rebase Punto Importante

Excelente explicacion para el comando Rebase, gracias

Como hacía para mostrar el “arbolito” en la consola? Me confunde. Gracias!

Notar que no es del todo silencioso: "Committed x minutes ago" nos delata.

Ni pendiente con ese rebase… git reset y listo. Sorry Freddy 😦

Que chingon es git, Torvalds es rifado!

1. Rebase en la rama que ha cambiado (experimento).
2. Rebase en la rama final (master).

ufff esto sale como pan caliente en donde trabajo ajajjaj

buen dato