{"id":346247,"date":"2022-12-13T11:29:07","date_gmt":"2022-12-13T11:29:07","guid":{"rendered":"https:\/\/magazineoffice.com\/git-rebase-todo-lo-que-necesitas-saber\/"},"modified":"2022-12-13T11:29:09","modified_gmt":"2022-12-13T11:29:09","slug":"git-rebase-todo-lo-que-necesitas-saber","status":"publish","type":"post","link":"https:\/\/magazineoffice.com\/git-rebase-todo-lo-que-necesitas-saber\/","title":{"rendered":"Git rebase: Todo lo que necesitas saber"},"content":{"rendered":"


\n<\/p>\n

\n
fatmawati achmad zaenuri\/Shutterstock.com<\/span><\/figcaption><\/figure>\n

El comando Git rebase mueve una rama a una nueva ubicaci\u00f3n en la cabecera de otra rama. A diferencia del comando de fusi\u00f3n de Git, rebase implica volver a escribir el historial de su proyecto. Es una gran herramienta, pero no rebase las confirmaciones en las que otros desarrolladores han basado el trabajo.<\/p>\n

el git rebase<\/code> El comando combina dos ramas del c\u00f3digo fuente en una sola. el git merge<\/code> comando hace eso tambi\u00e9n. Te explicamos qu\u00e9 rebase<\/code> hace, c\u00f3mo se usa y cu\u00e1ndo usar merge<\/code> en cambio.<\/p>\n

La explosi\u00f3n de Git<\/h2>\n

Frustrado con otros sistemas de control de versiones y sus lentas actualizaciones y confirmaciones, Linus Torvalds, famoso por el kernel de Linux, dedic\u00f3 un mes en 2005 a escribir el suyo propio. Lo llam\u00f3 Git.<\/p>\n

Sitios como GitHub, GitLab y BitBucket han promovido simbi\u00f3ticamente y se han beneficiado de Git. Hoy en d\u00eda, Git se usa a nivel mundial, con un masivo 98 por ciento de 71 mil encuestados en una encuesta de 2022 que usa Git como sistema de control de versiones.<\/p>\n

Una de las principales decisiones de dise\u00f1o de Git fue la velocidad. En particular, el trabajo con ramas ten\u00eda que ser lo m\u00e1s r\u00e1pido posible. Las sucursales son una parte fundamental de los sistemas de control de versiones. Un repositorio de proyectos tendr\u00e1 una rama principal o maestra. Aqu\u00ed es donde se encuentra el c\u00f3digo base del proyecto. El desarrollo, como las nuevas caracter\u00edsticas, se lleva a cabo en ramas laterales segregadas. Esto evita que el trabajo realizado en las ramas estropee la rama principal y permite que se produzca un desarrollo simult\u00e1neo en diferentes partes de la base de c\u00f3digo.<\/p>\n

A medida que se completan los desarrollos en las ramas laterales, los cambios se transfieren a la rama maestra al fusionar la rama de desarrollo con la rama maestra. En otros sistemas de control de versiones, trabajar con sucursales era dif\u00edcil y computacionalmente costoso. Trabajar con ramas en Git es muy r\u00e1pido y muy ligero. Lo que antes era un ejercicio tedioso y evitado en otros sistemas, se volvi\u00f3 trivial en Git.<\/p>\n

el git rebase<\/code> El comando es otra forma de transferir los cambios de una rama a otra rama. los merge<\/code> y rebase<\/code> Los comandos tienen objetivos similares, pero logran sus fines de diferentes maneras y producen resultados ligeramente diferentes.<\/p>\n

\u00bfQu\u00e9 es la fusi\u00f3n de Git?<\/h2>\n

Entonces, \u00bfqu\u00e9 es el Git? merge<\/code> comando para? Digamos que ha creado una rama llamada dev-branch<\/code> para trabajar en una nueva funci\u00f3n.<\/p>\n

\"Un
Dave McKay\/C\u00f3mo hacer geek<\/span><\/figcaption><\/figure>\n

Realiza algunas confirmaciones y prueba su nueva funci\u00f3n. Todo funciona bien. Ahora desea enviar su nueva funci\u00f3n al master<\/code> rama. debes estar en el master<\/code> rama para unir otra a ella.<\/p>\n

Podemos asegurarnos de que estamos en el master<\/code> ramificaci\u00f3n revis\u00e1ndola expl\u00edcitamente antes de fusionarnos.<\/p>\n

git checkout master<\/pre>\n
Ahora podemos decirle a Git que fusione el dev-branch<\/code> en la rama actual, que es la master<\/code> rama.<\/p>\n
git merge dev-branch<\/pre>\n
\"Fusi\u00f3n<\/p>\n
Nuestro merge<\/code> se completa para nosotros.  Si revisas el master<\/code> ramificar y compilarlo, tendr\u00e1 la caracter\u00edstica recientemente desarrollada.  Lo que Git realmente ha realizado es una combinaci\u00f3n de tres v\u00edas.  compara los commits m\u00e1s recientes en el master<\/code> y dev-branch<\/code> sucursales, y la confirmaci\u00f3n en el master<\/code> sucursal inmediatamente antes de la dev-branch<\/code> fue creado.  A continuaci\u00f3n, realiza una confirmaci\u00f3n en el master<\/code> rama.<\/p>\n
Las fusiones se consideran no destructivas porque no eliminan nada y no cambian nada del historial de Git.  los dev-branch<\/code> todav\u00eda existe, y ninguna de las confirmaciones anteriores se modifica.  Se crea una nueva confirmaci\u00f3n que captura los resultados de la combinaci\u00f3n de tres v\u00edas.<\/p>\n
Despu\u00e9s de la fusi\u00f3n, nuestro repositorio de Git parece una l\u00ednea de tiempo con una l\u00ednea alternativa que se bifurca y luego regresa a la l\u00ednea de tiempo principal.<\/p>\n
\"La
Dave McKay\/Geek de instrucciones<\/span><\/figcaption><\/figure>\n
los dev-branch<\/code> sucursal se ha incorporado a la master<\/code> rama.<\/p>\n
Si tiene muchas sucursales en un proyecto, la historia del proyecto puede volverse confusa.  Este suele ser el caso si un proyecto tiene muchos colaboradores.  Debido a que el esfuerzo de desarrollo se divide en muchas rutas diferentes, el historial de desarrollo no es lineal.  Desenredar el historial de confirmaciones se vuelve a\u00fan m\u00e1s dif\u00edcil si las sucursales tienen sus propias sucursales.<\/p>\n
Tenga en cuenta que si tiene cambios no confirmados en el master<\/code> branch, deber\u00e1 hacer algo con estos cambios antes de poder fusionar algo en \u00e9l.  Puede crear una nueva rama y confirmar los cambios all\u00ed, y luego realizar la fusi\u00f3n.  Luego, deber\u00e1 fusionar su rama temporal nuevamente en la rama principal.<\/p>\n
Eso funciona, pero Git tiene un comando que logra lo mismo, sin tener que crear nuevas ramas.  los stash<\/code> El comando almacena los cambios no confirmados por usted y le permite recuperarlos con stash pop<\/code> .<\/p>\n
Los usar\u00edas as\u00ed:<\/p>\n
stash
\n
\ngit merge dev-branch
\n
\nstash pop<\/pre>\n
El resultado final es una rama fusionada, con los cambios no guardados restaurados.<\/p>\n
\u00bfQu\u00e9 es Git rebase?<\/h2>\n
el git rebase<\/code> comando logra sus objetivos de una manera completamente diferente.  Toma todas las confirmaciones de la rama en la que se va a reorganizar y las reproduce en el final de la rama en la que se est\u00e1 reorganizando.<\/p>\n
Tomando nuestro ejemplo anterior, antes de realizar cualquier acci\u00f3n, nuestro repositorio de Git se ve as\u00ed.  Tenemos una sucursal llamada dev-branch<\/code> y queremos mover esos cambios a la master<\/code> rama.<\/p>\n
\"Un
Dave McKay\/C\u00f3mo hacer geek<\/span><\/figcaption><\/figure>\n
Despu\u00e9s de la rebase<\/code> parece una \u00fanica l\u00ednea de tiempo de cambios completamente lineal.<\/p>\n
\"La
Dave McKay\/Geek de instrucciones<\/span><\/figcaption><\/figure>\n
los dev-branch<\/code> ha sido eliminado, y las confirmaciones en el dev-branch<\/code> se han agregado a la rama principal.  El resultado final es el mismo que si las confirmaciones en el dev-branch<\/code> en realidad se hab\u00eda comprometido directamente con el master<\/code> rama en primer lugar.  Las confirmaciones no solo se a\u00f1aden al master<\/code> rama, se \u00abreproducen\u00bb y se agregan nuevos.<\/p>\n
Esta es la raz\u00f3n por la cual el rebase<\/code> comando se considera destructivo.  La rama reorganizada ya no existe como una rama separada y el historial de Git de su proyecto se ha reescrito.  No puede determinar en alg\u00fan momento posterior qu\u00e9 confirmaciones se realizaron originalmente en el dev-branch<\/code>.<\/p>\n
Sin embargo, te deja con una historia simplificada y lineal.  En comparaci\u00f3n con un repositorio con docenas o incluso cientos de ramas y fusiones, leer el registro de Git o usar una GUI gr\u00e1fica de Git para ver un gr\u00e1fico del repositorio, un repositorio reorganizado es muy f\u00e1cil de entender.<\/p>\n
C\u00f3mo cambiar de base a otra rama<\/h2>\n
Probemos un git rebase<\/code> ejemplo.  Tenemos un proyecto con una rama llamada new-feature<\/code>.  Casarse rebase<\/code> esa rama hacia el master<\/code> rama como esta.<\/p>\n
Primero, comprobamos que el master<\/code> sucursal no tiene cambios destacados.<\/p>\n
git status<\/pre>\n
Verificamos el new-feature<\/code> rama.<\/p>\n
git checkout new-feature<\/pre>\n
Le decimos a Git que rebase<\/code> la rama actual en la rama maestra.<\/p>\n
git rebase master<\/pre>\n
Podemos ver que todav\u00eda tenemos dos sucursales.<\/p>\n
git branch<\/pre>\n
Cambiamos de nuevo a la master<\/code> rama<\/p>\n
git checkout master<\/pre>\n
Fusionamos la rama de nuevas funciones con la rama actual, que en nuestro caso es la master<\/code> rama.<\/p>\n
git merge new-feature<\/pre>\n
\"La
Dave McKay\/Geek de instrucciones<\/span><\/figcaption><\/figure>\n
Curiosamente, todav\u00eda tenemos dos sucursales despu\u00e9s de la fusi\u00f3n final.<\/p>\n
\"Usando
Dave McKay\/Geek de instrucciones<\/span><\/figcaption><\/figure>\n
La diferencia es que ahora el jefe de la new-feature<\/code> rama y el jefe de la master<\/code> rama est\u00e1n configurados para apuntar a la misma confirmaci\u00f3n, y el historial de Git no muestra que sol\u00eda haber una new-feature<\/code> rama, aparte de la etiqueta de la rama.<\/p>\n
\"La
Dave McKay\/Geek de instrucciones<\/span><\/figcaption><\/figure>\n
Git Rebase vs. Merge: \u00bfCu\u00e1l deber\u00eda usar?<\/h2>\n
no es un caso de rebase<\/code> contra merge<\/code>.  Ambos son comandos poderosos y probablemente los usar\u00e1 a ambos.  Dicho esto, hay casos de uso en los que rebase<\/code> realmente no funciona tan bien.  Desechar errores causados \u200b\u200bpor errores usando merge<\/code> son desagradables, pero los errores de eliminaci\u00f3n causados \u200b\u200bpor rebase<\/code> es infernal<\/p>\n
Si es el \u00fanico desarrollador que usa un repositorio, hay menos posibilidades de que haga algo con rebase<\/code> eso es desastroso.  todav\u00eda podr\u00edas rebase<\/code> en la direcci\u00f3n equivocada, por ejemplo, y rebase<\/code> su rama principal en su new-feature<\/code> rama.  para conseguir tu master<\/code> bifurcarse hacia atr\u00e1s, necesitar\u00eda rebase<\/code> otra vez, esta vez de su new-feature<\/code> ramifica a tu master<\/code> rama.  Eso restaurar\u00eda su master<\/code> rama, aunque con una historia de aspecto extra\u00f1o.<\/p>\n
no usar rebase<\/code> en sucursales compartidas donde es probable que otros trabajen.  Tus cambios en tu repositorio van a causar problemas a muchas personas cuando env\u00edes tu c\u00f3digo rebasado a tu repositorio remoto.<\/p>\n
Si su proyecto tiene varios colaboradores, lo m\u00e1s seguro es usar solo rebase<\/code> en tu local<\/em> repositorio, y no en sucursales p\u00fablicas.  Del mismo modo, si las solicitudes de extracci\u00f3n forman parte de sus revisiones de c\u00f3digo, no use rebase<\/code>.  O al menos, no usar rebase<\/code> despu\u00e9s de crear la solicitud de extracci\u00f3n.  Es probable que otros desarrolladores est\u00e9n mirando sus confirmaciones, lo que significa que esos cambios est\u00e1n en una rama p\u00fablica, incluso si no est\u00e1n en el master<\/code> rama.<\/p>\n
El peligro es que vas a rebase<\/code> confirmaciones que ya se han enviado a un repositorio remoto, y es posible que otros desarrolladores ya hayan basado su trabajo en esas confirmaciones.  tu local rebase<\/code> har\u00e1 que esos compromisos existentes desaparezcan.  Si env\u00eda esos cambios al repositorio, no ser\u00e1 popular.<\/p>\n
Otros colaboradores tendr\u00e1n que pasar por un complicado merge<\/code> para que su trabajo sea devuelto al repositorio.  Si luego vuelve a colocar sus cambios en su repositorio local, se enfrentar\u00e1 a deshacer un l\u00edo de cambios duplicados.<\/p>\n
\u00bfRebase o no Rebase?<\/h2>\n
Rebase<\/code>  podr\u00eda estar fuera de la ley en su proyecto.  Puede haber objeciones culturales locales.  Algunos proyectos u organizaciones consideran rebase<\/code> como una forma de herej\u00eda y un acto de profanaci\u00f3n.  Algunas personas creen que el historial de Git deber\u00eda ser un registro permanente e inviolable de lo que sucedi\u00f3.  Asi que, rebase<\/code> podr\u00eda estar fuera de la mesa.<\/p>\n
Pero, usado localmente, en sucursales privadas, rebase<\/code> es una herramienta \u00fatil.<\/p>\n
Empujar despu\u00e9s<\/em> ha reorganizado y restringirlo a sucursales donde usted es el \u00fanico desarrollador.  O al menos, donde todo el desarrollo se ha detenido y nadie m\u00e1s ha basado ning\u00fan otro trabajo en las confirmaciones de su rama.<\/p>\n
Haz eso y te evitar\u00e1s cualquier problema.<\/p>\n
RELACIONADO:<\/strong> C\u00f3mo verificar y actualizar su versi\u00f3n de Git<\/em><\/strong><\/p>\n<\/div>\n