La guía avanzada de Git: Git Stash, Reset, Rebase y más

Todo desarrollador debe tener una buena comprensión del control de versiones, y Git se ha convertido en el estándar de facto para el control de versiones en el desarrollo de software.

Sin embargo, a menudo, los desarrolladores solo aprenden unos pocos comandos simples y pasan por alto el poder del historial de Git y las otras cosas que Git puede hacer para que sea mucho más eficiente. Por ejemplo, administrar lanzamientos es muy fácil con Git usando git tag .

Tomé un curso avanzado en Git en línea (con Github) y procedí a enseñar una clase de Git para principiantes junto con Github. Cuando me di cuenta de que no había muchos artículos técnicos sobre mis características favoritas de Git, aproveché la oportunidad para compartirlo con mis compañeros desarrolladores. En esta publicación, aprenderá cómo aprovechar las siguientes funciones avanzadas de Git:

• git stash , que hace un guardado local temporal de su código
• git reset , que te permite ordenar tu código antes de realizar una confirmación
• git bisect , una función que te permite buscar confirmaciones incorrectas
• git squash , que te permite combinar tus confirmaciones
• git rebase , que permite aplicar cambios de una rama a otra

Alijo Git

Git stash le permite guardar su código sin realizar una confirmación. ¿Cómo es esto útil? Imagina el siguiente escenario:

Ya ha realizado tres confirmaciones claras y ordenadas, pero también tiene un código no confirmado que es bastante desordenado; no querrá confirmarlo sin eliminar primero su código de depuración. Entonces, por alguna razón, de repente necesita atender otra tarea y tiene que cambiar de sucursal. Esto puede suceder a menudo si está en su rama main y se olvidó de crear una nueva rama para su característica. En este momento, su código se ve así:

 $ git status On branch my-feature Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: css/common.scss no changes added to commit (use "git add" and/or "git commit -a")

 $ git diff diff --git a/css/common.scss b/css/common.scss index 2090cc4..90fd457 100644 --- a/css/common.scss +++ b/css/common.scss @@ -13,6 +13,6 @@ body { font-family: "Proxima Nova", Arial, sans-serif; font-size: 13px; - color: #333; + color: red; background-color: #f00; }

Cuando ejecutas git stash , el código no confirmado desaparece sin ser confirmado. Stashing es como guardar un compromiso local temporal en su sucursal. No es posible enviar un alijo a un repositorio remoto, por lo que un alijo es solo para su uso personal.

 $ git stash Saved working directory and index state WIP on my-feature: 49ee696 Change text color

Tu rama ahora aparece como estaba cuando hiciste tu última confirmación. Ahora, puede cambiar de rama de manera segura sin perder su código o tener una confirmación desordenada. Cuando vuelvas a tu rama y git stash list , verás una lista de alijos que se parece a esto:

 $ git stash list stash@{0}: WIP on my-feature: 49ee696 Change text color

Puede volver a aplicar fácilmente el contenido escondido ejecutando git stash apply . También puedes aplicar un alijo específico (si lo has hecho más de una vez) ejecutando git stash apply stash@{1} (el '1' indica el penúltimo alijo). Aquí hay un ejemplo de ocultar más de una confirmación y aplicar un alijo diferente:

 $ git diff diff --git a/css/common.scss b/css/common.scss index 2090cc4..90fd457 100644 --- a/css/common.scss +++ b/css/common.scss @@ -13,6 +13,6 @@ body { font-family: "Proxima Nova", Arial, sans-serif; font-size: 13px; - color: #333; + color: red; background-color: #f00; } $ git stash Saved working directory and index state WIP on my-feature: 49ee696 Change text color $ git diff diff --git a/css/common.scss b/css/common.scss index 2090cc4..b63c664 100644 --- a/css/common.scss +++ b/css/common.scss @@ -13,6 +13,6 @@ body { font-family: "Proxima Nova", Arial, sans-serif; font-size: 13px; - color: #333; + color: red; background-color: #f00; } $ git stash Saved working directory and index state WIP on my-feature: 49ee696 Change text color

 $ git stash list stash@{0}: WIP on my-feature: 49ee696 Change text color stash@{1}: WIP on my-feature: 49ee696 Change text color stash@{2}: WIP on my-feature: 49ee696 Change text color $ git stash apply stash@{2} On branch my-feature Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: css/common.scss no changes added to commit (use "git add" and/or "git commit -a")

git stash apply stash@{2} aplicó el código oculto más antiguo, cuando cambiamos el color del texto a rojo.

 $ git diff diff --git a/css/common.scss b/css/common.scss index 2090cc4..90fd457 100644 --- a/css/common.scss +++ b/css/common.scss @@ -13,6 +13,6 @@ body { font-family: "Proxima Nova", Arial, sans-serif; font-size: 13px; - color: #333; + color: red; background-color: #f00; }

Si decide no confirmar su trabajo una vez que haya restaurado el alijo, puede ejecutar git checkout . , que restablece todo el código no confirmado.

Como otro ejemplo de cómo usar Git Stash: digamos que tiene algunos archivos nuevos, uno de los cuales tiene un error. Deje todo, excepto el archivo de error sospechoso, sin preparar (el código debe estar preparado para ser escondido), luego puede esconder ese archivo y solucionar el problema. Si el archivo oculto no era el problema, puede restaurarlo.

 $ git status On branch my-feature Untracked files: (use "git add <file>..." to include in what will be committed) css/colors.scss nothing added to commit but untracked files present (use "git add" to track)

 $ git add css/colors.scss $ git stash Saved working directory and index state WIP on my-feature: 0d8deef delete colors $ git status On branch my-feature nothing to commit, working tree clean $ git stash apply stash@{0} On branch my-feature Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: css/colors.scss

También puedes trasladar tus confirmaciones ocultas a una nueva rama de funciones o a una rama de depuración usando git stash branch :

 $ git status On branch my-feature Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: css/common.scss no changes added to commit (use "git add" and/or "git commit -a") $ git stash Saved working directory and index state WIP on my-feature: 66f3f3b Add colors file $ git stash branch debugging-branch M css/common.scss Switched to a new branch 'debugging-branch' Unstaged changes after reset: M css/common.scss On branch debugging-branch Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: css/common.scss Dropped refs/stash@{0} (d140624f60d8deef7bceb0d11fc80ed4fd47e0a1)

Tenga en cuenta que cuando ha aplicado un alijo, el alijo no se elimina. Puedes eliminar los alijos individualmente usando git drop , o eliminar todos los alijos usando git stash clear :

 $ git stash list stash@{0}: WIP on my-feature: 66f3f3b Add colors file stash@{1}: WIP on my-feature: 0d8deef delete colors stash@{2}: WIP on my-feature: 49ee696 Change text color $ git stash drop stash@{2} Dropped stash@{2} (8ed6d2ce101aa2e28c8ccdc94cb12df8e5c468d6) $ git stash list stash@{0}: WIP on my-feature: 66f3f3b Add colors file stash@{1}: WIP on my-feature: 0d8deef delete colors $ git stash clear $ git stash list $

Restablecer Git

Si te encuentras en una situación en la que accidentalmente cometiste un código desordenado, puedes hacer un reinicio "suave". Esto significa que el código aparece como si aún no se hubiera confirmado. Luego, puede ordenar su código en su IDE antes de realizar una confirmación más limpia. Para hacer esto, puede ejecutar git reset --soft HEAD~1 . Esto restablecerá la confirmación más reciente. Puede restablecer más de una confirmación cambiando el número después de ~ por ejemplo, git reset --soft HEAD~2 .

 $ git reset --soft HEAD~1 $ git status On branch debugging-branch Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: css/common.scss Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: css/common.scss

 $ git diff diff --git a/css/common.scss b/css/common.scss index 2090cc4..90fd457 100644 --- a/css/common.scss +++ b/css/common.scss @@ -13,6 +13,6 @@ body { font-family: "Proxima Nova", Arial, sans-serif; font-size: 13px; - color: $grey; + color: red; background-color: #f00; }

El restablecimiento de Git es un poco más confuso, especialmente cuando se enseña a los nuevos usuarios de Git. Un restablecimiento parcial debe reservarse para un error genuino, mientras que un alijo se puede usar para intercambiar código dentro y fuera.

También puede realizar un restablecimiento completo ( git reset --hard HEAD~1 ). Este tipo de reinicio esencialmente borra tu última confirmación. Debe tener mucho cuidado al realizar restablecimientos completos, especialmente si presiona su rama, ya que no hay forma de restaurar su confirmación.

Git bisecar

Mi herramienta Git favorita es git bisect . Solo lo he necesitado un puñado de veces, pero cuando lo hice, ¡fue invaluable! Lo usé principalmente en grandes bases de código donde había un problema para el cual nadie encontró la causa raíz, incluso después de una depuración vigorosa.

git bisect esencialmente realiza una búsqueda binaria entre dos confirmaciones dadas y luego le presenta los detalles de una confirmación específica. Primero debe darle a Git un buen compromiso, donde sabe que su funcionalidad estaba funcionando, y un mal compromiso. Tenga en cuenta que siempre que tenga un compromiso bueno y uno malo, los compromisos pueden estar separados por años (aunque cuanto más retroceda en el tiempo, ¡más difícil se vuelve!).

Lo más divertido de git bisect es que, por lo general, no sabes quién escribió la confirmación con errores cuando comienzas. ¡La emoción de descubrir dónde se introdujo el error ha provocado que algunos compañeros de trabajo se acurruquen alrededor de mi computadora más de una vez!

Para comenzar, echa un vistazo a la rama con errores y encuentra las buenas confirmaciones. Deberá revisar su historial de confirmación y encontrar el hash de confirmación, luego verifique esa confirmación específica y pruebe su rama. Una vez que encuentre un buen y un mal lugar para trabajar, puede ejecutar un git bisect .

En este escenario, el texto es rojo en este sitio web que creamos (aunque podría usar un diseñador de interfaz de usuario), pero no sabemos cómo ni cuándo se hizo rojo. Este es un ejemplo muy simple, en un escenario de la vida real, probablemente tendría un problema mucho menos obvio, por ejemplo, un formulario que no se envía/funciona.

Cuando ejecutamos un git log , podemos ver la lista de confirmaciones para elegir.

 $ git log commit a3cfe7f935c8ad2a2c371147b4e6dcd1a3479a22 (HEAD -> main) Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 10:52:57 2021 +0100 Update .gitignore file for .DS_Store commit 246e90977790967f54e878a8553332f48fae6edc Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 10:51:23 2021 +0100 Change styling of page commit d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 10:50:48 2021 +0100 Change text color commit 032a41136b6653fb9f7d81aef573aed0dac3dfe9 Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 10:42:57 2021 +0100 Change text color commit 246e90977790967f54e878a8553332f48fae6edc Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 10:41:23 2021 +0100 delete colors commit d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 10:50:48 2021 +0100 Change text color commit ce861e4c6989a118aade031020fd936bd28d535b Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 10:07:36 2021 +0100 ...

Si abro mi página web en el hash de confirmación más reciente, el texto es rojo, entonces sé que tengo un problema.

Ahora comenzamos la bisección y le decimos a Git que tenemos una confirmación incorrecta.

 $ git bisect start $ git bisect bad 8d4615b9a963ef235c2a7eef9103d3b3544f4ee1

Ahora retrocedemos en el tiempo para intentar encontrar una confirmación donde el texto no estaba en rojo. Aquí intento comprobar mi primer compromiso...

 $ git checkout ce861e4c6989a118aade031020fd936bd28d535b Note: checking out 'ce861e4c6989a118aade031020fd936bd28d535b'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at ce861e4 Add CSS styles

…y actualizando la página web…

El texto ya no es rojo, ¡así que este es un buen compromiso! Cuanto más nuevo sea el commit, es decir, cuanto más cerca esté del mal commit, mejor:

 $ git checkout d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e Previous HEAD position was ce861e4c6989a118aade031020fd936bd28d535b Add CSS styles HEAD is now at d647ac4 Change text color

Git ahora te dirá cuántas confirmaciones tiene que buscar antes de encontrar la correcta. La cantidad de confirmaciones que atravesará Git depende de cuántas confirmaciones haya entre la confirmación buena y la mala (cuanto más tiempo, más veces Git necesita iterar).

Ahora, deberá probar su rama nuevamente y ver si su problema ha desaparecido. A veces, esto puede ser un poco engorroso si actualiza los módulos con regularidad, ya que es posible que deba reinstalar los módulos de nodo en su repositorio front-end. Si ha habido actualizaciones de la base de datos, es posible que también deba actualizarlas.

git bisect verifica automáticamente una confirmación en medio de sus confirmaciones buenas y malas. Aquí está estimando un paso para encontrar el compromiso incorrecto.

 $ git bisect good 1cdbd113cad2f452290731e202d6a22a175af7f5 Bisecting: 1 revision left to test after this (roughly 1 step) [ce861e4c6989a118aade031020fd936bd28d535b] Add CSS styles $ git status HEAD detached at ce861e4 You are currently bisecting, started from branch '8d4615b'. (use "git bisect reset" to get back to the original branch)

Actualice la página y vea si su problema desapareció. El problema sigue ahí, así que le decimos a Git que sigue siendo una mala confirmación. No es necesario hacer referencia al hash de confirmación esta vez, ya que Git utilizará la confirmación que ha verificado. Tendremos que repetir este proceso hasta que Git haya recorrido todos los pasos posibles.

 $ git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [cbf1b9a1be984a9f61b79ae5f23b19f66d533537] Add second paragraph to page

Actualice la página y nuestro problema desaparecerá nuevamente, por lo que esta es una buena confirmación:

En esta etapa, Git ha encontrado la primera confirmación incorrecta:

 $ git bisect good ce861e4c6989a118aade031020fd936bd28d535b is the first bad commit commit ce861e4c6989a118aade031020fd936bd28d535b Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 10:52:57 2021 +0100 Add CSS styles :000000 100644 0000000000000000000000000000000000000000 092bfb9bdf74dd8cfd22e812151281ee9aa6f01a M css

Ahora podemos usar git show para mostrar la confirmación e identificar el problema:

 $ git show ce861e4c6989a118aade031020fd936bd28d535b commit ce861e4c6989a118aade031020fd936bd28d535b Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 10:52:57 2021 +0100 Add CSS styles diff --git a/css/base.scss b/css/base.scss index e69de29..26abf0f 100644 --- a/css/base.scss +++ b/css/base.scss @@ -1,7 +1,7 @@ body { background-color: $white; margin: 0px; line-height: 20px; - color: $grey; + color: red; }

Cuando haya terminado, puede ejecutar git bisect reset para restablecer su rama a su estado de funcionamiento normal.

Cuanto más cerca estén las confirmaciones, más fácil será que Git encuentre el problema, pero he tenido que tomar 10 pasos antes y aún encontrar la confirmación incorrecta fácilmente. No está garantizado que funcione, pero ha encontrado el problema la mayor parte del tiempo para mí. ¡Felicitaciones, ahora eres un arqueólogo del código!

Aplastando tus confirmaciones

Anteriormente, trabajé a tiempo completo en un proyecto de código abierto para una organización global y rápidamente aprendí lo importante que es aplastar, o combinar, tus confirmaciones. Creo que es un excelente hábito para adquirir, incluso si su empleador no lo requiere. Es especialmente considerado para otros desarrolladores que necesitarán revisar y editar las funciones que ha creado más adelante.

¿Por qué aplastar tus commits?

• Es más fácil de leer para los colaboradores de su repositorio. Imagínese si tiene una lista de confirmaciones como esta:
  • Implementar control deslizante de carrusel
  • Agregar estilo al carrusel
  • Agregar botones al carrusel
  • Solucionar problema extraño en IE con carrusel
  • Ajustar márgenes en carrusel

  Es mucho más fácil agruparlos en una sola confirmación que diga "Agregar carrusel a la página de inicio".

• Lo alienta a mantener sus mensajes de compromiso comprensibles y relevantes si cada vez que realiza una solicitud de extracción, tiene que agrupar sus compromisos en uno. ¿Cuántas veces ha visto un compromiso titulado "WIP", "corrección de errores para la página de inicio de sesión" o "corregir error tipográfico"? Es importante tener nombres de confirmación relevantes, por ejemplo, "Corrección de errores para la página de inicio de sesión #444: corrección del parpadeo debido a la falta de la función $scope".

Una razón por la que es posible que no desee aplastar sus compromisos podría ser porque está trabajando en una función muy detallada y extensa, y desea mantener un historial diario en caso de que encuentre errores más adelante. Entonces su característica es más fácil de depurar. Sin embargo, cuando verifica su función en su rama principal y está seguro de que está libre de errores, todavía tiene sentido aplastar.

En este escenario, hice cinco confirmaciones, pero todas ellas están relacionadas con una característica. Mis mensajes de confirmación también están demasiado relacionados con el mérito de estar separados; todas mis confirmaciones tienen que ver con diseñar la página para esta nueva función:

 $ git log commit a8fbb81d984a11adc3f72ce27dd0c39ad24403b7 (HEAD -> main) Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 11:16:10 2021 +0100 Import colors commit e2b3ddd5e8b2cb1e61f88350d8571df51d43bee6 Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 11:15:32 2021 +0100 Add new color commit d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 10:50:48 2021 +0100 Change text color commit c005d9ceeefd4a8d4e553e825fa40aaafdac446e Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 09:59:57 2021 +0100 Add CSS styles commit 9e046b7df59cef07820cc90f694fabc666731bd2 Author: Ursula Clarke <[email protected]> Date: Tue Jan 11 09:56:28 2021 +0100 Add second paragraph to page commit 5aff973577d67393d914834e8af4c5d07248d628 Author: Ursula Clarke <[email protected]> Date: Mon Jan 10 16:04:22 2021 +0100 Add colors CSS file and edit background color

También puede usar git merge --squash , pero creo que es más claro usar rebase porque cuando selecciona sus confirmaciones es más fácil ver la descripción de la confirmación. Si ejecuta un git merge --squash , primero debe hacer un restablecimiento completo de sus confirmaciones ( git reset --hard HEAD~1 ), y es fácil confundirse con la cantidad exacta de confirmaciones con las que necesita hacer esto. Encuentro que git rebase es más visual.

Comience ejecutando git rebase -i --root y su editor de texto predeterminado en la línea de comando se abrirá con su lista de confirmaciones:

 pick eb1eb3c Update homepage pick 5aff973 Add colors CSS file and edit background color pick 9e046b7 Add second paragraph to page pick c005d9c Add CSS styles pick d647ac4 Change text color pick e2b3ddd Add new color pick a8fbb81 Import colors # Rebase a8fbb81 onto b862ff2 (7 commands) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # d, drop = remove commit # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out

Es posible que solo desee aplastar sus últimas confirmaciones, en cuyo caso podría ejecutar git rebase -i HEAD~3 y ver sus últimas tres confirmaciones:

 pick eb1eb3c Update homepage pick 5aff973 Add colors CSS file and edit background color pick 9e046b7 Add second paragraph to page # Rebase b862ff2..9e046b7 onto b862ff2 (3 commands) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # d, drop = remove commit # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out

Ahora podemos aplastar todas las confirmaciones en la primera confirmación como se muestra a continuación.

 pick eb1eb3c Update homepage squash 5aff973 Add colors CSS file and edit background color squash 9e046b7 Add second paragraph to page # Rebase b862ff2..9e046b7 onto b862ff2 (3 commands) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # d, drop = remove commit # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out

Cuando guarde el archivo, Git abrirá su mensaje de confirmación para editarlo.

 # This is a combination of 3 commits. # This is the 1st commit message: Update homepage # This is the commit message #2: Add colors CSS file and edit background color # This is the commit message #3: Add second paragraph to page # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # Date: Wed Jan 13 18:31:28 2021 +0100 # # interactive rebase in progress; onto b862ff2 # Last commands done (3 commands done): # squash 5aff973 Add colors CSS file and edit background color # squash 9e046b7 Add second paragraph to page # No commands remaining. # You are currently rebasing branch 'main' on 'b862ff2'. # # Changes to be committed: # new file: .gitignore # new file: css/base.css # new file: css/base.scss # new file: css/colors.css # new file: css/colors.css.map # new file: css/colors.scss # new file: css/common.css # new file: css/common.scss # new file: index.html #

Mientras hacemos la reorganización, también podemos editar la descripción de la confirmación para que sea más fácil de leer.

 Implement new design for homepage. Add .gitignore file for Sass folder. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. #

Guarde este archivo nuevamente y ¡listo! Cuando echamos otro vistazo al registro de Git, podemos ver que solo hay una confirmación limpia.

 [detached HEAD 574ec7e] Implement new design for homepage. Add .gitignore file for Sass folder. Date: Wed Jan 13 18:31:28 2021 +0100 10 files changed, 215 insertions(+) create mode 100644 .gitignore create mode 100644 css/base.css create mode 100644 css/base.scss create mode 100644 css/colors.css create mode 100644 css/colors.css.map create mode 100644 css/colors.scss create mode 100644 css/common.css create mode 100644 css/common.scss create mode 100644 index.html create mode 100644 verylargefile.txt Successfully rebased and updated refs/heads/main. $ git log commit 574ec7e5d7d7a96427e049cad9806cdef724aedd (HEAD -> main) Author: Ursula Clarke <[email protected]> Date: Wed Jan 13 18:31:28 2021 +0100 Implement new design for homepage. Add .gitignore file for Sass folder.

Git Rebase

Los desarrolladores suelen dudar en usar git rebase porque saben que se puede usar un rebase para eliminar archivos de forma permanente de su base de código.

Como vimos anteriormente, git rebase se puede usar para mantener su código y ordenarlo, así como para eliminarlo, pero ¿qué sucede si realmente desea eliminar un archivo del historial de forma permanente?

Una vez presencié un escenario en el que un miembro de nuestro equipo de desarrollo había enviado accidentalmente un archivo muy grande a la base de código. Era parte de una rama mucho más grande, por lo que el archivo grande pasó desapercibido en la revisión del código y se registró por error en la rama principal. Esto se convirtió en un problema cada vez que alguien quería volver a clonar el repositorio: ¡la descarga tardó mucho tiempo! Y por supuesto, el expediente en cuestión era innecesario. No habría sido un problema si el archivo fuera el último compromiso con la rama principal; en ese caso, podría ejecutar un restablecimiento completo ( git reset --hard HEAD~1 ) y forzar la inserción de la rama.

Del mismo modo, si el archivo fue el único cambio en una confirmación dada, podría eliminar toda la confirmación ejecutando git reset --hard <commit-id> . Sin embargo, en nuestro escenario, el archivo grande se comprometió junto con otro código que queríamos mantener en el historial, como la penúltima confirmación.

Una vez que encuentre el compromiso problemático, verifíquelo usando git checkout y el hash de compromiso:

 $ git checkout ce861e4c6989a118aade031020fd936bd28d535b Note: checking out 'ce861e4c6989a118aade031020fd936bd28d535b'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at ce861e4 Add CSS styles

Elimine el archivo o edite su código y deje el código (o los archivos) que desea conservar intactos.

 $ rm verylargefile.txt $ git status HEAD detached at ce861e4 Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: verylargefile.txt no changes added to commit (use "git add" and/or "git commit -a")

Asegúrese de ejecutar git add -A para que su archivo eliminado se organice y Git sepa cómo eliminarlo. Ahora ejecute git commit --amend -v y Git le pedirá que edite su mensaje de confirmación.

Después de esto, ejecuta git rebase --onto HEAD <commit-id> main . Aquí es donde podría encontrar algunos conflictos de combinación, lo que significa que hay un conflicto entre su nueva confirmación y el código anterior. Git te pedirá que resuelvas el conflicto:

 $ git add -A $ git status HEAD detached at ce861e4 Changes to be committed: (use "git reset HEAD <file>..." to unstage) deleted: verylargefile.txt $ git commit --amend -v [detached HEAD 7c9516a] Add CSS styles Date: Thu Jan 14 14:43:54 2021 +0100 3 files changed, 9 insertions(+), 2 deletions(-) create mode 100644 css/common.css.map delete mode 100644 verylargefile.txt $ git status HEAD detached from ce861e4 nothing to commit, working tree clean $ git rebase --onto HEAD ce861e4 First, rewinding head to replay your work on top of it... Fast-forwarded HEAD to HEAD.

Si abre el archivo en su editor de texto, verá que Git ha marcado dos versiones del archivo de índice. Simplemente necesita eliminar uno o editar uno para mantener los cambios que desee.

 <p> Toptal was created by engineers. We are entrepreneurs, all passionate about working with top tech talent and exciting companies from all over the world. </p> <<<<<<< HEAD <p> Toptal connects the top 3% of freelance talent all over the world. </p> </main> </body> </html> ======= </main> </body> </html> >>>>>>> Add index file

El código entre <<<<<<< HEAD y la línea de signos de igual es una versión, y el código entre los signos de igual y >>>>>>> Add index file es la versión de la confirmación "Agregar archivo de índice" . Entonces puede ver que una versión tiene el párrafo adicional de "Toptal conecta el 3% superior de talento independiente en todo el mundo", mientras que la otra no.

Guarde su archivo editado y ejecute git add filename seguido de git rebase --continue . Si no hay cambios, también puede ejecutar git rebase --skip . Puede llevar un tiempo pasar por el reajuste si hubo muchas confirmaciones entre su confirmación de "archivo grande" y la última confirmación en main.

Sea paciente, y si está en un equipo grande, ¡asegúrese de obtener una segunda opinión! Es especialmente importante consultar con la(s) persona(s) que escribieron la(s) confirmación(es) que está fusionando, si es posible.

Recuerde que los cambios de combinación son relevantes para la confirmación específica en el historial y no para los cambios más actualizados. Es decir, si está editando una confirmación de cuando el texto de su sitio era Arial y ahora es Verdana, aún debe mantener esa confirmación con el historial de Arial como fuente.

Tenga en cuenta también que si Git ve un espacio o un carácter de final de línea, puede causar un conflicto de fusión, ¡así que tenga cuidado!

Más que solo comprometerse y tirar

Git es más poderoso de lo que muchos desarrolladores piensan. Si está presentando a un novato, asegúrese de darle algunos consejos sobre estas características invaluables. Hace que el flujo de trabajo sea más eficiente.

¿Quieres saber más sobre Git? Eche un vistazo a la página de consejos y prácticas de Git de Toptal.