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.
El comando rebase es **_una mala práctica, sobre todo en repositorios remotos. Se debe evitar su uso, pero para efectos de práctica te lo vamos a mostrar, para que hagas tus propios experimentos. Con rebase puedes recoger todos los cambios confirmados en una rama y ponerlos sobre otra.
# Cambiamos a la rama que queremos traer los cambiosgit checkout experiment
# Aplicamos rebase para traer los cambios de la rama que queremos git rebase master
rebase reescribe la historia del repositorio, cambia la historia de donde comenzó la rama y solo debe ser usado de manera local.
Gracias!
A buen dato.
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.
Gracias por el aporte
Excelente gracias :D
¿Sabían que el comando:
git checkout -
cambia del actual branch al anterior branch en el que hubieran estado?
gracias muy útil
Exclente, muy util el dato bro!
==Comparto algunos apuntes adicionales==
Además comparto una comparación entre Git Merge y Git Rebase:
Muy bueno, Gracias!!!
muchas gracias, es un buen resumen para complementar la clase!!
Cuando usas Rebase
Jajajajajajjajajajajaja
Me sentí igualito. :)
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?
Uuuy que buen uso, gracias por el dato!
excelente, yo también le veo varios usos, en especial el rebase interactivo, me parece mal que digan q no se debiera usar,
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
¿En que te perdiste amigo?, Yo al principio pensaba lo mismo pero mas sencillo de lo que parece, seguramente te dieron conflictos con las ramas pues tenemos que tomar en cuanta las lineas de codigo que modificamos, si te fijas el no mueve master 1 nunca desde que lo crea, solo agrega exp 1 y 2 arriba de el es por eso que no le da conflictos si no tendras que resolverlos y es normal sentirse así, puedes utilizar como lo dice un resen y volver a intentarlo. Si tienes alguna duda te dejo mi correo y podemos platicar mas a fondo! Saludos y buen codigo! jaime.mac001@gmail.com
Yo dije lo mismo pero uno debe practicar buen amigo, a mi me daba conflicto hasta que identifique mi erro luego de varios intentos, te invito a hacerlo aunque sea solo para tenerlo en mente, saludo Joel!! :)
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.
Me parece genial este aporte Jared, Saludos.
Muy bueno tu aporte, aunque me surge una duda, esto mismo no lo podríamos realizar con un git reset --soft a un commit anterior (quizás 2 o 3 commits anteriores por ejemplo) y luego dar git commit y así compactar varias ramas en un commit ?
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
la nemotecnia es tu amiga...
Solo que con palabras completas son dos guiones: git log --all --decorate --oneline --graph
Buen aporte!
# 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
Con gusto!
Un buen aporte. Gracias William!
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
Jajajajaaja creo que mejor práctica es reescribiendo la historia de la rama con este comando .
git commit --amend --no-edit .
Con este comando creo yo que una mejor practica para rescribir el mensaje y los archivos .
git commit --amend
Se puede usar el siguiente comando en tal caso:
git branch -m <viejo nombre de la rama><nuevo nombre de la rama>
Básicamente renombras la rama que tienes. No sé por qué se ha coloreado así
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.
Hay un caso en el que un rebase es muy útil. Tienes una rama, haces un pull request de esa rama y dicho pull request ha sido aprobado y mergeado a máster por el equipo encargado de esto.
Todo bien, sin embargo el equipo de QA encuentra un escenario en el que tu fix no funciona. Entonces el issue pasa de resuelto a re abierto y debes volver a trabajar en él.
Tomas tu branch, creas uno nuevo para no dañar el anterior, trabajas en el nuevo escenario y entonces haces rebase del branch anterior, ahora vuelves a tu branch anterior y te traes el nuevo escenario al branch original que habías trabajado antes. Finalmente tienes todos tus cambios en un mismo branch, el mismo que había sido mergeado a máster.
Ahora pides un nuevo pull request que es aprobado y mergeado para ser probado por el equipo de QA. A los ojos de todos trabajaste siempre en el mismo branch, sin embargo no fue así.
claro pero no en el repositorio base, o no en el repositorio online, o lo haces en tu propio repositorio o en local, pero el repo oficial se queda sin el rebase, no se si me dejé entender
Gracias
Como esto es una mala practica me quedo con el merge.
Si con la vieja confiable.
Jajaja claro siempre la vieja confiable
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 mastergit merge prueba
.
.
Ejempo de mezcla de ramas con git rebase
.
git checkout mastergit 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.
ESto era lo que me faltaba leer, gracias!
De nada bro me alegra que te sirvio
¿Por qué no le da conflictos cuando hace el segundo rebase y a mí si?
Se supone que modifico las mismas lineas y deberia de aparecer el conflicto no?
Muestra tu código Eduardo,
No da conflicto porque solo agrego lineas entonces el flujo de trabajo queda como que cada linea agregada fue un comió, algo conflictos se dan por ejemplo cuando el la misma linea cambiamos por ejemplo una palabra o algo así pero en este caso lo que sucedió fue que el solo agrego y no cambio cosas.
Así lo veo yo puede que este equivocado pero espero que te sirva mi respuesta saludos.
donde dice comio es commit*
¿Porque a Freddy no le aparece conflicto a pesar de que modifica las mismas lineas?
y a mi si me sale un conflicto
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
Tenemos3 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
Buen dato compañero.
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:
Primero editar en tu editor de codigo, el error que te salga.
Luego guarda CTRL + S.
Regresa a GIT y escribe git add historia.txt + ENTER.
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 🔥🔥🔥
al usar mi comando "arbolito" me dice que no existe ¿el nombre que yo le puse a la linea de comandos se borra cuando cierro Git?
Eso es porque solo funciona en la sesión de terminal donde ejecutaste el comando de establecer el alias de "arbolito", para tenerlo de forma permanente y suponiendo que la terminal que uses es git bash debes editar un archivo llamado .bashrc, para ello ejecutas el siguiente comando
vim ~/.bash_profile
Y agregas la linea para establecer el alias al final del archivo
alias arbolito="git log --oneline --graph --decorate --all"
Y guardas el archivo con Shitf+Z+Z
Luego la próxima vez que abras git bash ya tendrás disponible el comando o puedes ejecutar
source ~/.bash_profile
Para tenerlo disponible inmediatamente
Entré por acá por exactamente la misma duda. Que el arbolito se marchitó y se quedó sin hojas 😅