Ramas en Git

Ya sabemos cómo trabajar con repositorios locales pero, lo cierto, es que hasta ahora hemos trabajado de forma lineal, sin ningún tipo de ramificación, en el que simplemente hemos ido haciendo cambios, grabándolos y luego subiéndolos a nuestro repositorio remoto.

Aunque esto ya tiene suficiente utilidad, Git ofrece mucho más que eso. Ofrece la posibilidad de crear ramas. Una rama es una versión del repositorio que se crea a partir de un commit.

Un ejemplo sencillo son las ramas que se crean a partir de la rama principal. A estas ramas puedes hacerles commits y, más adelante, puedes decidir volver a fusionarla, o no, con la rama principal para que adopte los cambios.

El nombre deramapuede llevar a la confusiónpor la comparación con un árbol. Aunque es cierto que la creación de ramasse parecea las partes que nacen de un troco… en un árbol real éstas nunca vuelven a unirse al tronco. Esto es diferente a lasramas de Git, que tras divergir, se pueden volver a unir al tronco para que fusione sus cambios. En ese aspecto, la creación de ramas es más similar a una salida de una autopista que, más adelante, puede volver a llevarte a la misma vía

original.

Empezamos con las ramas

La creación de ramasnos permite el trabajo en paralelosobre una misma base de código o, dicho de otra forma, una rama representa una línea completamente independiente de desarrollo.

Al grabar cambios concommitsen una rama, se genera una bifurcación en el historial de cambios del proyecto. Estos cambios pueden ser más adelante integrados en otra rama (normalmente la rama principal) o se puede eliminar la rama y dejar los cambios sin efecto.

En este ejemplo hemos creado dos ramas. La de arriba nos ha servido para probar alguna cosa y finalmente no la fusionamos a la rama principal. La de abajo se fusiona a la rama main tras grabar dos commits

Dominar el uso de ramas es esencial para trabajar con Git. Como verás más adelante existen algunas estrategias de trabajo que las usan constantemente. El trabajo en paralelo es clave y, por eso, la mayoría de personas y compañías las usan en su día a día.

Creando nuestra primera rama

El comando git branchnos permite crear, listar, eliminar y renombrar ramas. Al crear una rama, para movernos a ella, tendremos que usar otro comando:git switch.

# creamos la rama mi-primera-rama
$ git branch mi-primera-rama

# cambiamos a la rama mi-primera-rama
$ git switch mi-primera-rama
Switched to branch 'mi-primera-rama'

Si quieres hacer los dos pasos a la vez, puedes usar el comando git switch -c mi-primera-rama. Esto creará la rama y te llevará a ella con un sólo comando. Ten en cuenta que, si el nombre de la rama ya existe, recibirás un error:

# creamos la rama mi-primera-rama
$ git switch -c mi-primera-rama

# intentamos crear una rama con el mismo nombre
$ git switch -c mi-primera-rama
fatal: A branch named 'mi-primera-rama' already exists.

Para poder crear una rama debes, al menos, tener un commit en el repositorio. Si ejecutas git inity lo primero que intentas es crear una rama con git branchverás que recibes un error. Tiene sentido. ¿Cómo se podría crear una rama si no existe ningún tronco del que sostenerla?

git checkout, el comando que hacía demasiadas cosas

Si ya sabías algo de Git seguramente te estés preguntando… ¿Por qué no he usado git checkoutpara crear y cambiar entre ramas? Es tan sencillo como usar un simple comando:

# crea la rama mi-primera-rama

$ git checkout -b mi-primera-rama
Switched to a new branch 'mi-primera-rama'

Sin embargo, desde agosto de 2019 el comandogitincluye dos nuevos sub-comandos git switchy git restore¹⁷. La idea era separar las responsabilidades de git checkout en varios comandos. Y, personalmente, considero que tiene bastante sentido.

Revisando la documentación de git checkout, podemos ver que git checkout cambiaentreramasyrestauraeldirectoriodetrabajo. Podríamos entrar en un debate sobre si realmente esto siguela filosofía Unix¹⁸de hacer que un programa haga una cosa y lo haga bien… (y para no dejarte con la intriga, yo personalmente creo que no lo cumple).

Fue en 2005 queun commit¹⁹hizo que git checkoutpasase a ser un comando más complejo de lo que había sido históricamente. Antes, simplemente servía para manejar ramas.

Por compatibilidad, obviamente, git checkoutno puede volver a su estado anterior, por lo que desde Git han decidido añadir los dos comandos git switchy git restore, como comentaba antes, para subsanar esto.

Ahora, git checkout no va a ir a ningún sitio. Si ya tienes comodidad trabajando con este comando, puedes seguir haciéndolo. Aún así, te recomiendo que pruebes a usar los nuevos para habituarte. Creo, sinceramente, que son más fáciles de entender y seguramente las personas a las que les enseñes a trabajar con Git te lo agradecerán.

Si nunca has oido hablar de git checkout, creo que está bien aprenderlo y entenderlo pero priorizaría a usar los nuevos comandos como mis principales.

Listando las ramas disponibles

Ahora que ya sabemos crear ramas es el momento de saber qué ramas tenemos disponibles en nuestro repositorio.

Por ahora estamos viendo las ramas disponibles a nivel local. Más adelante veremos que también podemos ver las ramas disponibles a nivel remoto que otras personas están trabajando en el mismo proyecto han dejado allí.

Para mostrar una lista de todas las ramas disponibles localmente, sólo tienes que ejecutar el comando git branch:

$ git branch

feat/remove-husky-usage
feat/remove-not-needed-deps
feat/subscribe-to-use-case-without-decorators
* feat/sui-bundler-webpack-5
master

Verás que una de las ramas tiene, al principio, unasterisco. Esto significa que actualmente te encuentras en esa rama.

Normalmente las terminales actuales te indican en qué rama te encuentras sin necesidad de ejecutar un comando pero si necesitas averiguarlo rápidamente, puedes añadir un parámetro al comando para que te indique en qué rama estás actualmente.

$ git branch --show-current
feat/upgrade-sui-lint-dependencies

Consigue la lista de las ramas más recientes

Si tienes muchas ramas en tus proyectos locales es posible que te cueste encontrar fácilmente las ramas más recientes.

Para mejorar esto, puedes usar el parámetro—sorty usar el valorcommitterdate para ordenar las ramas por fecha de creación.

$ git branch --sort=-committerdate

* feat/sui-bundler-webpack-5
master
feat/migrate-to-webpack5-and-karma-6
feat/bump-karma-webpack-version
feat/upgrade-to-latest-stylelint
feat/upgrade-sui-lint-dependencies

Trabajando con ramas

Ahora que ya sabemos crear y mostrar las ramas disponibles, es el momento de trabajar con ellas. Vamos a ver paso a paso, con comandos y de forma ilustrada, el estado en el que se encuentra en cada momento.

Pongamos que nuestra rama principal es master:

# empezamos en la rama principal master
$ git branch --show-current
master

# grabamos un commit en la rama master
$ git commit -am "first commit"

Es nuestro primer commit en el repositorio. Fíjate que el puntero HEAD irá cambiando conforme nos vayamos “moviendo”

Ahora vamos a crear una rama llamadamy-branch, donde vamos a trabajar en una nueva característica para nuestra aplicación:

# creamos nuestra primera rama y

$ git switch -c my-branch
Switched to a new branch 'my-branch'

Como podemos ver, el puntero HEAD ahora mismo está en la rama master y my-branch, ya que ambas apuntan al mismo commit

Vamos a empezar a trabajar en esta rama. Para ello, vamos a modificar el fichero index.jsy vamos a grabar los cambios en esta rama.

# estamos en la rama my-branch
$ git branch --show-current
my-branch

# modificamos los ficheros necesarios

$ code index.js

# si el fichero index.js es nuevo

# vamos a grabar el commit en la rama
$ git commit -am "branch commit"
[my-branch afaf06b] first branch commit
1 file changed, 5 insertions(+), 0 deletions(-)

Elcommitseañadeenlaramamy-branch.el HEADapuntaaestecommityvemoscomoeste commit tiene una flecha que enlaza con el de master, ya que es el que fue el origen

Ops! Nos hemos dado cuenta que enmasterhay un pequeño bug. Vamos a tener que cambiar a esa rama y hacer un commit para solucionarlo.

# cambiamos a la rama master
$ git switch master

# editamos el fichero en el editor...
$ code file-with-bug.js

# grabamos el commit en la rama master
$ git commit -am "bug fixed"

Ahora vemos como las ramas empiezan a divergir. Ambas ramas comparten el commit inicial, pero la rama master ha ido por un sitio y la rama my-branch por otro

Vaya, pensábamos que ya lo teníamos arreglado. Pero hemos encontrado otro pequeño bug en la rama principal que debemos arreglar.

# hay que editar otro fichero para arreglarlo del todo
$ code another-file-with-bug.js

# grabamos el commit en la rama master
$ git commit -am "another bug fixed"

El puntero HEAD apunta al último commit de la rama actual, que es master. Y vemos que este commit sólo se queda en la rama master

Con este pequeño ejemplo hemos visto como podemos usar las ramas para trabajar en un mismo proyecto en funcionalidades distintas e ir cambiando con git switch entre una rama y otra.

Pero… ¿qué gracia tiene hacer esto? ¿No llegan nunca las ramas a encontrarse? Claro que sí. Normalmente, creamos ramas para trabajar en una función o en una característica de nuestra aplicación para, luego, fusionarlas en otras ramas.

¿Quieres seguir trabajando en visualizar cómo quedaría el repositorio al trabajar con ramas? Pues pruebaVisualizing Git. Vas a poder ir añadiendo comandos de Git y podrás comprobar en tiempo real cómo va quedando el repositorio. https://git-school.github.io/visualizing-git/

Fusionando ramas

Las bifurcaciones de código que hemos creado en forma de ramas tendrándos destinos: acabar en el olvido para no terminar en ningún lado o ser fusionada en otra rama.

Cuando hablamos de fusiónnosreferimosaqueloscambiosquehemosrealizado enlaramaseintegranenotrarama, de forma que el código que habíamos generado en la nueva rama se asimila en otra.

Aunque normalmente este tipo de fusión ocurre de una rama a la rama principal, debes tener en cuenta que en realidad podemos fusionar una rama con cualquier otra rama. Esto puede ser útil para asimilar cambios que alguien del equipo esté haciendo o un fix que todavía no se encuentre en la rama principal.

git merge, el comando para fusionar ramas

Hemos estado trabajando antes en la ramamy-branchy ya estamos preparados para llevar todos esos cambios a la rama principal. ¿Cómo podemos conseguirlo? Con el comando git merge.

Este comando nos permite incorporar los cambios de una rama a la rama en la que nos encontramos en ese momento. Por ejemplo, si estamos actualmente en la rama mainy hacemos un git merge my-branchharemos que la ramamainincorpore y fusione los cambios que había en la ramamy-branch.

Si tienes cambios sin guardar en tu rama actual, Git no te permitirá fusionar nada hasta que los guardes, hagas commit o los elimines. ¡Tenlo en cuenta!

# nos aseguramos que estamos en la rama destino
$ git branch --show-current
main

# vamos a incorporar en main los cambios de my-branch
$ git merge my-branch

Si ahora ejecutas un git logverás que el último commit incluye la palabraMerge … Este commit justamente incluye todos los cambios que se habían realizado en la ramamy-branch. Git hareplicadoesos cambios en la ramamainy los ha fusionado.

Al ejecutar el comando git merge, se crea un nuevo commit que incluye todos los cambios de la rama de origen a la rama en la que nos encontramos ahora

Tipos de fusión

Git tiene varios tipos de fusión que se usarán dependiendo de la situación de las ramas o de los parámetros que le pasemos. Es importante conocerlas para saber qué está pasando cuando hacemos un git merge.

En el anterior caso hemos visto como Git ha creado un nuevo commitMerge …que incluye todos los cambios de la rama de origen a la rama en la que nos encontramos ahora. Esto se conoce como merge commit. Esto es lo que ocurre por defecto.

Pero existen otras posibilidades:

Fast-forward

Cuando la rama de origen está por delante de la rama destino, Git simplemente mueve el puntero de la rama destino al último commit de la rama de origen. Esto se conoce comofast-forward.

Lo que ocurrirá es que la rama destino pasará a tener todos los commits que tenía la rama de origen y se dibujará como una línea recta sin bifurcaciones.

Para que esto ocurra:

La rama de origen comparte el historial de commits de la rama destino.
La rama de origen tiene por delante commits que no tiene la de destino.
La rama destino no debe tener ningún commit que no esté en la rama de origen.

# vamos a la rama donde queremos fusionar cambios
$ git switch main
# traemos los cambios de feature-branch

$ git merge --ff-only feature-branch

Si la rama a fusionar está por delante de la rama destino y comparten el historial de commits, Git hará un fast-forward

Con ese comando, si el fast-forward no es posible, Git no lo hará y te mostrará un mensaje de error.

Si elfast-fowardha sido posible, verás que la rama destino se ha movido al último commit de la rama de origen y que no ha creado el commit deMerge …, ya que no ha sido necesario.

git mergeusará este tipo de merge automáticamente siempre que sea posible. Si quieres que Git siempre use elmergetipofast-forward, puedes configurarlo con git config —global merge.ff only. Si no es posible, Git te mostrará un error.

No fast-forward

Este tipo de fusión se usa cuando la rama de origen no está por delante de la rama destino. Dicho de otra forma, cuando la rama que va a recibir los cambios tiene commits distintos a la rama que queremos fusionar.

En este caso, Git crea un nuevo commit que incluye todos los cambios de la rama de origen a la rama destino. Esto se conoce comono fast-forwardotrue merge.

# vamos a la rama donde queremos fusionar cambios
$ git switch main

# creamos la rama feature
$ git switch -c feature

# hacemos un commit (después de hacer los cambios)
$ git commit -m "commit 1 feature"

# volvemos a main y hacemos un commit
$ git switch main
$ git commit -m "commit 1 main"

# hacemos el merge de feature sin fast-forward
$ git merge feature --no-ff

Si no hacemos un fast forward, Git nos crea un commit que reproducirá los cambios realizados en la rama feature desde que divergió de main.

Squash

Este tipo de fusión de cambios hace la fusión y junta todos los commits de la rama de origen en un solo commit que debe ser confirmado. Esto se conoce comosquash.

# creamos la rama feature desde main
$ git switch - c feature

# hacemos tres commits (después de hacer los cambios)
$ git commit -m "commit 1"
$ git commit -m "commit 2"
$ git commit -m "commit 3"

# vamos a la rama donde queremos fusionar cambios
$ git switch main

# traemos los cambios de feature

# usando --squash para que haga squash
$ git merge feature --squash

$ git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: index.js
new file: module.js
new file: styles.css

# hacemos commit de los cambios
$ git commit -m "Merge feature"

Siusamos –squash, Git agrupa loscommits que vamos a fusionar ynos deja los cambios preparados para hacer commit

Como ves, al usar git merge —squashno nos crea un commit deMerge …sino que nos deja los cambios preparados para hacer commit. Esto es porque Git no sabe

qué mensaje de commit ponerle y, por tanto, deja que tú lo hagas.

Modificando el mensaje de Merge commit

Por defecto, al ejecutar el git mergey según el tipo de fusión, Git crea un commit automáticamente y lo grabado. Sin embargo, es posible que quieras evitar esto. Tienes dos opciones para que no lo haga y, así, modificar el mensaje del commit o hacer otras comprobaciones o cambios antes:

# Abre el editor antes de hacer el commit
$ git merge --edit

# Evita que haga commit automáticamente

$ git merge --no-commit

Aunque puede ser útil en algunos casos muy concretos… lo normal es simplemente dejar que Git haga el commit automáticamente.

Resolviendo conflictos

Aunque Git hace un trabajo magnífico a la hora de fusionar ramas, existen situaciones que pueden dar problemas. ¿Qué pasa si al querer fusionar dos ramas, la de destino ha realizado cambios en las mismas líneas de un fichero que los que queremos fusionar? Tendríamosconflictos.

Un conflicto es una situación en la que Git no es capaz de determinar qué cambio es el que tiene que prevaleceruna vez ocurra la fusión y, por lo tanto, requiere que el usuario lo resuelva.

Dada la naturaleza de sistema distribuido, es normal que a veces ocurran conflictos al intentar fusionar dos ramas en Git. ¿Cómo iba a saber Git qué cambio es más importante que otro?

Que exista un conflicto no es malo. Puede ser hasta normal, especialmente cuando muchas personas están trabajando en un mismo proyecto y algunos ficheros son continuamente modificados. Si se convierte en algo demasiado frecuentemente es posible que se quiera evitar…

Creando nuestro primer conflicto

Vamos a ver cómo pueden surgir los conflictos… ¡generando uno! Para ello vamos a crear un repositorio desde cero con un ficheroindex.htmlcon un contenido inicial:

$ mkdir git-conflict-test
$ cdgit-conflict-test
$ git init.
Initialized empty Git repository in ~/git-conflict-test/.git/

# con este comando introducimos el contenido inicial al fichero index.h\
tml
$ echo "<p>This is our initial content</p>"> index.html
$ git add index.html
$ git commit -m "Add initial content"
[main (root-commit) 0d26ac1] Add initial content
1 file changed, 1 insertion(+)
create mode 100644 index.html

Ahora, vamos a crear una nueva rama llamadachangesdonde haremos algunos cambios que, después, entrarán en conflicto.

$ git switch -c changes
Switched to a new branch 'changes'

$ echo "<p>Completely different content</p>" > index.html
$ git commit -am "Edit index.html content to cause conflicts"
[changes e607927] Edit index.html content to cause conflicts
1 file changed, 1 insertion(+), 1 deletion(-)

Con esto hemos creado una nueva rama llamadachanges, hemos cambiado a ella y hemos cambiado completamente el contenido del ficheroindex.html. Hasta aquí todo bien pero… ¿Qué pasa si antes de fusionar esta rama volvemos a la rama principal y hacemos otros cambios como el siguiente?

$ git switch main
Switched to branch 'main'
# Al usar >> lo que hacemos es añadir el contenido al final del fichero
$ echo "<p>New content to the file</p>" >> index.html
$ git commit -am "Append new content to the index file"
[main 4056b12] Append new content to the index file
1 file changed, 1 insertion(+)

En este punto hemos evolucionado el mismo archivoindex.htmltanto en la rama principal como en la ramachanges. ¿Qué va a pasar cuando intentemos fusionar los cambios dechangesa main? Veamos.

# Nos aseguramos que estamos en la rama main
$ git branch --show-current
main

# Fusionamos los cambios de la rama changes en main
$ git merge changes
Auto-merging index.html
CONFLICT(content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
# ¡Vaya, tenemos conflictos!

Es normal que hayan ocurrido conflictos. Al intentar traer a la rama principal los cambios de la ramachanges, Git no ha sido capaz de determinar qué cambios son los que deben prevalecer.

En esta situación, si ejecutamos el comando git statuspodremos ver que el fichero index.htmlestá en conflicto.

$ git status
On branch main
You have unmerged paths.
(fix conflicts and run "git commit ")
(use "git merge --abort" to abort the merge)

Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.html

no changes added to commit (use "git add "and/or "git commit -a ")

Como ves, aquí nos da dos opciones: podemos abortar completamente la fusión ejecutando el comando git merge —aborto podemos intentar solucionar el conflicto y continuar con la fusión con un commit

Solucionando conflictos

Esta situación es posible que la encontremos frecuentemente en muchos proyectos. Por ello, hay que evitar alarmarse. Ahora que sabemos por qué ocurren los conflictos, entendemos quenoesquehayaalgomal, esquesimplementedebemos resolver cómo fusionar estos cambios.

Para poder resolver el conflicto, hay que ver el contenido del archivoindex.htmly entender qué es lo que hay que hacer para que la fusión sea correcta.

$ git diff
++<<<<<<< HEAD
+<p>This is our initial content</p>
+<p>New content to the file</p>
++=======
+ <p>Completely different content</p>
++>>>>>>> changes

Como ves el contenido de nuestro archivo tiene unas anotaciones un tanto extrañas que nosotros no hemos incluido en ningún momento. Ha sido Git que, al hacer la fusión, ha intentado separar el conflicto en dos partes.

Por un lado tenemos el contenido del archivo que se encontraba en la rama principal y que está limitado por<<<<<<< HEADy=======y por otro lado tenemos el contenido de la ramachangesque está limitado por>>>>>>> changes (Incoming Change).

Dicho de otra forma, arriba tenemos el contenido que ya existía en la rama de destino de la fusión (la rama main) y debajo de la línea divisoría=======tenemos el contenido de la rama de origen (la ramachanges), que queremos incorporar a la rama main.

Al resolver, deberemos decidir entre:

Nos quedamos con los cambios de la rama main
Nos quedamos con los cambios que vienen de la ramachanges
Modificamos los cambios para hacer una fusión personalizada

Por desgracia, a día de hoy, gitno tiene un comando para resolver conflictos desde la línea de comandos. Para ello puedes usar una aplicación visual o editor de código

comoVisual Studio Codeque, además, te dará una ayuda visual con enlaces directos para resolver y elegir el cambio con el que te quieres quedar.

El editor Visual Studio Code ofrece una experiencia muy buena a la hora de lidiar con conflictos y te ofrece accesos directos para resolverlos

La otra opción es, manualmente, modificarelficheroparaquedarteconelcambio que quieres. En nuestro caso vamos a conseguir que se mantengan tanto los cambios que teníamos en la rama principal como los que queremos aplicar, para ello simplementeeliminamos todas las anotaciones que ha hecho Gity la dejamos así:

$ git diff

diff --cc index.html
index 9e684df,ab7339b..0000000
--- a/index.html
+++ b/index.html
@@@ -1,2 -1,1 +1,3 @@@
+<p>This is our initial content</p>
+<p>New content to the file</p>
+ <p>Completely different content</p>

Ahora ya podemos fusionar los cambios de la ramachangesa la rama main, para ello vamos a ver el estado en el que está, luego añadimos a la fase destaginglos cambios y hacemos commit.

$ git status
On branch main
You have unmerged paths.
(fix conflicts and run "git commit ")
(use "git merge --abort" to abort the merge)

Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.html

# añadimos el archivo al área temporal
$ git add index.html
# y hacemos commit
$ git commit -m "Merge changes branch to main"
[main 2c72238] Merge changes branch to main

# revisamos otra vez el estado para ver

$ git status
On branch main
nothing to commit, working tree clean

Hora de podar: Eliminando ramas

Después de fusionar una rama en otra rama (normalmente, la rama principal) es posible que quieras eliminarla para no dejarla suelta. Para ello puedes usar el comando git branchcon el parámetro—deleteo, de forma corta,-d.

# borramos la rama llamada "mi-primera-rama"
$ git branch --delete mi-primera-rama
Deleted branch mi-primera-rama (was 7c60765).

Si la rama ya ha sido fusionada previamente, entonces todo habrá ido correctamente y nos habrá devuelto un mensaje similar al que tienes arriba… Sin embargo, si la rama no la habías fusionado (merge) previamente, entonces te devolverá un error:

error: The branch ‘mi-primera-rama’ is not fully merged. If you are sure you want to delete it, run ‘git branch -D mi-primera-ra\ ma’.

Creo que el mensaje nos ha devuelto unspoiler, directamente. Y es que en el caso que quieras borrar una rama que no ha sido fusionada previamente, deberás usar el parámetro-D. Este parámetro le indica a Git que queremos borrar la rama sin importar si ha sido fusionada o no.

# borramos la rama llamada "mi-primera-rama"
$ git branch -D mi-primera-rama
Deleted branch mi-primera-rama (was 7c60765).

¿Por qué hace esta comprobación Git? Es sencillo. Borrar una rama que no ha sido fusionada… puede hacerte perder muchas horas de trabajo. Asegúrate de que estás seguro de querer borrarla antes de hacerlo.

¿Cómo eliminar ramas de mi repositorio local que ya no

se usan?

Normalmente la idea detrás de las ramas que creamos es que sean fusionadas con otra rama y, por lo tanto, desaparezcan. Cuando su fusión ocurre en un repositorio remoto… ¿qué pasa con los repositorios locales que habían creado esas ramas? Pues que quedan ahí, descolgadas del repositorio remoto.

Estas ramas se pueden, en la jerga de Git, podar(en inglésprune). Para ver qué ramas serían podadas de las que tenemos en local, y que ya no son necesarias porque en el repositorio remoto ya han sido fusionadas, ejecutamos:

# el comando mira qué ramas locales han dejado

$ git remote prune origin --dry-run

Pruning origin
URL: git@github.com:tu-usuario/tu-usuario.dev.git
* [would prune]origin/feat/add-lighthouse-ci
* [would prune]origin/imgbot
* [would prune]origin/newsletter

La opción—dry-runnos permite ver qué ramas se eliminarían, pero no las eliminamos. Es un concepto que se utiliza mucho en programación y en la línea de comandos para ver qué resultado tendría una acción sin realizarla. De esta forma, podemos revisar antes las consecuencias que tendría la ejecución.

Ahora que ya hemos visto que es lo que se eliminaría y tenemos claro que sea así, podemos ejecutar el comando git remote prunepara eliminar todas las ramas que no sean necesarias:

# ejecutamos el mismo comando que antes

$ git remote prune origin

Pruning origin
URL: git@github.com:tu-usuario/tu-usuario.dev.git
* [pruned] origin/feat/add-lighthouse-ci
* [pruned] origin/imgbot
* [pruned] origin/newsletter