DEV Community: Claudio Sánchez

Git: how to salir de esta, repositorios remotos

Claudio Sánchez — Sun, 26 Sep 2021 09:26:55 +0000

How to

Introducción
Trastear con repositorios remotos
Problemas al subir una rama
Modificar algo en el repositorio remoto
Git pull, ese comando problemático
Renombrar una rama
Mantener el entorno limpio: cuando las ramas no dejan ver el bosque
Modificar un tag

Introducción

Un repositorio de código, dentro del contexto de los sistema de control de versiones, es un sistema para almacenar código y metadatos, como pueden ser el histórico de los archivos.

Git es un sistema de control de versiones distribuido, en el que cada repositorio guarda una copia completa del código y los metadatos, pudiendo funcionar de manera independiente; en contraposición están los sistemas centralizados, en los que existe un único repositorio de código y los clientes se comunican con él para obtener o subir código, pero en ningún caso tienen una copia de los metadatos.

Se denomina "flujo de trabajo" al cómo colaboran entre sí los repositorios de un sistema de control de versiones distribuido. El más común de ellos es el "flujo de trabajo centralizado", en el que hay un repositorio central o de referencia, por ejemplo un repositorio en Bitbucket o GitHub; los desarrolladores se clonan ese repositorio en su local, obteniendo así un repositorio privado sobre el que pueden trabajar; hacen cambios en su repositorio local, como por ejemplo desarrollador una nueva feature, y envian esos cambios al repositorio central; y actualizan el repositorio privado con los cambios que otros desarrolladores han enviado al repositorio central.

El tener un "sistema de control de versiones distribuido" y acabar usando un "flujo de trabajo centralizado" puede sonar contradictorio o exagerado ¿Por qué complicarse? ¿Por qué no usar simplemente un sistema de control de versiones centralizado como SVN?
En un sistema de control de versiones centralizado cualquier operación, desde hacer un nuevo commit a consultar el log, implica comunicaciones con el servidor donde está alojado el repositorio, lo cual es mucho más lento que consultando una copia local como en Git; además de la lentitud, una perdida de conexión con el servidor central implica no poder ejecutar ningún comando; y la gestión de conflictos es más complicada, ya que habrá que resolverlos sobre cambios que todavía no se han podido commitear.
Personalmente he trabajado con SVN y Git y me quedo sin ninguna duda con Git, pero como todo la elección dependerá de gustos y necesidades.

Adicionalmente, un sistema de control de versiones distribuido permite evolucionar el flujo de trabajo dependiendo de como evolucione o crezca el proyecto; por poner un ejemplo, en el kernel de Linux usan el "flujo de trabajo dictador y tenientes".

Tras hacer git clone <url repositorio> en el repositorio recién clonado habrá dos conjuntos de ramas: ramas locales y ramas remotas,

En un GUI	En consola

Las ramas remotas son referencias a ramas que existen en el repositorio remoto que se ha clonado, al que por defecto se le da el nombre de origin, y que se actualizan con git fetch si ha habido cambios en el repositorio remoto, o cuando este acepta los cambios que se le proponen al hacer git push.
Un ejemplo de rama remota sería origin/master, y haría referencia a la rama master en el repositorio remoto con nombre origin.
Una rama remota puede ser el "upstream" de una rama local, pudiéndose entender "lo que hay rio arriba" como que la rama local mira o sigue a la rama remota: cuando se hace git pull se intenta actualizar la rama local con lo que haya en su upstream; cuando se hace git push se intenta actualizar el upstream con los contenidos de la rama local. Y en ambos casos digo intentar porqué si la rama local ha divergido respecto del upstream, sera necesarias algunas acciones que se irán viendo a lo largo del post.

A la hora de visualizarlo, se puede hacer igual que con las ramas locales, solo que ahora habrá unas cuantas ramas más.
Con un GUI

O por consola

$ git log --graph --format='%C(auto)%h %s%n%C(auto)%d%n' --all

Las ramas de los repositorios remotos añaden un nuevo nivel de complejidad a la gestión de las ramas: hay ramas como pippin-merry que han adelantado a su upstream origin/pippin-merry; ramas como aragorn-legolas-gimli que se han quedado atrás respecto a su upstream origin/pippin-merry; y ramas como master que han divergido respecto a su upstream origin/master; también habrá ramas remotas que no serán seguidas por ninguna rama local o ramas locales que todavía no se han subido al repositorio remoto y que no tengan su equivalente en origin.

Y para terminar la introducción, algo muy importante:

🚨 No hay que editar nada que ya este en el repositorio remoto y que este siendo usado por otros desarrolladores, ya que se puede liar parda.

Imagina que:

Mortadelo hace git push a master con un commit que tiene un bug.
Filemón se actualiza su rama con master, obteniendo así el commit con el bug.
Mortadelo se da cuenta de su error, y sin avisar a nadie: borra el commit con el bug de master; intenta hacer git push a master, pero no puede por no se que error extraño; así que hace git push -f.
Filemón integra su rama en master, intenta subirla, y o bien vuelve a añadir a master el commit que Mortadelo había borrado, o bien se encuentra con conflictos y tiene que perder un buen rato en resolverlos.

El tener que usar git push -f (o borrar la rama remota y volver a crearla con commits diferentes) es algo que debe hacer saltar todas las alarmas, y hacer pensar muy mucho si realmente es necesario o hay otras opciones.

Dicho esto, si la rama es tuya, y estas seguro de que nadie más la ha usado ni ha usado ninguno de sus commits, es licito modificar los commits que hagan falta y usar git push -f, porque a todos nos ha pasado que queramos cambiar algo que hemos subido por error.

git push -f es una herramienta más de Git, y si sigue hay después de tantos años por algo será, pero hay que usarla con mucho cuidado.

Trastear con repositorios remotos

Personalmente, como más aprendo sobre las cosas es trasteando con ellas, y cómo más aprendí sobre los repositorios remotos de Git fue creándome un repositorio en local y clonándolo.
En un minuto es posibles tener un área de pruebas donde ver como afectan los comando git push y git pull al repositorio remoto, crear situaciones para probar las cosas, probar cosas antes de aplicarlas al repositorio remoto de verdad, etc.
También se puede crear un repositorio privado en GitHub o similares, pero me parece mucho más rápido y ágil probar en local.

El proceso sería más o menos así

# Creo una carpeta donde poner los repositorios para las pruebas.
~$ mkdir -p sandbox/remotes 
~$ cd sandbox/remotes/

# Creo una carpeta donde creare el repositorio remoto.
~/sandbox/remotes$ mkdir origin
~/sandbox/remotes$ cd origin/
# Inicio el repositorio.
~/sandbox/remotes/origin$ git init
        Inicializado repositorio Git vacío en ~/sandbox/remotes/origin/.git/

# Le añado algún commit.
~/sandbox/remotes/origin$ echo "hola git" > README.md
~/sandbox/remotes/origin$ git add .
~/sandbox/remotes/origin$ git commit -am "creado archivo index.html"
        [master (commit-raíz) 246ceaf] creado archivo README.md
         1 file changed, 1 insertion(+)
         create mode 100644 README.md
# Me voy a otra rama para evitar los problemas del tipo
# "remote: error: Por defecto, actualizar la rama actual 
# en un repositorio no vacío".
# https://stackoverflow.com/a/2933656/1587302
~/sandbox/remotes/origin$ git checkout -b no-editar

# Voy atras.
~/sandbox/remotes/origin$ cd ..

# Clono el repositorio origin en la carpeta local.
~/sandbox/remotes$ git clone origin local 
        Clonando en 'local'...
        hecho.

# Entro en él y veo que tengo un clone de "origin".
~/sandbox/remotes$ cd local/
~/sandbox/remotes$ git checkout master
        Rama 'master' configurada para hacer seguimiento a la rama remota 'master' de 'origin'.
        Cambiado a nueva rama 'master'
~/sandbox/remotes/local$ git status
        En la rama master
        Tu rama está actualizada con 'origin/master'.

        nada para hacer commit, el árbol de trabajo está limpio

~/sandbox/remotes/local$ cat README.md 
        hola git

Problemas al subir una rama

Hago push pero lo cambios no se suben; al intentar hacer push sale un error; hago push pero no pasa nada; etc

Hay varios motivos por los que git push puede dar error:

No se tienen permisos para escribir es un repositorio. Por poner un ejemplo, es posible clonarse cualquier repositorio público de GitHub, pero al hacer git push se obtendrá un error como este remote: Permission to 30-seconds/30-seconds-of-code.git denied to Pepito.
No se tienen permisos para escribir en una rama. Es posible restringir los permisos de escritura a ramas sensibles como master, de tal forma que sólo ciertos usuarios puedan escribir sobre ellas o solo se pueda escribir sobre ellas al darle a Merge en las "Pull request" o "Merge request".
Todavía no existe la rama remota.
La rama local está detrás o no está al día con la rama remota
La rama local ha divergido respecto a la rama remota y no es posible actualizarla.

Para los dos primeros casos habrá que consultar al administrador del repositorio.

En el tercer caso, git push da error porque se le pide actualizar algo que no existe, y la solución es tan simple como crearla siguiendo las instrucciones que da Git en el mensaje de error.
La siguientes veces que se ejecute git push ya no se obtendrá el error, porque ya sabrá que debe actualizar.
Aunque esto es algo que solo suelen experimentar los usuarios de consola, porque muchos muchos GUI por debajo controlan este caso y crean la rama remata si no existe.

# Intento hacer push de una rama que no existe y obtengo un error.
$ git push 
        fatal: La rama actual nueva-feature no tiene una rama upstream.
        Para realizar un push de la rama actual y configurar el remoto como upstream, use

            git push --set-upstream origin nueva-feature

# Así que la creo.
$ git push --set-upstream origin HEAD
        Total 0 (delta 0), reusado 0 (delta 0)
        To ~/sandbox/remotes/origin
         * [new branch]      HEAD -> nueva-feature
        Rama 'nueva-feature' configurada para hacer seguimiento a la rama remota 'nueva-feature' de 'origin'.

$ git status
        En la rama nueva-feature
        Tu rama está actualizada con 'origin/nueva-feature'.

        nada para hacer commit, el árbol de trabajo está limpio

En el ejemplo se utiliza git push --set-upstream origin HEAD para crear la rama en lugar del comando sugerido por Git git push --set-upstream origin nueva-feature.
Es un pequeño atajo no tener que pensar en el nombre de la rama a la hora de crearla.

Respecto a los dos últimos casos, si git push da error, es importante hacer git fetch para actualizar las ramas remotas, porque puede pasar que todo parezca estar en orden al ejecutar git status, pero que no lo este porque otro desarrollador haya hecho cambios en el repositorio remoto desde la última vez se actualizo el repositorio local, y las referencias a las ramas remotas no estén actualizadas.

Si la rama local está detrás de la rama remota no hay cambios que subir, y aunque el mensaje puede ser un poco agresivo es normal que no pase nada.
Si se actualiza la rama seguirá sin pasar nada, pero el mensaje no será tan agresivo.

# Hago push y obtengo un mensaje un poco agresivo
$ git push 
        To ~/sandbox/remotes/origin
         ! [rejected]        master -> master (non-fast-forward)
        error: falló el push de algunas referencias a '~/sandbox/remotes/origin'
        ayuda: Actualizaciones fueron rechazadas porque la punta de tu rama actual está
        ayuda: detrás de su contraparte remota. Integra los cambios remotos (es decir
        ayuda: 'git pull ...') antes de hacer push de nuevo.
        ayuda: Mira 'Note about fast-forwards' en 'git push --help' para más detalles.

# Compruebo el estado y veo que mi rama se ha quedado detras
$ git status
        En la rama master
        Tu rama está detrás de 'origin/master' por 1 commit, y puede ser avanzada rápido.
          (usa "git pull" para actualizar tu rama local)

        nada para hacer commit, el árbol de trabajo está limpio

# Actualizo la rama
$ git pull
        Actualizando 246ceaf..47be068
        Fast-forward
         index.html | 1 +
         1 file changed, 1 insertion(+)

# Y el git push segirá sin hacer nada, aunque el mensaje 
# no es tan agresivo
$ git push 
        Everything up-to-date

Y si la rama remota y la rama local han evolucionado de manera distinta, es que han divergido.

# Compruebo el estado de la rama y veo que está por delante 
# de la rama remota, así que debería poder hacer push.
$ git status
        En la rama master
        Tu rama está adelantada a 'origin/master' por 1 commit.
          (usa "git push" para publicar tus commits locales)

        nada para hacer commit, el árbol de trabajo está limpio

# Pero falla.
$ git push 
        To sandbox/remotes/origin
         ! [rejected]        master -> master (fetch first)
        error: falló el push de algunas referencias a 'sandbox/remotes/origin'
        ayuda: Actualizaciones fueron rechazadas porque el remoto contiene trabajo que
        ayuda: no existe localmente. Esto es causado usualmente por otro repositorio 
        ayuda: realizando push a la misma ref. Quizás quiera integrar primero los cambios
        ayuda: remotos (ej. 'git pull ...') antes de volver a hacer push.
        ayuda: Vea 'Notes about fast-forwards0 en git push --help' para detalles.

# Actualizo las ramas remotas y veo que la rama remota 
# se ha actualizado.
$ git fetch 
        remote: Enumerando objetos: 5, listo.
        remote: Contando objetos: 100% (5/5), listo.
        remote: Total 3 (delta 0), reusado 0 (delta 0)
        Desempaquetando objetos: 100% (3/3), 277 bytes | 277.00 KiB/s, listo.
        Desde sandbox/remotes/origin
           246ceaf..792a7bf  master     -> origin/master

# Intento obtener información más concreta y veo que 
# las ramas han divergido.
$ git status
        En la rama master
        Tu rama y 'origin/master' han divergido,
        y tienen 1 y 1 commits diferentes cada una respectivamente.
          (usa "git pull" para fusionar la rama remota en la tuya)

        nada para hacer commit, el árbol de trabajo está limpio

En el ejemplo se puede ver que la rama local master y la rama remota origin/master partieron de commit creado archivo index.html y que en ambas se han hecho commits.

git push solo funciona cuando los commits que se suben salen del último commit de la rama remota, es decir, se produce un fast forward, en caso contrario falla y habrá que actualizar la rama local con el upstream.

La forma de salir del paso depende de como se integren las ramas en el proyecto:

Si se usan rebases, el comando sería git rebase <upstream>, por ejemplo git rebase origin/master si por ejemplo mi el upstream es origin/master.
Si se usan merges git pull .

Una vez integrada, y si no se da la casualidad de que justo se ha vuelto a actualizar la rama remota entre medias, se podrá hacer git push.

Modificar algo en el repositorio remoto

He visto después de hacer push que el mensaje de un commit tiene una errata; he mergeado la rama que no era y he hecho push; he subido algo por error; me acabo de dar cuenta de que he subido un bug; etc.

Como se vio en la introducción

🚨 No hay que editar nada que ya este en el repositorio remoto y que este siendo usado por otros desarrolladores, ya que se puede liar parda.

Pero ¿quién no la ha cometido errores alguna vez?

Como también se dijo en la introducción, si la rama es tuya, y estas seguro de que nadie más la ha usado ni ha usado ninguno de sus commits, es licito modificar los commits que hagan falta y usar git push -f

$ git commit -am "Hañado titúlo"
        [mi-rama 13c9acf] Hañado titúlo
         1 file changed, 1 insertion(+)

$ git push 
        Enumerando objetos: 5, listo.
        Contando objetos: 100% (5/5), listo.
        Compresión delta usando hasta 12 hilos
        Comprimiendo objetos: 100% (2/2), listo.
        Escribiendo objetos: 100% (3/3), 314 bytes | 314.00 KiB/s, listo.
        Total 3 (delta 0), reusado 0 (delta 0)
        To sandbox/remotes/origin
           207ba5a..13c9acf  mi-rama -> mi-rama

# Me doy cuenta de que he metido algunos errores en el mensaje 
# y los corrijo.
$ git amend -m "Añado título"
        [mi-rama ec27a36] Añado título
         Date: Sat May 8 21:05:27 2021 +0200
         1 file changed, 1 insertion(+)

# Pero el push falla porque he modificado un commit que 
# ya estaba en el repositorio remoto.
$ git push 
        To sandbox/remotes/origin
         ! [rejected]        mi-rama -> mi-rama (non-fast-forward)
        error: falló el push de algunas referencias a 'sandbox/remotes/origin'
        ayuda: Actualizaciones fueron rechazadas porque la punta de tu rama actual está
        ayuda: detrás de su contraparte remota. Integra los cambios remotos (es decir
        ayuda: 'git pull ...') antes de hacer push de nuevo.
        ayuda: Mira 'Note about fast-forwards' en 'git push --help' para más detalles.

# Compruebo el estado.
$ git status
        En la rama mi-rama
        Tu rama y 'origin/mi-rama' han divergido,
        y tienen 1 y 1 commits diferentes cada una respectivamente.
          (usa "git pull" para fusionar la rama remota en la tuya)

        nada para hacer commit, el árbol de trabajo está limpio

# Estando muy muy seguro de que no va a afectar a otras personas.
$ git push -f
        Enumerando objetos: 5, listo.
        Contando objetos: 100% (5/5), listo.
        Compresión delta usando hasta 12 hilos
        Comprimiendo objetos: 100% (2/2), listo.
        Escribiendo objetos: 100% (3/3), 318 bytes | 318.00 KiB/s, listo.
        Total 3 (delta 0), reusado 0 (delta 0)
        To ~/sandbox/remotes/origin
         + 13c9acf...ec27a36 mi-rama -> mi-rama (forced update)

$ git status
        En la rama mi-rama
        Tu rama está actualizada con 'origin/mi-rama'.

        nada para hacer commit, el árbol de trabajo está limpio

Si el git push se hizo a una rama compartida, las acciones a tomar dependen de la situación:

Si los commits son para corregir una errata en un mensaje, lo mejor es dejarlo correr, porque arreglarlo no merece la pena.
Si es algo que hay que deshacer, lo más correcto sería usar git revert para revertir un commit individual o un merge commit, probar bien los cambios, y después hacer git push.
Si es algo como un bug, siempre se pueden hacer commits para corregirlo.

Aunque lo más correcto no siempre es lo más cómodo, para que mentir.
Si se ha hecho git push a una rama compartida con otros desarrolladores y ninguno ha usado ninguno de los commits que se han subido (no han hecho git pull en la rama comprometida, ni git pull origin <rama>, ni git cherry-pick de ninguno de los commits) se puede:

Avisar al resto de desarrolladores de que se ha subido algo por error y que hasta nuevo aviso no hagan ni git pull en la rama, git pull origin <rama> ni git cherry-pick de los commits recién subidos.
Hacer lo cambios que se tengan que hacer y hacer git push -f.
Pedir al resto de desarrolladores que se actualicen las ramas remotas con git fetch y decir que ya se puede trabajar con normalidad.

¿Y si algún otro desarrollador ya ha hecho uso de alguno de los commits subidos?
Siempre es posible seguir los pasos de arriba y que el resto de desarrolladores rehagan parte del trabajo, pero igual es demasiado trastorno y no merece la pena.

¿Y si se ha modificado algún commit en local y se decide que lo mejor es dar marcha atrás porque no se puede hacer git push -f?

Se puede volver a lo que había antes de modificar el commit siguiendo los mismos pasos que para recuperar una rama borrada por error.

Git pull, ese comando problemático

"git pull" cada vez hace una cosa distinta; después de hacer "git pull" la aplicación ya no funciona.

git pull sirve para actualizar una rama local con una rama del repositorio remoto.
Por debajo primero hace git fetch , actualizando todas las ramas del repositorio remoto, y después a git merge <rama-remota> .
Ciertamente es muy cómodo, pero hay que tener todas las consideraciones que al mergear una rama (pueden surgir conflictos, hay revisar que todo sigue funcionando después de un merge commit, etc) y alguna más.

La forma más verbosa de invocar a git pull sería git pull origin <rama>, que por debajo vendría a hacer:

git fetch origin , que actualizaría todas las ramas remotas (las ramas origin/<rama> que se mencionaban en la introducción).
git merge origin/<rama> para mergear la rama remota origin/<rama> en la rama local.

Es una forma muy útil para por ejemplo actualizar la rama local en la que se está desarrollando una nueva feature con la última versión de master en el repositorio remoto.

$ git status
        En la rama mi-feature
        nada para hacer commit, el árbol de trabajo está limpio

# Actualizo mi-feature con la rama master del repositorio remoto.
$ git pull origin master 

        # Internamente hace git fetch.
        remote: Enumerando objetos: 5, listo.
        remote: Contando objetos: 100% (5/5), listo.
        remote: Comprimiendo objetos: 100% (2/2), listo.
        remote: Total 3 (delta 0), reusado 0 (delta 0)
        Desempaquetando objetos: 100% (3/3), 291 bytes | 291.00 KiB/s, listo.

        # La rama master ha cambiado en el repositorio remoto
        # así que actualiza origin/master.
        Desde ~/sandbox/remotes/origin
         * branch            master     -> FETCH_HEAD
           792a7bf..1a16ce3  master     -> origin/master

        # Hace el merge.
        Merge made by the 'recursive' strategy.
         index.html | 2 ++
         1 file changed, 2 insertions(+)

# Reviso la el úlitmo commit para ver que ha sido un merge.
$ git log -1
        commit 73365ef70d893c3b3b9680e0676bda0c78c36505 (HEAD -> mi-feature)
        Merge: 504b167 1a16ce3

            Merge branch 'master' of ~/sandbox/remotes/origin into mi-feature

Otra forma es git pull a secas, bastante útil para actualizar la rama local con el upstream.
Por debajo vendría a hacer:

git fetch <remoto>, donde <remoto> sería el repositorio remoto del upstream (si el upstream fuese origin/master haría git fetch origin).
git merge <upstream>, para mergear el upstream en la rama local (si el upstream fuese origin/master haría git merge master). Si la rama no tuviese upstream indicaría como añadirlo.

# Hago git status y veo que no estoy siguiendo 
# a ninguna rama remota.
$ git status
        En la rama mi-feature
        nada para hacer commit, el árbol de trabajo está limpio

# git pull hace internamente el git fetch, y luego falla, 
# porque la rama actual no sigue a ninguna rama remota
$ git pull
        remote: Enumerando objetos: 5, listo.
        remote: Contando objetos: 100% (5/5), listo.
        remote: Comprimiendo objetos: 100% (2/2), listo.
        remote: Total 3 (delta 0), reusado 0 (delta 0)
        Desempaquetando objetos: 100% (3/3), 290 bytes | 290.00 KiB/s, listo.
        Desde ~/sandbox/remotes/origin
           792a7bf..01d5c54  master     -> origin/master
        No hay información de rastreo para la rama actual.
        Por favor especifica a qué rama quieres fusionar.
        Ver git-pull(1) para detalles.

            git pull <remoto> <rama>

        Si deseas configurar el rastreo de información para esta rama, puedes hacerlo con:

            git branch --set-upstream-to=origin/<rama> mi-feature

# Cambio a otra rama que si sigue a una rama remota.
$ git checkout master 
        Cambiado a rama 'master'
        Tu rama está detrás de 'origin/master' por 1 commit, y puede ser avanzada rápido.
          (usa "git pull" para actualizar tu rama local)

# Hago git pull.
# Internamente hace el git fecth, pero como no hay cambios
# en el repositorio remoto no imprime nada.
$ git pull
        Actualizando 792a7bf..01d5c54
        Fast-forward
         index.html | 1 +
         1 file changed, 1 insertion(+)

Todas las opciones que se pueden aplicar a git merge se pueden aplicar también a git pull.

Si por ejemplo se está en la rama master y se quiere actualizar con el repositorio remoto puede ser útil ejecutar git pull --ff-only ; haciéndolo así git pull fallaría si las ramas han divergido, evitando así que la rama master se diferente a la de otros desarrolladores.

Se puede ejecutar git pull --no-ff --no-commit origin hotfix para que si el merge resultase en un merge commit tener la posibilidad de revisar los cambios antes de completar el commit, por si hubiese alguna incompatibilidad entre las dos ramas.

Renombrar una rama

Corregir un texto incorrecto, se copio la clave del issute tracker que no era, etc.

Las acciones para renombrar ramas solo renombran ramas locales, no actúan sobre los upstream; como tal no existe la opción de renombrar una rama en un repositorio remoto, aunque si se puede borrar la rama con el nombre antiguo y crear una rama con el nombre nuevo. Adicionalmente habría que actualizar el upstream de la rama, porque no se actualiza solo.

# Hago un git status y veo que estoy en la rama dovolop 
# y que estoy siguiendo a la rama remota origin/dovolop.
$ git status
        En la rama dovolop
        Tu rama está actualizada con 'origin/dovolop'.

        nada para hacer commit, el árbol de trabajo está limpio

# Otra opción para ver esto es mirarlo es 
$ git branch -vv -a
        * dovolop                d63cc7b [origin/dovolop] crear hoja de estilos home.css
          master                 d63cc7b [origin/master] crear hoja de estilos home.css
          remotes/origin/dovolop d63cc7b crear hoja de estilos home.css
          remotes/origin/master  d63cc7b crear hoja de estilos home.css

# El nombre debería ser develop, así que renombro la rama.
$ git branch -m develop

# Si verifico el estado veo que he renombrado la rama local, 
# pero no la remota, y que mi rama local todavía sigue 
# a origin/dovolop.
$ git branch -a -vv
        * develop                d63cc7b [origin/dovolop] crear hoja de estilos home.css
          master                 d63cc7b [origin/master] crear hoja de estilos home.css
          remotes/origin/dovolop d63cc7b crear hoja de estilos home.css
          remotes/origin/master  d63cc7b crear hoja de estilos home.css

# "Actualizo" la rama remota borrando la vieja y creando la nueva.
$ git push origin :dovolop develop
        Total 0 (delta 0), reusado 0 (delta 0)
        To ~/sandbox/git
         - [deleted]         dovolop
         * [new branch]      develop -> develop

# Si consulto el estado veo que la rama remota se ha renombrado
# y que mi rama local sigue a una rama "desaparecida" o "gone".
$ git branch -a -vv
        * develop                d63cc7b [origin/dovolop: desaparecido] crear hoja de estilos home.css
          master                 d63cc7b [origin/master] crear hoja de estilos home.css
          remotes/origin/develop d63cc7b crear hoja de estilos home.css
          remotes/origin/master  d63cc7b crear hoja de estilos home.css

# Así que tengo que actualizar el upstream para que siga 
# a la rama renombrada.
$ git push --set-upstream origin develop 
        Rama 'develop' configurada para hacer seguimiento a la rama remota 'develop' de 'origin'.
        Everything up-to-date

# Y ya está todo en orden.
$ git branch -a -vv
        * develop                d63cc7b [origin/develop] crear hoja de estilos home.css
          master                 d63cc7b [origin/master] crear hoja de estilos home.css
          remotes/origin/develop d63cc7b crear hoja de estilos home.css
          remotes/origin/master  d63cc7b crear hoja de estilos home.css

🚨 Los comandos anteriores pueden afectar a otros desarrolladores.

Si el Filemón tenía una rama siguiendo a dovolop y Mortadelo la "renombra" en el repositorio remoto, pueden ocurrir varias cosas: que Filemón no sea capaz de actualizarse con los commits que haga Mortadelo, ya que ha perdido la referencia la rama remota; o que Filemón haga nuevos commits y al subirlos al repositorio remoto cree una nueva sin darse cuenta.

# Mortadelo comprueba el estado de las ramas.
$ git branch -vv -a
        * dovolop                d63cc7b [origin/dovolop] crear hoja de estilos home.css
          master                 d63cc7b [origin/master] crear hoja de estilos home.css
          remotes/origin/dovolop d63cc7b crear hoja de estilos home.css
          remotes/origin/master  d63cc7b crear hoja de estilos home.css

# Hace un fetch y no le presta mucha antención, porque 
# no es extraño que se creen o borren ramas.
$ git fetch 
        Desde ~/sandbox/git
         - [eliminado]       (nada)     -> origin/dovolop
         * [nueva rama]      develop    -> origin/develop

# Si Filemón comprobase el estado de la rama vería algo raro, 
# pero supongamos que no lo hace.
$ git branch -vv -a
        * dovolop                d63cc7b [origin/dovolop: desaparecido] crear hoja de estilos home.css
          feature                d63cc7b [origin/feature: desaparecido] crear hoja de estilos home.css
          master                 d63cc7b [origin/master] crear hoja de estilos home.css
          remotes/origin/develop d63cc7b crear hoja de estilos home.css
          remotes/origin/master  d63cc7b crear hoja de estilos home.css

# Hace algunos cambios y los commitea.
$ git commit -am "algunos cambios"
        [dovolop 190e822] algunos cambios
         1 file changed, 1 insertion(+)

# Sube el nuevo commit al repositorio remoto...
# y ve que se ha creado una nueva rama, aunque el esperaba 
# que se hubiese actualizado la rama dovolop
$ git push 
        Enumerando objetos: 5, listo.
        Contando objetos: 100% (5/5), listo.
        Compresión delta usando hasta 12 hilos
        Comprimiendo objetos: 100% (3/3), listo.
        Escribiendo objetos: 100% (3/3), 305 bytes | 305.00 KiB/s, listo.
        Total 3 (delta 1), reusado 0 (delta 0)
        To ~/sandbox/git
         * [new branch]      dovolop -> dovolop

# Y sin darse cuenta ha recreado la rama que mi Mortadelo 
# con tanto esfuerzo renombro.
$ git branch -a -vv
        * dovolop                190e822 [origin/dovolop] algunos cambios
          master                 d63cc7b [origin/master] crear hoja de estilos home.css
          remotes/origin/develop d63cc7b crear hoja de estilos home.css
          remotes/origin/dovolop 190e822 algunos cambios
          remotes/origin/master  d63cc7b crear hoja de estilos home.css

Mantener el entorno limpio: cuando las ramas no dejan ver el bosque

"git branch" y tengo muchas ramas que ya no se usan; "git branch -a " muestra ramas del repositorio remoto que ya fueron borradas; "git status" dice que el upstream ha desaparecido o "is gone".

En repositorios muy activos y con muchos desarrolladores es fácil que git branch y git brach -a devuelvan decenas de resultados, de los cuales la inmensa mayoría serán ramas que no se han usado en meses.
Git nunca borra nada a menos que se le diga explícitamente, lo cual esta bien porque nunca se pierde información, pero tiene la contra de que se puede acabar con información que ya no es relevante y que dificulta encontrar lo que se esta buscando, como cuando se tiene el escritorio tan lleno de archivos, carpetas y enlaces directos que lleva un rato encontrar algo que no uses todos los días.

Ramas del repositorio remoto que ya no existen

Las más fáciles de limpiar son las ramas remotas que ya no existen en el repositorio remoto, es decir aquellas que cuando:

Pin subió la rama feature/tiger al repositorio remeto.
Pon hizo un git fetch, el cual creo la rama origin/feature/tiger. Si ejecutase hiciese git branch -a mostraría, entre otras, origin/feature/tiger
Pin borro feature/tiger.
Pon hizo git fetch, que no cambio nada. Si ejecutase hiciese git branch -a seguiría mostrando origin/feature/tiger.

Se le puede indicar a Git que borre esas ramas llamando a git fetch o a git pull con la opción --prune, para indicar que tiene que podar las ramas que ya no existen.
Si se usa un GUI, puede que ya haga el prune automáticamente, o puede que tenga una opción para configurarlo.

Es posible configurar Git para que por defecto haga prune , ahorrando así tener que usar la opción --prune en cada llamada, para ello, añadir lo siguiente al archivo ~/.gitconfig

[fetch]
        prune = true

Un ejemplo paso a paso

### Pin publica la rama feature/tiger.

# Pon hace un fetch.
$ git fetch 
        remote: Enumerando objetos: 5, listo.
        remote: Contando objetos: 100% (5/5), listo.
        remote: Comprimiendo objetos: 100% (2/2), listo.
        remote: Total 3 (delta 0), reusado 0 (delta 0)
        Desempaquetando objetos: 100% (3/3), 294 bytes | 294.00 KiB/s, listo.
        Desde ~/sandbox/remotes/origin
         * [nueva rama]      feature/tiger -> origin/feature/tiger

$ git branch -a
        * master
          remotes/origin/HEAD -> origin/master
          remotes/origin/feature/tiger
          remotes/origin/master

### Pin borra del repositorio remoto feature/tiger.

# Pon hago un fecth y no pasa nada.
$ git fetch 

# La rama origin/feature/tiger sigue existiendo.
$ git branch -a
        * master
          remotes/origin/HEAD -> origin/master
          remotes/origin/feature/tiger
          remotes/origin/master

# Si hiciese fetch con la opción --prune
# origin/feature/tiger se borraría.
$ git fetch --prune
        Desde ~/sandbox/remotes/origin
         - [eliminado]       (nada)     -> origin/feature/tiger

$ git branch -a
        * master
          remotes/origin/HEAD -> origin/master
          remotes/origin/master

Ramas locales que se han quedado sin rama remota

Pin subió la rama feature/duck
Pon hizo un git fech y git checkout feature/duck, lo cual creo la rama local feature/duck cuyo upstream es origin/feature/duck.
Pin mergeó feature/duck en master y la borro del repositorio remoto para no deja una rama que ya terminado su ciclo de vida.
Pon hizo git fecth con la opción de autoprune, con lo cual Git borro la rama origin/feature/duck , pero no feature/duck, no vaya a ser que por alguna razón se quiera conservar en local, o que la rama local hubiese divergido de la rama remota y se pierdan commits.
Pon ejecuta git status y ve el siguiente mensaje Tu rama está basada en 'origin/feature/duck', pero upstream ha desaparecido.

La manera de limpiar estar ramas es borrarlas a mano: git branch -d feature/duck

Pero con el tiempo se vuelve una tarea repetitiva y pesada, sobre todo cuando hay varias ramas en ese estado.

Una forma de hacerlo menos pesado es definiendo un par de alias en ~/.gitconfig

[alias]
    clear-pruned-branches = "!f() { git branch -vv | grep -E ': (desaparecido|gone)\\]' | grep -v '*' | awk '{print $1}' | xargs -r git branch -d; }; f"
  fetch-and-clear = !sh -c 'git fetch && git clear-pruned-branches'

git clear-pruned-branches borraría las ramas desaparecidas que no estén mergeadas en la rama actual (git branch -d).
Si alguna rama no se puede borrar porque no está mergeada mostrará un mensaje tal que error: La rama 'feature/gorilla' no ha sido fusionada completamente., y tal vez haya que prestarle un poco más de atención para no borrar algún commit que se olvido subir.

git fetch-and-clear serviría como atajo para evitar tener que escribir git fecth && git clear-pruned-branches.
Para mantener el sistema limpio se puede usar git clear-pruned-branches o usar git fetch-and-clear en lugar de git fetch.

Un ejemplo paso a paso

### Pin publica la rama feature/duck.

# Pon hace un fetch y va a la ramara a cotillear.
$ git fetch
        Desde ~/sandbox/remotes/origin
         * [nueva rama]      duck       -> origin/duck
$ git checkout duck 
        Rama 'duck' configurada para hacer seguimiento a la rama remota 'duck' de 'origin'.
        Cambiado a nueva rama 'duck'
$ git status
        En la rama duck
        Tu rama está actualizada con 'origin/duck'.

        nada para hacer commit, el árbol de trabajo está limpio

### Pin borra del repositorio remoto feature/duck.

# Pon hace un fecth y como tiene el autoprune activo 
# borra la rama remota.
$ git fetch
        Desde ~/sandbox/remotes/origin
         - [eliminado]       (nada)     -> origin/duck

# git status dice que el upstream ha desaparecido.
$ git status
        En la rama duck
        Tu rama está basada en 'origin/duck', pero upstream ha desaparecido.
          (usa "git branch --unset-upstream" para arreglar)

        nada para hacer commit, el árbol de trabajo está limpio

# Para borrarla tendría que ir a otra rama y borrarla
$ git checkout master 
        Cambiado a rama 'master'
        Tu rama está actualizada con 'origin/master'.

$ git branch -d duck
        Eliminada la rama duck (era 01d5c54)..

Ramas remotas que han sido mergeadas pero no borradas

Pin subió la rama feature/dolphin.
Mergeó la rama feature/dolphine en master pero no la borro.
La rama sigue ahí 3 meses después.

Muchos sistemas de control de versiones como GitHub o Bitbucket tienen una opción para borrar la rama al mergear si se usan Pull Request o Merge Request, pero no es raro que se olvide marcarla, o que el merge se haga en local y se olvide borrar la rama después.

Una solución es ir al repositorio remoto y borrar una por una, asegurándose de borrar solo las ramas mergeadas para no perder ningún commit
Pero de nuevo es una tarea manual y tediosa, que se puede simplificar con un comando de consola

# Ir a la rama de integración, master en ese caso
git checkout master \
    `# Actualizarla a la última versión` \
    && git pull --ff-only \
    `# Listar todas ramas remotas mergeadas en master` \
    && git branch -r --merged \
  `# Excluir del listado las ramas que no hay que borrar;` \
  `# con expresiones regulares se exluyen las que contienen el texto` \
  `# "master", "production" o "RC"` \
    | grep -vE 'master|production|RC' \
  `# Quitar del texto el nombre del repositorio remoto` \
  | sed 's/origin\///' \
  `# Borrar las ramas del repositorio remoto` \
  | xargs -r -n 1 git push --delete origin

No es un comando precisamente sencillo, y personalmente siempre me da un poco de respecto ejecutarlo.
Por ello, primero listo las ramas que se irían a borrar.

# Ir a la rama de integración, master en ese caso
git checkout master \
    `# Actualizarla a la última versión` \
    && git pull --ff-only \
    `# Listar todas ramas remotas mergeadas en master` \
    && git branch -r --merged \
  `# Excluir del listado las ramas que no hay que borrar` \
  `# con expresiones regulares se exluyen las que contienen el texto` \
  `# "master", "production" o "RC"` \
    | grep -vE 'master|production|RC' \
  `# Quitar del texto el nombre del repositorio remoto` \
  | sed 's/origin\///'

Las reviso, y si todo me cuadra ya lanzo el comando completo.

Y como medida de seguridad adicional, siempre se puede clonar el proyecto original para tener un backup.

git clone <repository-url> <project-name>-bck-"$(date)"

# Hago 'git branch' y veo que hay muchas ramas,
# muchas de las cuales creo que ya no se usan.
$ git branch 
        * contenido-home
          master
          rama-dos
          rama-nueve
          rama-seis
          rama-siete
          rama-tres
          rama-uno
          seccion-contacto

# Intento borrar alguna que ya se haya borrado del repositorio 
# remoto,pero nada.
# (fetch-and-clear es un alias descrito algo más arriba en 
# "Ramas locales que se han quedado sin rama remota")
$ git fetch-and-clear

$ git checkout master 
# Miro cuantas ramas hay mergeadas en master y hay unas cuantas...
$ git branch -r --merged
        origin/HEAD -> origin/master
      origin/master
      origin/production
      origin/rama-cinco
      origin/rama-cuatro
      origin/rama-diez
      origin/rama-dos
      origin/rama-nueve
      origin/rama-ocho
      origin/rama-seis
      origin/rama-siete
      origin/rama-tres
      origin/rama-uno
      origin/seccion-contacto

# Asi que quiero borrarlas todas menos 'production'. 
# Como borrarlas una a una sería demasiado tedioso uso un script.
$ git branch -r --merged \
   `# Excluir del listado las ramas que no hay que borrar;` \
   `# con expresiones regulares se exluyen las que contienen el texto` \
   `# "master", "production" o "RC"` \
   | grep -vE 'master|production|RC' \
   `# Quitar del texto el nombre del repositorio remoto` \
   | sed 's/origin\///' \
   `# Borrar las ramas del repositorio remoto` \
   | xargs -r -n 1 git push --delete origin
                To ~/sandbox/remotes/origin
         - [deleted]         rama-cinco
        To ~/sandbox/remotes/origin
         - [deleted]         rama-cuatro
        To ~/sandbox/remotes/origin
         - [deleted]         rama-diez
        To ~/sandbox/remotes/origin
         - [deleted]         rama-dos
        To ~/sandbox/remotes/origin
         - [deleted]         rama-nueve
        To ~/sandbox/remotes/origin
         - [deleted]         rama-ocho
        To ~/sandbox/remotes/origin
         - [deleted]         rama-seis
        To ~/sandbox/remotes/origin
         - [deleted]         rama-siete
        To ~/sandbox/remotes/origin
         - [deleted]         rama-tres
        To ~/sandbox/remotes/origin
         - [deleted]         rama-uno
        To ~/sandbox/remotes/origin
         - [deleted]         seccion-contacto

# Listo todas las ramas y veo que se han borrado muchas 
# del repositorio remoto, pero todavía quedan muchas en local. 
$ git branch -a
          contenido-home
        * master
          rama-dos
          rama-nueve
          rama-seis
          rama-siete
          rama-tres
          rama-uno
          seccion-contacto
          remotes/origin/HEAD -> origin/master
          remotes/origin/contenido-home
          remotes/origin/master
          remotes/origin/production

# Puede ser que me falte hacer el prune y borrar las ramas locales
# que se han quedado sin rama remota.
$ git fetch-and-clear 
        Eliminada la rama rama-dos (era 211751a)..
        Eliminada la rama rama-nueve (era 211751a)..
        Eliminada la rama rama-seis (era 211751a)..
        Eliminada la rama rama-siete (era 211751a)..
        Eliminada la rama rama-tres (era 211751a)..
        Eliminada la rama rama-uno (era 211751a)..
        Eliminada la rama seccion-contacto (era 2656b99)..

# Reviso por última vez y veo que está más limpio.
$ git branch -a
          contenido-home
        * master
          remotes/origin/HEAD -> origin/master
          remotes/origin/contenido-home
          remotes/origin/master
          remotes/origin/production

Modificar un tag

He creado un tag en el commit que no era; me he equivocado en el nombre del tag; he creado un tag del tipo que no era; etc

Si no se ha subido todavía al repositorio remoto, basta con borrarlo y volver a crearlo.

🚨 Si ya se ha subido al repositorio remoto... se podría reemplazar, pero eso tendría consecuencias para otros desarrolladores.

Los tags no están pensados para ser modificados, así que si alguien modifica un tag en el repositorio remoto, ya sea haciendo git push -f o borrándolo y recreándolo, el resto de desarrolladores seguirían teniendo en sus locales la versión original del tag, ya que git fetch no modifica tags.

Y puede ser un problema si en algún momento hay que revertir alguna rama a ese tag o hay que sacar un fix para esa versión, ya que dependiendo de quien haga la operación los resultados serían distintos.

En la documentación de Git se analiza este caso, y vienen a proponer dos soluciones.

La primera es crear un nuevo tag, añadiéndole por ejemplo un sufijo (si el tag original era 1.0.0 llamar al nuevo 1.0.0-the-good-one).

La segunda opción es modificar el tag en el repositorio remoto y escribir al resto de desarrolladores explicando lo ocurrido y describiendo los pasos que hay que seguir para obtener el tag correcto (borrar el tag en local con git tag --delete TAG, hacer git fetch para obtener la nueva versión, y verificar que tienen el tag correcto con git rev-parse TAG o git show TAG)

Aquí un ejemplo práctico.

# Moratadelo crea un nuevo tag y lo sube al repositorio remoto.
mortadelo@tia$ git commit -am "Implementado algoritmo secreto"
        [master 2da5ad7] Implementado algoritmo secreto
         1 file changed, 1 insertion(+)

mortadelo@tia$ git push 
        Enumerando objetos: 5, listo.
        Contando objetos: 100% (5/5), listo.
        Compresión delta usando hasta 12 hilos
        Comprimiendo objetos: 100% (2/2), listo.
        Escribiendo objetos: 100% (3/3), 285 bytes | 285.00 KiB/s, listo.
        Total 3 (delta 0), reusado 0 (delta 0)
        To ~/sandbox/remotes/origin/
           409db7e..2da5ad7  master -> master

mortadelo@tia$ git tag -a "1.0.0" -m "Implementado algoritmo secreto"

mortadelo@tia$ git push origin 1.0.0
        Enumerando objetos: 1, listo.
        Contando objetos: 100% (1/1), listo.
        Escribiendo objetos: 100% (1/1), 169 bytes | 169.00 KiB/s, listo.
        Total 1 (delta 0), reusado 0 (delta 0)
        To ~/sandbox/remotes/origin/
         * [new tag]         1.0.0 -> 1.0.0

# Se lo comenta a Filemón, que hace git fectch para traerse todas
# las novedades
filemon@tia$ git fetch
        remote: Enumerando objetos: 6, listo.
        remote: Contando objetos: 100% (6/6), listo.
        remote: Comprimiendo objetos: 100% (3/3), listo.
        remote: Total 4 (delta 0), reusado 0 (delta 0)
        Desempaquetando objetos: 100% (4/4), 402 bytes | 402.00 KiB/s, listo.
        Desde ~/sandbox/remotes/origin
           409db7e..2da5ad7  master     -> origin/master
         * [nuevo tag]       1.0.0      -> 1.0.0

# Por algúna razón Mortadelo se da cuenta de que hay un error 
# en código y decide actualizarlo.
mortadelo@tia$ git commit \
                   -am "Implementación sin errores del algoritmo secreto"
        [master e985b90] Implementación sin errores del algoritmo secreto
         1 file changed, 1 insertion(+)

mortadelo@tia$ git push 
        Enumerando objetos: 5, listo.
        Contando objetos: 100% (5/5), listo.
        Compresión delta usando hasta 12 hilos
        Comprimiendo objetos: 100% (2/2), listo.
        Escribiendo objetos: 100% (3/3), 311 bytes | 311.00 KiB/s, listo.
        Total 3 (delta 0), reusado 0 (delta 0)
        To ~/sandbox/remotes/origin/
           2da5ad7..e985b90  master -> master

# Mortadelo no quiere que el primer tag del proyecto tenga 
# ese bug, así que intenta recrearlo, pero Git le da error.
mortadelo@tia$ git tag -a "1.0.0" -m "Implementado algoritmo secreto"
        fatal: el tag '1.0.0' ya existe
# Decidido a cubrir sus huellas opta por borrar el tag 
# y crear el bueno.
mortadelo@tia$ git tag --delete 1.0.0
        Etiqueta '1.0.0' eliminada (era b017cde)

mortadelo@tia$ git tag -a "1.0.0" -m "Implementado algoritmo secreto"

# Intenta pushearlo, pero el repositorio remoto lo rechaza
mortadelo@tia$ git push origin 1.0.0
        To ~/sandbox/remotes/origin/
         ! [rejected]        1.0.0 -> 1.0.0 (already exists)
        error: falló el push de algunas referencias a '~/sandbox/remotes/origin/'
        ayuda: Actualizaciones fueron rechazadas porque el tag ya existe en el remoto.

# Resuelto quema todas las naves con un git push -f
mortadelo@tia$ git push --force origin 1.0.0
        Enumerando objetos: 1, listo.
        Contando objetos: 100% (1/1), listo.
        Escribiendo objetos: 100% (1/1), 171 bytes | 171.00 KiB/s, listo.
        Total 1 (delta 0), reusado 0 (delta 0)
        To ~/sandbox/remotes/origin/
         + b017cde...7a1b39e 1.0.0 -> 1.0.0 (forced update)

# Revisa la información del tag para comprobar que es la esperada.
mortadelo@tia$ git show 1.0.0
        tag 1.0.0
        Tagger: mortadelo <mortadelo@tia.es>
        Date:   Sun Sep 19 17:19:08 2021 +0200

        Implementado algoritmo secreto

        commit e985b904626ff98b77b2478d15abd929d4b6237d (HEAD -> master, tag: 1.0.0, origin/master, origin/HEAD)
        Author: mortadelo <mortadelo@tia.es>
        Date:   Sun Sep 19 17:18:34 2021 +0200

            Implementación sin errores del algoritmo secreto


# Filemón, hace git fetch, pero el tag no se actualiza.
filemon@tia$ git fetch
        remote: Enumerando objetos: 6, listo.
        remote: Contando objetos: 100% (6/6), listo.
        remote: Comprimiendo objetos: 100% (3/3), listo.
        remote: Total 4 (delta 0), reusado 0 (delta 0)
        Desempaquetando objetos: 100% (4/4), 430 bytes | 430.00 KiB/s, listo.
        Desde ~/sandbox/remotes/origin
           2da5ad7..e985b90  master     -> origin/master

# Revisa su tag en local y es distinto al de Mortadelo, 
# ya que apunta a la versión con el bug.
filmemon@tia$ git show 1.0.0
        tag 1.0.0
        Tagger: mortadelo <mortadelo@tia.es>
        Date:   Sun Sep 19 17:14:32 2021 +0200

        Implementado algoritmo secreto

        commit 2da5ad761654cd67bbd8bdfe1a9ac9891f04970f (tag: 1.0.0)
        Author: mortadelo <mortadelo@tia.es>
        Date:   Sun Sep 19 17:11:17 2021 +0200

            Implementado algoritmo secreto

# Para tener el mismo tag que Mortadelo tendría que 
# borrar el tag en local.
filmemon@tia$ git tag --delete 1.0.0
        Etiqueta '1.0.0' eliminada (era b017cde)
# Y hacer git fetch para obtener el nuevo tag
filmemon@tia$ git fetch
        Desde /home/claudio/sandbox/remotes/origin
         * [nuevo tag]       1.0.0      -> 1.0.0

# Revisa la información y ya ve lo mismo que Mortadelo.
filmemon@tia$ git show 1.0.0
        tag 1.0.0
        Tagger: mortadelo <mortadelo@tia.es>
        Date:   Sun Sep 19 17:19:08 2021 +0200

        Implementado algoritmo secreto

        commit e985b904626ff98b77b2478d15abd929d4b6237d (HEAD -> master, tag: 1.0.0, origin/master, origin/HEAD)
        Author: mortadelo <mortadelo@tia.es>
        Date:   Sun Sep 19 17:18:34 2021 +0200

            Implementación sin errores del algoritmo secreto

Si has llegado hasta aquí, gracias 🙂
Este era el último post de la serie; espero que este post, así como los anteriores, te hayan resultado útiles 👋

Créditos

Cover: https://www.pexels.com/photo/photography-of-forest-during-daytime-1068508/
Generación de diagramas: https://excalidraw.com/

Git: how to salir de esta, ramas

Claudio Sánchez — Mon, 19 Jul 2021 15:23:47 +0000

How to

Introducción
Orientarse dentro de una rama
Renombrar una rama
Recuperar una rama borrada por error
Git merge, ese comando problemático
Mover commits
Mover ramas
Deshacer un merge
¿Cómo integrar una rama?
HEAD detached o desacoplado

Introducción

Con un GUI

O por consola.

$ git log --graph --format='%C(auto)%h %s%n%C(auto)%d%n' --all

Una forma de visualizar los commits de un repositorio es en un árbol, donde los commits son los nudos de las ramas.

De un commit pueden salir uno o varios commits (por ejemplo, de "todos: concilio del anillo" sólo sale el commit "todos: moria", mientras que de "todos - gandalf: amon hen" salen tres, "aragorn + legolas + gimli: siguiendo a los uruk-hai...", "pipin + merry: camino a isengard" y "frodo + sam: camino a mordor"), y los commits se pueden unir de dos en dos (por ej. "aragorn + legolas + gimli + gandalf: fangorn" es la unión de los commits "aragorn + legolas + gimli: siguiendo a los uruk-ahi" y "gandalf: cayendo con el balrog").

Cuando el commit es la unión de dos commits se llama "merge commit", ya que es el resultado de git merge o git pull (sí, porque git pull hace merges por debajo), mientras que el resto de los commits suelen ser resultado de git commit, aunque también serlo de git revert o de git merge --squash.

Las ramas son referencias a commits, referencias que cambian al realizar acciones como git commit o git merge estando en esa rama (por ej. la rama "pippin-merry" estaba en el commit "pippin + merry: camino a insengard", y se modifico automáticamente para referenciar a "pippin-merry: concilio de los ents" cuando se hizo dicho commit).

Múltiples ramas pueden hacer referencia al mismo commit (por ej. las ramas "gandalf" y "aragorn-legolar-gimli" hacen referencia al commit 872cac9).

Este post va a lidiar solo con casos que pueden surgir al trabajar con ramas locales, es decir, aquellas ramas creadas localmente y que todavía no se han subido a un repositorio remoto.
Para manipular ramas en repositorio remoto con git pull o sincronizar las ramas locales con las ramas del repositorio remoto git push, hay que tener en cuenta una serie de cosas que se tratarán en el siguiente post.

Orientarse dentro de una rama

¿Cómo obtengo el commit anterior?; ¿Cuál era el commit antes del merge?

HEAD siempre indica el commit actual y HEAD~ siempre indica el commit anterior.
Refiendose a ramas, master indica el último commit de la master y master~ indica el commit anterior.
Y refiriendose a commits, 872cac9 indica el commit 872cac9 y 872cac9~ indica el commit anterior.
Estas referencias facilitan las operaciones más o menos cotidianas como pueden ser el deshacer el commit actual; git reset HEAD~ es mucho más rápido que git log para obtener el hash del commit anterior y luego hacer git reset <hash>.

Ya a modo de curiosidad, ~ es una "referencia por ancestro" que indica el commit padre. Se pueden añadir todos los ~ que se quieran para obtener referencias a commits anteriores; HEAD~ referencia al commit "padre"; HEAD~~, o HEAD~2 referencian al commit "abuelo"; HEAD~3 referencian al "bisabuelo"; etc.

También existen ^1, o simplemente ^, y ^2, para hacer referencias a los commits implicados en merge commits ; si HEAD es un merge commit, HEAD^ es equivalente a HEAD~, e indica el commit en el que se estaba cuando se hizo git merge; HEAD^2 indica el último commit de la rama con la que se hizo merge.
Y se pueden combinar para hacer cosas como HEAD^2~2.

Renombrar una rama

Corregir un texto incorrecto; se copio la clave del issute tracker que no era.

En un GUI se puede hacer click derecho en el nombre de la rama y click en "Rename".

Si es por consola hay que usar git branch -m.

# git status para ver la rana actual.
$ git status
    En la rama fature
    nada para hacer commit, el árbol de trabajo está 
        limpio

# O git status para ver todas las ramas, 
# con un * delante de la rama actual.
$ git branch
      dovolop
    * fature
      master

# Renombrar la rama actual.
$ git branch -m feature

# Renombrar otra rama.
$ git branch -m dovolop develop

$ git branch
      develop
    * feature
      master

Estas acciones solo renombran la rama local y no afectan al nombre de la rama en el repositorio remoto; si hay que renombrar una rama en el repositorio hay que tener en cuenta más detalles que se explicará en el post de repositorios remotos.

Recuperar una rama borrada por error

Me equivoque al poner el nombre de la rama cuando ejecute el comando; pensaba que sólo era pruebas, pero no...; la he borrado antes de subirla al repositorio remoto; pensaba que ya había subido todo al repositorio remoto, pero faltaba un commit.

Para borrar una rama en un GUI, click derecho en el nombre de la rama y "Delete".
Algunos GUI, tras borrar una rama, dan la opción de recuperarla.

Si el mensaje es "Unmerged commits were discarted", es recomendable prestarle atención, porque puede ser uno de los casos en los que interese recuperar la rama.

Se pueden borrar ramas de dos maneras:

git branch --delete <rama> o git branch -d <rama>: Git comprobará si <rama> esta mergeada en la rama actual, y de no estarla, no permitirá borrar la rama, evitando así que puedan perderse commits.
git branch --delete --force <rama> o git branch -D <rama>: borra la rama, este o no mergeada en la rama actual.

Como norma general es preferible usar git branch -d para ir sobre seguro, y git branch -D solo para esos casos en los que se esta completamente seguro.

Ya en el tema del HOW TO, es posible recrear la rama con git branch <rama> <hash>, donde <hash> indicaría el último commit de la rama en el momento de borrarla.
Si no se conoce ese hash y la rama se borro hace poco, git reflog puede ser una buena opción para buscarlo, ya que muestra un histórico de todos los commits por los que se ha pasado. En Deshacer un git reset hay más detalles sobre git reflog.

Si la rama se borro hace mucho tiempo, git reflog puede no ser la mejor opción, ya que el hash que se busca puede estar enterrado entre muchos otros. Documentándome para el post he visto opciones mejores como esta o esta, pero personalmente no me ha surgido el caso de tener que recuperar una rama borrada hace semanas.

¿Y si la rama se ha borrado en un repositorio remoto? Tras recrear la rama en local habría que subirla al repositorio.

Haciendo un ejemplo práctico:

$ git branch -vv
      feature/create-home   6748ee2 crear hoja de estilos                             home.css
      feature/setup-project 9e75aa0 añadido .gitignore
    * master                9e75aa0 añadido .gitignore

# Como la rama feature/setup-project está mergeada en master
# se borra sin problemas.
$ git branch -d feature/setup-project 
    Eliminada la rama feature/setup-project (era 9e75aa0)..

# Como la rama feature/create-home no está mergeada en master
# borrarla con -d da error.
$ git branch -d feature/create-home 
    error: La rama 'feature/create-home' no ha sido fusionada completamente.
    Si estás seguro de querer borrarla, ejecuta 'git branch -D feature/create-home'.

# Si se fuerza el borrado si que deja.
$ git branch -D feature/create-home 
    Eliminada la rama feature/create-home (era 6748ee2)..

# Pero me doy cuenta de mi error :(

# Así que busco el commit.
$ git reflog 
    ...
    9e75aa0 (HEAD -> master) HEAD@{6}: checkout: moving from feature/create-home to master


# Y recreo la rama.
$ git branch feature/create-home 6748ee2

$ git branch -vv
      feature/create-home 6748ee2 crear hoja de estilos home.css
    * master              9e75aa0 añadido .gitignore

Git merge, ese comando problemático

"git merge" cada vez hace una cosa distinta; después de hacer "git merge" la aplicación ya no funciona.

git merge puede hacer cosas distintas dependiendo de las diferencias que haya entre la rama actual y la rama que se quiere mergear.

El siguiente diagrama de flujo resume la lógica que hay por debajo.

Es "fast forward" cuando la rama que se quiere mergear, target, ha partido del último commit de la rama actual; en este caso git merge simplemente modificará la referencia de la rama actual para que apunte al mismo commit que la rama target.

Por poner un ejemplo, supongamos que se quiere mergear la rama feature/create-home en la rama master; dado que feature/create-home parte de master git merge por defecto hará fast forward.

$ git status
    En la rama master

$ git merge feature/create-home
    Actualizando 85b13b4..82975ee
    Fast-forward
     home.css  | 3 +++
     home.html | 2 ++
     2 files changed, 5 insertions(+)
     create mode 100644 home.css
     create mode 100644 home.html

Si no es fast forward , y no hay conflictos, git merge creará un merge commit.

$ git status
    En la rama master

$ git merge feature/create-home
   # Se abre un editor de texto para poder personalizar el 
   # mensaje del commit.
   # Tras guardar el mensaje:
    Merge made by the 'recursive' strategy.
     home.css  | 3 +++
     home.html | 2 ++
     2 files changed, 5 insertions(+)
     create mode 100644 home.css
     create mode 100644 home.html

Si no es fast forward , y hay conflictos... bien, es un momento que a nadie le gusta.
Los conflictos surgen cuando en las dos ramas se han tocado los mismos trozos de código, ya sea editándolos en ambas ramas, modificando el archivo en una y renombrándolo en la otra, etc.
Cuando surjan, Git modificará los archivos con conflictos para indicar dónde están y esperará a que se resuelvan, pero no hará nada más. Será el momento de analizar que ha pasado y resolver los conflictos.
Y siempre se puede ejecutar git reset --hard para hacer tabla rasa y empezar de cero, porque hay veces en que los conflictos se resuelven y los tests dejan de pasar, o simplemente porque los conflictos son complicados y se prefiere empezar fresco después de una pausa.

Los conflictos se verán así en el archivo

<<<<<<< HEAD
<a href="contact.html">Contacto</a>
=======
<h1> Home </h1>
<p> bienvenido </p>
>>>>>>> feature/create-home

Donde entre <<<<<<<< y ======= esta lo que hay en la rama actual, y entre ======== y >>>>>> lo que hay en la rama a mergear.

Para estos casos lo más cómodo es recurrir a un GUI:

Una vez resuelto

Ya se podrá hacer commit:.

$ git merge feature/create-home 
    CONFLICTO (add/add): Conflicto de merge en home.html
    Auto-fusionando home.html
    Fusión automática falló; arregle los conflictos y luego realice 
        un commit con el resultado.

# Resolver conflictos.

$ git commit -a
    [master 1814deb] Merge branch 'feature/create-home'

Cuando haya un merge commit de por medio siempre hay que tener cuidado, ya que si bien puede no haber conflictos si que se pueden haber introducir errores.
Si por ejemplo en la rama actual se renombrase la función doThings a createUser, junto con todos sus usos, y se mergease una rama que ha introducido un nuevo uso de doThings en un nuevo archivo, git merge puede no encontrar conflictos y mergear automáticamente, pero cuando se invoque doThings en el nuevo archivo se producirá un error, ya que doThings ha dejado de existir.
Para evitar estos problemas se pueden usar varias estrategias:

Ejecutar los tests después de cada merge, y si hay algún problema hacer commits con los fixes.
Crear un hook que impida completar el merge si fallan los tests.
Usar algunas de las opciones de git merge para controlar como se hace el merge:
- --ff-only para indicar que solo se quiere hacer merge si es fast forward, fallando en caso contrario ( por ej. git merge --ff-only feature/create-home). Puede ser útil para actualizar ramas importantes como master con total tranquilidad.
- --no-commit fuerza a que si el merge implica un merge commit, Git se detenga justo antes de hacer el commit, como haría si hubiese conflictos; en ese momento se podrán revisar los cambios, ejecutar los tests, arreglar alguna cosilla su fuese necesario, y finalmente, hacer el commit. Si el merge es fast forward este se hará automáticamente usando la estrategia de fast forward, ignorando el flag --no-commit.

Mover commits

He hecho un commit en la rama que no era; se me olvido crear la rama antes de hacer los commits.

Lo primero sería llevarse los commits a la rama adecuada.
Si la rama en la que se deberían haber hecho los commits no existe, es tan sencilla como crearla en el punto actual:

Si se usa un GUI, click derecho en la rama actual y crear una nueva rama.
Si se usa consola git branch <rama>.

Si la rama ya estaba creada, basta con ir al ella y hacer git cherry-pick de los commits que se quieren mover.

Y los segundo y último es restaurar la rama en la que se han hecho los commits por error al punto correcto .

Al final muchas situaciones en Git se resuelven combinando varias acciones.

Mover ramas

Saque la rama del hotfix de mi rama de feature en lugar de sacarla de master; saque mi rama de feature de master en lugar de la rama de integración.

Un ejemplo de esta situación sería sacar la rama hotfix de la rama de integración develop, en lugar de haberlo hecho de la rama principal master.

Si no se ha hecho ningún commit bastaría con modificar la rama hotfix para que parta de master:

Si se usa un GUI, click derecho en master y click en "Reset current branch to here" o similar.
Si se usa consola git checkout -B hotfix master.

Si ya se ha hecho algún commit, la opción que menos comandos requiere es git rebase, aunque hay que visualizar muy bien lo que se quiere hacer antes de usarlo.
Otra opción algo más laboriosa sería:

Apuntarse el hash de los commits que han hecho en la rama hotfix.
Resetear la rama hotfix para que apunte al punto correcto con "Reset current branch to here" si se una GUI o git checkout -B hotfix master si se usa consola.
Recuperar los commits con apuntados en el paso 1 con git cherry-pick

La forma por defecto de git rebase es git rebase <rama-destino> <rama-a-mover>, o, si ya se está en <rama-a-mover>, simplemente git rebase <rama-destino>; haciendo un símil, sería como "trasplantar la rama".

En el ejemplo, git rebase master hotfix movería los commits de la rama hotfix para que salgan del commit G en lugar del commit E .

(Como nota aclaratoria, añado un apostrofe para indicar que el commit con hash A' es una copia A pero con distinto padre; decir "mover" no es del todo correcto, pero es una simplificación bastante útil).

Por defecto git rebase mueve todos los commits de <rama-a-mover> que no tiene <rama-destino>, incluso aunque alguno de esos commits estén compartidos con otra rama.

En el ejemplo, git rebase master hotfix movería los commits E y F, que solo tiene hotfix, y copiaría los commits C, D y F, que hotfix comparte con la rama develop y que no están en en master.

Si el algún momento se llegasen a mergear las ramas hotfix y develop en master no habría conflictos porque, aunque los commits C', D' y F' estén duplicados en la rama develop, Git detectaría que son lo mismo.

Se puede indicar de una manera más precisa los commits que hay que mover con el comando
git rebase --onto <rama-destino> <desde-la-rama> <rama-a-mover>

En el ejemplo git rebase --onto master develop hotfix movería solo los commits E y F, que están en la rama hotfix y salen de la rama develop .

Como se decía al principio, git rebase es lo que menos comandos requiere, pero en contra tiene que lleva su tiempo visualizarlo.

Otra nota sobre git rebase es que puede implicar resolver conflictos varias veces si las ramas de origen y destino son muy distintas; si eso ocurre, siempre se puede dar marchar atrás con git rebase --abort y replantarse la estrategia.

Deshacer un merge

Un merge que produce un error; un merge hecho donde en una rama que no era; un merge hecho con la rama que no era.

Si se acaba de hacer el merge y no se ha subido a un repositorio remoto lo más sencillo es revertir la rama al commit en el que estaba antes del merge.

Si se han hecho commits después del merge o ya se han subido al repositorio remoto, se pueden deshacer con git revert.

Si el merge fue fast forward, habría que hacer un git revert de cada uno de los commits que se han añadido con el merge, empezando por el más reciente.
Más sobre como revertir commits simples en Deshacer un commit: como revertir un cambio.

Si el merge implico un merge commit se puede usar git revert -m1 <hash>, donde -m1 indica que se desean deshacer los cambios que vinieron de <rama> cuando se hizo git merge <rama>.

También se puede usar, aunque es menos común, git revert -m2 <hash> para indicar que se desean deshacer las diferencias que había en la rama en la que se hizo git merge <rama> con respecto de <rama>, para que tras el git revert se tenga lo mismo que en <rama>.

Estos comando generarán un commit con los cambios para deshacer el merge commit.

Con un ejemplo práctico.

# Acabo de hacer un merge y lo quiero deshacer.

# Hago git log -1 para ver la información del último commit.
# 'Merge: 6512051 6748ee2' me dice que 
# estaba en el commit 6512051 cuando hice el merge 
# de otra rama que a su vez estaba en el commit 6748ee2.
$ git log -1
    commit 7a12efcf980753856b67b72b040a73a93cdb3c9b (HEAD -> master)
    Merge: 6512051 6748ee2

        Merge branch 'feature/create-home'

# Compruebo cuales son las diferencias entre el commit
# 6512051 y el commit en el que estoy.
$ git diff 6512051 HEAD 
    diff --git a/home.css b/home.css
    new file mode 100644
    index 0000000..6748ee2
    --- /dev/null
    +++ b/home.css
    ...
    diff --git a/home.html b/home.html
    new file mode 100644
    index 0000000..6141d5d
    --- /dev/null
    +++ b/home.html
    ...

# Hago el revert del merge indicando con -m1 que quiero
# tomar como referencia lo que había antes del merge.  
$ git revert -m1 7a12efcf980753856b67b72b040a73a93cdb3c9b
    [master f65033c] Revert "Merge branch 'feature/create-home'"
     1 file changed, 2 deletions(-)

# log -1 me indica que hay nuevo commit.
$ git log -1 f65033c
    commit f65033c1cb53ab664482d9d7ee3f836a493e249f

        Revert "Merge branch 'feature/create-home'"

        This reverts commit 7a12efcf980753856b67b72b040a73a93cdb3c9b, reversing
        changes made to 651205183ba4da49663163b881901c74e8c98606.

# Compruebo los cambios y no hay diferencias.
$ git diff 6512051 HEAD

¿Qué ocurriría si se mergease de nuevo la rama cuyo merge se ha revertido?
Si no se ha hecho ningún commit adicional en <rama>, git merge <rama> dirá que "la rama ya está actualizada" y no hará nada, aunque quizá lo natural sería pensar que volvería a aplicar los cambios de <rama>.
Si se ha hecho algún commit adicional en <rama>, git merge <rama> solo aplicará los cambios de los nuevos commits; la "buena" noticia es que en git merge notificará unos conflictos bastante extraños que harán ver que algo raro pasa.
Todo eso resulta un poco contraintuitivo, pero git revert sólo modifica archivos, no modifica el histórico de commits, así que cuando se le pide a Git que mergee commits que ya tiene en su histórico, se limita a ignorarlos porque ya los tiene.

¿Por qué alguien querría mergear de nuevo algo que acaba de revertir?
Si un merge commit causa problemas en producción, una forma rápida de salir del paso es revertir ese merge commit, arreglar el problema en la rama y volver a mergearla.

Pero como se sigue de la pregunta anterior no es algo directo.
En https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt se explican muy bien dos posibles maneras para hacerlo.

Resolver los problemas en la rama cuyo merge commit se ha revertido, revertir el commit que revirtió el merge commit y por último mergear la rama con el fix.
Replicar en una nueva rama todos los commits de la rama cuyo merge commit se ha revertido (los commits tendrían los mismos cambios, pero como tendrían un hash distinto para Git serían distintos), resolver los problemas en la nueva rama y mergearla.

¿Cómo integrar una rama?

He terminado mi flamante primera feature, los tests están en verde, ha pasado las revisiones de código, y ahora ¿como la integro?

Supongamos que se quiere integrar la rama feature/create-home en la rama master.

Algunas de las estrategias más habituales son:

Merge commit
Merge squash
Rebase
Trunk base development

Merge commit

Crear un merge commit cada vez que se mergee una rama en master: git merge --no-ff <rama>.
--no-ff sirve para forzar que se cree un merge commit, aunque se pudiese hacer fast forward.

# Me aseguro de que estoy en la rama master, 
# que es donde quiero hacer el merge.
$ git merge status 
    En la rama master
    nada para hacer commit, el árbol de trabajo está limpio

$ git merge --no-ff feature/create-home 
    Merge made by the 'recursive' strategy.
     home.css  | 3 +++
     home.html | 2 ++
     2 files changed, 5 insertions(+)
     create mode 100644 home.css
     create mode 100644 home.html

Merge squash

Condensar todos los commits de la rama a mergear en un único commit: git merge --squash <rama>.

Después del merge será necesario un hacer git commit, cuyo mensaje por defecto será un sumario de todos los commits de <rama>, aunque se podrá personalizar.

# Me aseguro de que estoy en la rama master, 
# que es donde quiero hacer el merge.
$ git merge status 
    En la rama master
    nada para hacer commit, el árbol de trabajo está limpio

$ git merge --squash feature/create-home
    Actualizando 85b13b4..82975ee
    Fast-forward
    Commit de squash -- no actualizando HEAD
     home.css  | 3 +++
     home.html | 2 ++
     2 files changed, 5 insertions(+)
     create mode 100644 home.css
     create mode 100644 home.html

$ git commit 
    [master 1a5ee55] Squashed commit of the following:
     2 files changed, 5 insertions(+)
     create mode 100644 home.css
     create mode 100644 home.html

$ git log -1
    commit 1a5ee55ca09d28b8469385fa6675211ddc2d23ca (HEAD -> master)

        Squashed commit of the following:

        commit 82975ee0f7f4fcab93e2b0d0d6e9d2f915510881     
            crear hoja de estilos home.css

        commit b9632f136aef8ae41306fc4468aa979800fb330a     
            crear home.html

    A       home.css
    A       home.html

Rebase

Mover todos los commits de la rama a mergear en la rama actual, o, haciendo un símil, "replantar la rama": git rebase <rama-destino> <rama-a-mover>.
Si actualmente se está en <rama-a-mover>, se puede hacer directamente git rebase <rama-destino>.

Después del merge será necesario un hacer git merge para añadir los commits en la rama de integración.

# "Replanto" feature/create-home en master.
$ git rebase master feature/create-home 
    En primer lugar, rebobinando HEAD para después reproducir 
        tus cambios encima de ésta...
    Aplicando: crear home.html
    Aplicando: crear hoja de estilos home.css

# Hago checkout en master.
$ git checkout master 
    Cambiado a rama 'master'

# Hago un merge fast forward de la rama a integrar.
$ git merge --ff-only feature/create-home 
    Actualizando e157378..d63cc7b
    Fast-forward
     log.txt | 2 ++
     1 file changed, 2 insertions(+)

Algo a tener en cuenta con git rebase es que puede llegar a ser necesarios resolver conflictos si <rama-a-mover> parte de un commit antiguo de <rama-destino>.
Si <rama-a-mover> tiene varios commits puede llegar a ser necesario resolver conflictos una vez por cada commit.
Hay proyectos en los que por defecto utilizan git rebase, y excepcionalmente, cuando se encuentran un caso donde la resolución de conflictos se complica, usan git merge para así solo resolver conflictos una única vez.

Cuando surjan conflictos en un git rebase seguir las instrucciones que da Git como salida del comando.

Trunk base development

Sólo hay una rama, master, y todos los commits se hacen sobre ella.
Adelantándome al post de repositorios remotos, cuando se quiera subir esa rama al repositorio remoto y surjan conflictos porque la rama local master ha divergido respecto de la rama master del repositorio remoto, habrá que decidir si optar por merge commits o por rebase.

¿Por que se llama Trunk base development? Trunk es el nombre de la rama principal en los primeros sistemas de control de versiones.

Conclusión

Cada opción tiene sus pros y sus contras:

git merge preserva todo el histórico de commits tal y surgió, pero si no se sigue un buen flujo de ramas puede resultar en un árbol de commits muy complejo, donde sería difícil determinar cuando se introdujo un bloque de código o un bug.
git merge --squash deja un árbol de commits muy sencillo, con una única rama y un único commit por cada feature, pero puede dejar commits muy grandes y se pierde información de los commits individuales.
git rebase produce una única rama con todos los commits que se han hecho, pero se pierde la información de en que punto se inicio una rama y los merges con conflictos pueden ser muy dolorosos.
Trunk base development reduce a 0 la gestión de ramas, pero cuando las ramas divergen hay que optar por git merge o git rebase.

¿Qué usar? La decisión dependerá de cuanta gente trabaje en el proyecto, de las convenciones del equipo, del tipo de proyecto, de como de grandes sean las features, ...

Esto intenta ser un post agnóstico, así que

HEAD detached o desacoplado

"git status" muestra un texto extraño en lugar del nombre de la rama; me he cambiado de rama y ya no encuentro el último commit.

Lo normal es hacer git checkout a ramas, pero también se puede hacer a tags y a commits. En estos últimos casos se pasa al estado "detached HEAD", o "HEAD desacoplada" si se tiene Git configurado en castellano .

$ git log --graph --format='%C(auto)%h %s%n%C(auto)%d'
    * d63cc7b crear hoja de estilos home.css
    |  (HEAD -> master, feature/create-home)
    * 1676ceb crear home.html
    | 
    * e157378 añadido .gitignore
    | 
    * 85b13b4 set up proyecto
    | 
    * 417ceac commit inicial

# git status indica que estoy en la rama master.
$ git status
    En la rama master
    nada para hacer commit, el árbol de trabajo está limpio

# Al hacer checkout a un commit se muestra un mensaje 
# que da respeto.
$ git checkout e157378
    Nota: cambiando a 'e157378'.

    Te encuentras en estado 'detached HEAD'. Puedes revisar por aquí, hacer
    cambios experimentales y hacer commits, y puedes descartar cualquier
    commit que hayas hecho en este estado sin impactar a tu rama realizando
    otro checkout.

    Si quieres crear una nueva rama para mantener los commits que has creado,
    puedes hacerlo (ahora o después) usando -c con el comando checkout. Ejemplo:

      git switch -c <nombre-de-nueva-rama>

    O deshacer la operación con:

      git switch -

    Desactiva este aviso poniendo la variable de config advice.detachedHead en false

    HEAD está ahora en e157378 añadido .gitignore

# git status en lugar de mostrar un nombre de rama 
# muestra un mensaje bastante raro....
$ git status
    HEAD desacoplada en e157378
    nada para hacer commit, el árbol de trabajo está limpio

# git branch, para ver las ramas, también muestra 
# el mensaje raro.
$ git branch
    * (HEAD desacoplada en e157378)
      master

Los checkouts a tag y a commits pueden ser una suerte de máquina del tiempo con la que, sin necesidad de crear o modificar ramas, poder consultar como estaba el código hace unas semanas, o confirmar que los tests funcionaban antes de integrar una feature.

Para volver a ver nombres de ramas normales basta con hacer git checkout a una rama.

Los problemas pueden venir cuando estando en detached HEAD se hace un commit y después git checkout a otra rama, ya que ese commit se puede llegar a perder a menos que se conozca su clave hash o se use git reflog (ver Deshacer un commit: como revertir un cambio para más información sobre git reflog).
Si el commit es de prueba no habrá problema, ya que desaparecerá sin dejar rastro, pero si es algo con lo que se quiere seguir trabajando siempre es posible crear una rama a partir de él, o recuperarlo con git cherry pick.

$ git checkout e157378
    Nota: cambiando a 'e157378'.

    Te encuentras en estado 'detached HEAD'. ...

# Hago algunos cambios en el .gitignore.
$ git commit -am "ignorar más cosas"
    [HEAD desacoplado aec5722] ignorar más cosas
     1 file changed, 1 insertion(+)

# Cambio de rama por alguna razón y Git da la señal de
# alarma, indicando ademas como se puede recuperar el commit.
$ git checkout master 
    Peligro: estás saliendo 1 commit atrás, no está conectado
    a ninguna rama:

      aec5722 ignorar más cosas

    Si quieres conservarlo creando una nueva rama, este es un buen momento
    para hacerlo:

     git branch <nuevo-nombre-de-rama> aec5722

    Cambiado a rama 'master'

# Si por alguna razón no hubiese conservado el hash del
# commit, siempre es posible consultarlo en con git reflog.
$ git reflog 
    d63cc7b (HEAD -> master, feature/create-home) HEAD@{0}: checkout: moving from aec57222a12d12ca6b87f5329ce67c10b5289d0a to master
    aec5722 HEAD@{1}: commit: ignorar más cosas
    e157378 HEAD@{2}: checkout: moving from master to e157378
    d63cc7b (HEAD -> master, feature/create-home) HEAD@{3}: checkout: moving from e15737895b61e4c7e205a8729abad775b6679f5d to master
    e157378 HEAD@{4}: checkout: moving from master to e157378
    claudio@jupiter2:~/sandbox/git(master)$ git checkout e157378

# Si quiero crear una rama para poder seguir trabajado a 
# partir de él,hago como ha dicho Git
$ git branch nuevo-nombre-de-rama aec5722
$ git checkout feature/configure-project 
    Cambiado a rama 'feature/configure-project'
$ git status
    En la rama feature/configure-project
    nada para hacer commit, el árbol de trabajo está limpio

Si has llegado hasta aquí, gracias 🙂
Espero que te haya resultado útil, y nos vemos en el próximo post sobre repositorios remotos 👋

Créditos

Cover: https://pxhere.com/en/photo/149424
Generaciónd de diagramas: https://excalidraw.com/

Git: how to salir de esta, commits

Claudio Sánchez — Tue, 15 Jun 2021 12:29:37 +0000

How to

Introducción
Cambiar el mensaje de un commit
Deshacer un commit: cómo revertir un cambio
Deshacer un commit: borrón y cuenta nueva
Deshacer un git reset
Añadir o quitar algo de un commit
Hacer commit con algunos cambios de un archivo, no del archivo completo
Compartir archivos y cambios sin conflictos
Cómo hacer un commit paso a paso
¿o por qué no se ha añadido un archivo o un cambio al hacer commit?

Introducción

Los commits son la unidad básica de Git. Se identifican con una clave hash única y son inmutables, es decir, un commit no se puede modificar una vez creado, pero es muy fácil reemplazarlo por otro con una clave hash diferente y los cambios que se deseen.
Dicho esto, y aunque se que lo correcto sería decir "reemplazar el commit X por un commit X', que es como X pero con algunos cambios", yo suelo decir "modificar el commit X" porque es más corto y me abstrae de las complejidades de lo que hace Git por debajo; en el contexto de mi día a día prefiero un lenguaje conciso y expresivo, que transmita el resultado final, a una parrafada detallada y precisa que sea difícil de entender y donde sea fácil perderse en los detalles.

Un ejemplo de clave hash sería 7f347041e695151cbe8493b8ed842949150095c4. Muchas veces, por no llenar la pantalla con claves largas, se suele usar la una clave abreviada, por ejemplo 7f34704, que vienen a ser los primeros caracteres de la clave hash. Nada garantiza que una clave abreviada sea única, pero si se detecta que esta repetida solo hay que mostrar más caracteres, hasta que deje de haber conflicto, por ejemplo 7f347041e.

Algo muy importante a tener en cuenta con los commits es que no hay que modificar, deshacer o borrar un commit que ya este en un repositorio remoto, ya que otro desarrollador puede haber partido de ese commit para su desarrollo y cuando se quieran unir las dos versiones pueden surgir conflictos.

Cambiar el mensaje de un commit

Corregir una falta de ortografía, mejorar el texto del commit,incluir la clave de la tarea del issue tracker, etc

Para modificar el mensaje de un commit lo más fácil es recurrir a un GUI, click derecho en el commit a modificar y click en la opción de editar el mensaje del commit.

Para entender un poco lo que pasa por debajo, además de saber como hacerlo cuando no se tiene una GUI, lo mejor es recurrir a la linea de comandos.

# Acabo de hacer un commit con un error en el texto.
$ git commit -m "mi tercre commit" 
    [master 7f34704] mi tercre commit
    1 file changed, 1 insertion(+)

# Para cambiarlo

# Primero me aseguro de que no haya ningún cambio en el área de stage.
$ git status
    En la rama master
    Cambios a ser confirmados:
      (usa "git reset HEAD <archivo>..." para sacar del área de stage)

        modificado:     dates.txt

# Si los hay los saco del área de stage.
$ git reset HEAD dates.txt 
    Cambios fuera del área de stage tras el reset:
    M   dates.txt

# Y modifico el mensaje del commit.
$ git commit --amend -m "mi tercer commit"
    [master 19ffda6] mi tercer commit
     1 file changed, 1 insertion(+)

Esto habrá reemplazado el último commit, con hash 7f34704, por otro con el mismo contenido, pero con otro mensaje y hash 19ffda6.

Cuando se usa git commit --amend -m, es importante asegurarse qué se va a commitear para no incluir nada que se desee.

Si se tuviese que modificar el mensaje de un commit más antiguo, por ejemplo el 077c45d , se podría hacer algo como esto

# La virgulilla es importante
$ git rebase -i 077c45d~ 
# Se abrirá un editor de texto con algo como
##--------------
    pick 077c45d mi segunod commit
    pick 19ffda6 mi tercer commit

    # Rebase bced58d..11a0995 en bced58d (2 comandos)
    #
    # Comandos:
    #  p, pick = usar commit
    #  r, reword = usar commit, pero editar el mensaje
      #  .... 
## ----------------
# Edito el archivo para tener
    r 077c45d mi segundo commit
    pick 19ffda6 mi tercer commit
## Guardo.
## Se abre un editor de texto con el mensaje a modificar, 
## escribo el texto correcto y guardo.

Esto habrá remplazado el commit 077c45d, por otro con el mensaje correcto y un nuevo hash, así como todos los commits que vengan después.

$ git log --pretty=format:"%h %s" --graph
    * 52190c2 mi tercer commit
    * 247f469 mi segundo commit
    * bced58d first commit

Aunque ni el contenido ni el mensaje del commit con hash 19ffda6 hayan cambiado, si ha cambiado el commit que venía antes que él, y por lo tanto ha hecho falta reemplazarlo para reflejar ese cambio.

Deshacer un commit: cómo revertir un cambio

Un commit que produce un bug; un commit hecho por error; un commit con trazas hecho por error; etc

Cuando lo que se quiere deshacer esta bien acotado en un commit, y se está seguro de que si ese commit desapareciese todo estaría como debería, se puede usar git revert <hash a deshacer>, o en el GUI, click derecho en el commit a deshacer, y "Revert commit".

git revert no elimina el commit objetivo, si no que crea un commit con cambios para deshacer el commit objetivo.

¿Y si se quiere deshacer el commit resultado de un git revert? Se puede hacer un git revert de ese commit.

¿Y si no se quiere deshacer el commit entero, si no sólo parte?
En algunos GUIs, "Revert commit" abrirá una ventana con los cambios del revert commit; si se cierra esa ventana, se podrá: ver cambios del "revert commit"; añadir o quitar cosas; y finalmente hacer un nuevo commit.
Por consola lo equivalente sería git revert --no-commit <hash a deshacer>, revisar el "revert commit" y git commit

$ git log -1 73d8766 --patch-with-stat 
    commit 73d8766f13198c5da71e2759b1c659f5c5a3bf8a (HEAD -> master)
        commit con error
    ---
     log.txt | 1 +
     1 file changed, 1 insertion(+)

    diff --git a/log.txt b/log.txt
    index f14e7df..7c5c54a 100644
    --- a/log.txt
    +++ b/log.txt
    @@ -1,5 +1,6 @@
     dom may 24 16:17:36 CEST 2020: log
    +esto no es un log
     dom may 24 16:17:37 CEST 2020: log

$ git revert 73d8766
    [master e9bac4c] Revert "commit con error"
     1 file changed, 1 deletion(-)

$ git log -1 e9bac4c --patch-with-stat
    commit e9bac4c003bc41640c29a12b21b70a5eb0d99193 (HEAD -> master)
        Revert "commit con error"     
        This reverts commit 73d8766f13198c5da71e2759b1c659f5c5a3bf8a.
    ---
     log.txt | 1 -
     1 file changed, 1 deletion(-)

    diff --git a/log.txt b/log.txt
    index 7c5c54a..f14e7df 100644
    --- a/log.txt
    +++ b/log.txt
    @@ -1,6 +1,5 @@
     dom may 24 16:17:36 CEST 2020: log
    -esto no es un log
     dom may 24 16:17:37 CEST 2020: log

¿Y si el commit es de un merge commit?

$ git revert 5139b956
    error: el commit 5139b9560d954dd0c20320ecb3bac404e8bee7dc es una fusión pero no se proporcionó la opción -m.
    fatal: falló al revertir

El comando dará un error, el cual se verá en el post dedicado a ramas.

Deshacer un commit: borrón y cuenta nueva

Empezar desde de cero una feature que se está complicando; estar a medias en una resolución de conflictos de un merge, perder el hilo por alguna razón, y casi que mejor empezar de 0 ; etc.

git reset <hash> hará que todo sea como en el commit de indicado, incluido el histórico de commits.
¿Qué pasara con las diferencias que hay entre el commit actual y el commit de destino? Bien, git revert tiene varios modos:

--soft deja todos los cambios como staged.
--mixed (el modo por defecto) deja todos los cambios como unstage o untracked.
--hard descarta todos los cambios. Hay que intentar hacerlo solo cuando se este seguro, porque no siempre es posible recuperar todos los cambios. Para más detalles ver Deshacer un git reset.
--merge, nunca he llegado a entenderlo...
--keep, nunca he llegado a entenderlo...

Si se usa un GUI, la diferencia entre --soft y --mixed no es apreciable, ya que el GUI hace su magia por debajo y el resultado final es el mismo; si se usa consola, con --soft se podría hacer directamente un commit con todos los cambios, sin tener que añadir los archivos con git add, mientras que con --mixed si habría que hacerlo.

Para hacerlo desde un GUI, click derecho en el commit al que se desee volver y click en "Reset current branch to Here...".

Por consola:

# Consulto el histórico de commits.
$ git log --pretty=format:"%h %s" --graph
    * b2cd87b mi tercer commit
    * 247f469 mi segundo commit
    * bced58d first commit

$ git reset --hard bced58d
    HEAD is now at bced58d reset

$ git log --pretty=format:"%h %s" --graph
    * bced58d first commit

Para los usuarios de consola, y adelantando un poco contenidos del futuro post de ramas, decir que se pueden hacer cosas como git reset master, para así hacer que el commit de destino sea el último commit de la rama master.

Deshacer un git reset

He hecho 'git reset —hard' donde no era y he perdido todos los cambios; He hecho 'git reset' al commit donde no era y he perdido algunos cambios.

Cuando se hace git reset --hard se pueden perder dos cosas:

Commits que no estén en ninguna otra rama.
Cambios de los que todavía no se hubiese hecho ningún commit.

Lo primero tiene solución haciendo otro git reset al punto del que que se venía
¿Pero y si no se conoce el hash del commit al que se quiere volver?
git reflog muestra un histórico de todos los commits por los que sea ha pasado, ya sea porque se ha hecho un commit, se ha cambiado de rama, o se ha hecho un git reset.
Un ejemplo sería

fc2f7e1 HEAD@{1}: commit: amazing stuff

fc2f7e1: es el hash del commit por el que se ha pasado.
HEAD@{1}: es un alias algo más amigable de ese hash. El indice indica hace cuando se produjo el cambio, siendo HEAD{0} el punto actual, HEAD{1} el punto anterior, HEAD{2} lo que vino antes, etc. Estos alias no son constantes, si por ejemplo se hiciese otro git reset u otro git commit, HEAD{1} pasaría a referenciar lo que referenciase HEAD{0} antes del cambio y sucesivamente.
acción: en este caso commit, pero podría ser un reset, un checkout, un merge, etc.
mensaje: una descripción textual de la acción.

Poniéndolo en un ejemplo

# Partiendo de un repositorio a estrenar.
$ git log --pretty=format:"%h %s" --graph
    * 00fd1f0 inicializar repo

# Hago algunos cambios en el proyecto y hago commit.
$ git commit -am "amazing stuff"
    [master fc2f7e1] amazing stuff
     1 file changed, 1 insertion(+), 1 deletion(-)

# Hago un git reset por alguna razón.
$ git reset --hard 00fd1f0
    HEAD is now at 00fd1f0 inicializar repo

# Reviso el histórico y me doy cuenta de que he perdido 
# cosas por error.
$ git log --pretty=format:"%h %s" --graph
    * 00fd1f0 inicializar repo

$ git reflog 
    00fd1f0 (HEAD -> master) HEAD@{0}: reset: moving to 00fd1f0
    fc2f7e1 HEAD@{1}: commit: amazing stuff
    00fd1f0 (HEAD -> master) HEAD@{2}: commit (initial): inicializar repo

# Hago reset al punto al que quiero volver.
$ git reset --hard HEAD@{1}
    HEAD is now at fc2f7e1 amazing stuff

$ git log --pretty=format:"%h %s" --graph
    * fc2f7e1 amazing stuff
    * 00fd1f0 inicializar repo

¿Y si es el segundo caso?
En esos casos me apoyo en el IDE, ya que desconozco si hay alguna manera de hacerlo con Git.

La mayoría de los IDEs suelen tener un "Local history" donde almacenan todos los cambios que se han hecho, y se puede acceder a él para ver cuando se produjo un cambio o restaurar algo.
Para acceder suele ser algo como como seleccionar una carpeta o un archivo en el IDE, click derecho, "Local history", "Show history" y a jugar.

Añadir o quitar algo de un commit

Añadir un archivo que por alguna razón se ha olvidado, quitar algo que se ha olvidado quitar; quitar algo que se ha commiteado por error, etc.

La solución más sencilla es hacer un nuevo commit con lo que se quiere añadir o quitar, y la mejor si ha se ha hecho git push ; quedará un commit de más en la rama (se si usa git merge--squash ni siquiera eso), pero es una solución rápida y a prueba de errores.

Ahora bien, si eres de esos a los que les gusta tener un árbol de commits donde cada uno de ellos represente un paso lógico dado para crear una nueva feature, para así tener un histórico bien detallado, hay comandos para modificar los commits.

Si se usa una GUI, en el menú del commit suele existir la opción de "Amend Commit", que a grandes grandes rasgos crea un nuevo commit con la unión del último commit de la rama y el commit que se esté haciendo y reemplazará el último commit de la rama con ese nuevo commit.

# Antes del "Amend commit".
$ git log --pretty=format:"%h %s" --graph
    * b2cd87b mi tercer commit
    * 247f469 mi segundo commit
    * bced58d first commit

# Después del "Amend commit".
$ git log --pretty=format:"%h %s" --graph
    * d9822c9 mi tercer commit
    * 247f469 mi segundo commit
    * bced58d first commit

Para hacerlo en consola

# Modificao un archivo.

# Revisar el status.
$ git status
    En la rama master
    Cambios no rastreados para el commit:
      (usa "git add <archivo>..." para actualizar lo que será confirmado)
      (usa "git checkout -- <archivo>..." para descartar los cambios en el directorio de trabajo)

        modificado:     dates.txt

# Añado el archivo modificado al área de stage.
$ git add dates.txt

# Hago un commit con la opción ammend para modificar 
# el commit y el mensaje.
$ git commit --amend -m "mi tercer commit más un cambio"                     
    [master d9822c9] mi tercer commit más un cambio
     1 file changed, 2 insertions(+)

¿Y si el commit no es el último, si no uno anterior?
git rebase -i (ver Cambiar el mensaje de un commit, a parte de pick y reword tiene la opción de editar o borrar un commit. Es una opción que existe, pero intento evitarla ya que es probable que implique resolver conflictos varias veces: si se edita un archivo en un commit antiguo, es probable que ese mismo archivo haya sido editado commits posteriores y habrá resolver conflictos por cada uno de esos commits.

Hacer commit con algunos cambios de un archivo, no del archivo completo

Estoy con un bug y creo que ya lo he solucionado, así que voy probarlo en la máquina de CI; por si acaso no quiero borrar todavía las trazas de debug que he metido, pero tampoco quiero hacer un commit con ellas.

Algunos GUIs dejan revisar que cambios en un archivo se quieren commitear al inspeccionar los archivos para el commit

Desde consola también se puede hacer con git add -p (o --patch) y seleccionar que trozos de un archivo se quieren añadir; o con git commit -i (o --interactive) , que permite elegir como tratar todos los archivos que se incluirían en el commit al hacer git commit -a.

Estos comandos abren un dialogo en la consola donde se puede seleccionar como tratar los cambios.

$ git add -p recursive.php 
    diff --git a/recursive.php b/recursive.php
    index 215ddd0..590b3ac 100644
    --- a/recursive.php
    +++ b/recursive.php
    @@ -1,11 +1,14 @@
     <?php

         function recursiveFunction(Closure $action, Closure $stopCheck, $data) : void {
    +        var_dump($data);
    +
             if ($stopCheck($data)) {
    +            var_dump("stop contidion matched");
                 return;
             }

    -        $action($data);
    +        $data = $action($data);

             recursiveFunction($action, $stopCheck, $data);
         }
    \ No newline at end of file
    Stage this hunk [y,n,q,a,d,s,e,?]? ?    
    y - stage this hunk
    n - do not stage this hunk
    q - quit; do not stage this hunk or any of the remaining ones
    a - stage this hunk and all later hunks in the file
    d - do not stage this hunk or any of the later hunks in the file
    s - split the current hunk into smaller hunks
    e - manually edit the current hunk
    ? - print help
    Stage this hunk [y,n,q,a,d,s,e,?]? s
    Split into 3 hunks.
    @@ -1,4 +1,6 @@
     <?php

         function recursiveFunction(Closure $action, Closure $stopCheck, $data) : void {
    +        var_dump($data);
    +
             if ($stopCheck($data)) {
    Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? n
    @@ -4,4 +6,5 @@
             if ($stopCheck($data)) {
    +            var_dump("stop contidion matched");
                 return;
             }

    Stage this hunk [y,n,q,a,d,K,j,J,g,/,e,?]? n
    @@ -5,7 +8,7 @@
                 return;
             }

    -        $action($data);
    +        $data = $action($data);

             recursiveFunction($action, $stopCheck, $data);
         }
    \ No newline at end of file
    Stage this hunk [y,n,q,a,d,K,g,/,e,?]? y

$ git status
    On branch test
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)

            modified:   recursive.php

    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:   recursive.php

$ git diff --staged 
    diff --git a/recursive.php b/recursive.php
    index 215ddd0..b865da0 100644
    --- a/recursive.php
    +++ b/recursive.php
    @@ -5,7 +5,7 @@
                 return;
             }

    -        $action($data);
    +        $data = $action($data);

             recursiveFunction($action, $stopCheck, $data);
         }
    \ No newline at end of file

Y permite ir tan al detalle como seleccionar que lineas concretas de un pedazo de código se quieren incluir en el commit, opción que no todos los GUI permiten.

Compartir archivos y cambios sin conflictos

Traerme de otra rama en desarrollo una nueva interfaz, un cambio o un fix; etc

Si los cambios estuviesen ya en master, o en cualquier otra rama compartida, sería tan sencillo como mergear esa rama, pero hay ocasiones en las que dos desarrolladores (pongamos Fulano y Mengano) están trabajando cada uno en su rama y la cosa se complica:

Fulano podría mergearse la rama de Mengano, pero ello implicaría traerse también cosas todavía no estables o no finalizadas, y a la larga le podría dar problemas.
Fulano podría pedirle por email o chat los cambios a Mengano y aplicarlos manualmente en su rama.
O Fulano, si Mengano hubiese subido su rama al repositorio común, podría usar git cherry-pick

git cherry-pick <hash> crea un commit que añade exactamente los mismos objetos que los que contiene el commit indicado (para más información ahí va un buen artículo de como se organiza Git por debajo).

Si hay un commit que sólo contiene los cambios que se desea traer (una nueva interfaz, clase, archivo, fix, etc), es sencillo.

Desde el GUI, buscar el commit con los cambios, click derecho, y "Cherry-Pick"

Desde consola git cherry-pick -x <hash> ( -x añade al commit el texto cherry picked from commit <hash>, lo cual puede ser un buen añadido)

# La rama amazing contiene una una interfaz que 
# quiero traerme.
(amazing)$ git log -2 --stat 
    commit c30dd31081fc390465d9ef1a7f3d0a8422d90408 (HEAD -> amazing)

        AMAZING: implementación en proceso

     src/AmazingImplementation.php | 10 ++++++++++
     1 file changed, 10 insertions(+)

    commit e10c9b91860d182b4985c843a502de653e44c500

        AMAZING: new inteface

     src/AmazingInterface.php | 7 +++++++
     1 file changed, 7 insertions(+)

# Mi rama actual es comercial, y me traigo los cambios 
# que me interesan.
(comercial)$ git cherry-pick -x e10c9b91860d182b4985c843a502de653e44c500
    [comercial 1ef28f9] AMAZING: new inteface
     1 file changed, 7 insertions(+)
     create mode 100644 src/AmazingInterface.php

# Hago algún otro commit.

$ git log -2 --stat 
    commit f55e27bb46ae08c6dfb97a69e3f9ab4dc2ef18e3 (HEAD -> comercial)

        COMERCIAL: Comercial.php

     src/Comercial.php | 15 +++++++++++++++
     1 file changed, 15 insertions(+)

    commit 1ef28f9e31adb6d6191d1b2f224daf5357dd217d

        AMAZING: new inteface

        (cherry picked from commit e10c9b91860d182b4985c843a502de653e44c500)

     src/AmazingInterface.php | 7 +++++++
     1 file changed, 7 insertions(+)

# Cuando en el futuro se haga el merge no debería 
# haber conflictos...
# a menos que se hayan tocado mucho los archivos en 
# las dos ramas.
(master)$ git merge --no-ff amazing 
    Merge made by the 'recursive' strategy.
     src/AmazingImplementation.php | 10 ++++++++++
     src/AmazingInterface.php      |  7 +++++++
     2 files changed, 17 insertions(+)
     create mode 100644 src/AmazingImplementation.php
     create mode 100644 src/AmazingInterface.php

(master)$ git merge --no-ff comercial
    Merge made by the 'recursive' strategy.
     src/AmazingInterface.php |  1 +
     src/Comercial.php        | 15 +++++++++++++++
     2 files changed, 16 insertions(+)
     create mode 100644 src/Comercial.php

Algo a tener en cuenta a la hora de hacer cherry-pick de archivos que no están en la rama, es que si por ejemplo ese archivo se ha creado en un commit y modificado en otro, y se intenta hacer cherry-pick de ese último commit, se producirá un conflicto.
Se puede resolver el conflicto o hacer git cherry-pick -x <hash-primer-commit> <hash-segundo-commit>

¿Qué ocurre si <hash-commit-X> contiene cambios que no queremos, como por ejemplo la clase que implementa la interfaz que queremos traernos?

Desde consola se puede hacer git cherry-pick -x --no-commit <hash-commit-X> , que lo dejara todo listo para hacer el commit. En ese momento se podría quitar alguno de los archivos que no se quisiesen.

# Hay una rama que en uno de sus commits tiene la interfaz
# que me interesa junto con más cosas.
$ git log -2 --stat
    commit dbcf29746184e8d9d3969fc4e008a80f140d7df6 (HEAD -> amazing-II)

        implementación de método

     src/AmazingImplementation.php | 10 ++++++++++
     1 file changed, 10 insertions(+)

    commit 61b38431b7b6cdcc279515b3467370d1d8cd64ca

        añadida interfaz y algo más

     log.txt                  | 3 +++
     src/AmazingInterface.php | 6 ++++++
     2 files changed, 9 insertions(+)

# Estoy en la rama comercial-II, y me quiero traer 
# la interfaz
(comercial-II)$ git cherry-pick -x --no-commit 61b38431b7b6cdcc279515b3467370d1d8cd64ca

# Reviso los cambios.
(comercial-II)$ git status
    On branch comercial-II
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)

            modified:   log.txt
            new file:   src/AmazingInterface.php

# Quito los cambios que no necesito.
(comercial-II)$ git reset HEAD log.txt
    Unstaged changes after reset:
    M       log.txt

# Hago el commit.
(comercial-II)$ git commit -m "añadida solo interfaz"
    [comercial-II 16908dd] añadida solo interfaz
     1 file changed, 6 insertions(+)
     create mode 100644 src/AmazingInterface.php

# Reviso el status, donde veo que tengo cambios que no he 
# commiteado y que tendré que quitar.
(comercial-II)$ git status
    On branch comercial-II
    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:   log.txt

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

# Reviso los cambios que he incluido en el commit.
(comercial-II)$ git log -1 --stat 
    commit 16908dd4cf9d15e2bf8feafce1d1b3e296f1bede (HEAD -> comercial-II)
    Author: claudio <claudio.sanchez@coches.com>
    Date:   Sun Aug 23 13:32:11 2020 +0200

        añadida solo interfaz

        (edited cherry picked from commit 61b38431b7b6cdcc279515b3467370d1d8cd64ca)

     src/AmazingInterface.php | 6 ++++++
     1 file changed, 6 insertions(+)

También se puede hacer cherry-pick de rangos de commits

# la ~ en el primer commit es importante
$ git cherry-pick -x <hash-primer-commit>~..<hash-ultimo-commit>

Cómo hacer un commit paso a paso
¿o por qué no se ha añadido un archivo o un cambio al hacer commit?

¿Por qué un cambio o un nuevo archivo no pueden llegar a incluirse en un commit al hacer git commit?

Podría ser porque el archivo está untracked, porque se ha hecho git commit cuando el archivo no estaba en área de stage o porque cumple alguna de las expresiones del archivo .gitignore

Para entender la respuesta a los dos primeros casos hay que entender cómo es el ciclo de vida de un archivo en Git y hacer un commit siguiendo todos los pasos, sin atajos como git commit -a

Para Git los archivos pueden estar en dos estados:

Tracked: son todos aquellos archivos sobre los que Git lleva un registro, y que alguien tendría si se clonase el repositorio. Los archivos en este estado pueden estar a su vez modificados, no modificados o en el area de stage.
Untracked: son todos aquellos archivos que están dentro de la carpeta del repositorio pero que nunca se le ha dicho a Git que tiene que registrar. Git no hace nada que no se le diga, así que un archivo untracked estará así hasta que se indique explícitamente que debe cambiar al estado tracked.

A grandes rasgos, cuando se crea un nuevo archivo en la carpeta del repositorio:

El archivo empieza en el estado untracked.
Con git add <nuevo archivo> se le dice a Git que lo tiene que registrar; el archivo pasara a estar en el estado tracked y se moverá al área de stage.
Cuando se haga git commit se incluirá en el nuevo commit, se sacará del área de stage y pasará a estar no modificado.

Un detalle importante, es que git commit -a no registra archivos en estado untracked, y por lo tanto estos no se incluirían en el commit. Hay que incluirlo con git add.

¿Y cuando se modifica o borra un archivo que ya estaba registrado?

El archivo pasa a estar como modificado.
Con git add <nuevo archivo> se moverá al área de stage.
Con git commit se incluirá en el nuevo commit, se sacará del área de stage y pasará a estar no modificado.

Para archivos en estado tracked si funciona git commit -a, así que es posible ahorrarse el git add.

Otra cosa que suele hacer soltar una exclamación es que si se modifica un archivo, se hace git add , se vuelve a modificar el archivo y se hace git commit, los últimos cambios no estarán incluidos en commit.
Después de cada cambio en un archivo habría que volver a hacer git add.

En cualquier momento se puede verificar el estado de los archivos con git status, tanto antes como después del commit.
Si eres un usuario de consola te gustará saber que es posible personalizar el prompt de la shell para saber de un vistazo si hay algo modificado o pendiente de hacer commit (para zsh hay multitud de temas, y para bash al final hay un ejemplo).

Pero antes un ejemplo práctico de toda la explicación de arriba.

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

# Creo un archivo.
$ echo "TODO" > README.md

# Git status indicará que hay un archivo nuevo
$ git status
    On branch master
    Untracked files:
      (use "git add <file>..." to include in what will be committed)

        README.md

    nothing added to commit but untracked files present (use "git add" to track)

# Si intento hacer un commit fallará, ya que README.md 
# esta untracked.
$ git commit -m "creación de README.md"
    On branch master
    Untracked files:
        README.md

    nothing added to commit but untracked files present

$ git add README.md 

# Tras git add README.md pasa a estar tracked y en 
# el area de stage.
$ git status
    On branch master
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)

        new file:   README.md

# Ahora si que es posible hacer commit.
$ git commit -m "creación de README.md"
    [master ccd62fa] creación de README.md
     1 file changed, 1 insertion(+)
     create mode 100644 README.md

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

$ echo "# Introducción" > README.md

$ git status
    On branch master
    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:   README.md

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

$ git add README.md 

$ echo "# Instalación" >> README.md

# Los cambios de antes antes de git add están en 
# el area de stage; y los de después están fuera.
$ git status
    On branch master
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)

        modified:   README.md

    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:   README.md

$ git commit -m "añadir secciones"
    [master f4df7c2] añadir secciones
     1 file changed, 1 insertion(+), 1 deletion(-)

# Al haber hecho el commit sin la opción -a, solo los cambios
# en el area de stage se han incluido en el commit;
# si el commit se hubise hecho con -a, se habrían incluido 
# todos los cambios
$ git status
    On branch master
    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:   README.md

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

$ git diff
    diff --git a/README.md b/README.md
    index 28429bb..ab9e81e 100644
    --- a/README.md
    +++ b/README.md
    @@ -1 +1,2 @@
     # Introducci<C3><B3>n
    +# Instalaci<C3><B3>n

Incluyendo lo siguiente en el ~/.bashrc, el prompt incluirá, cuando se esté dentro de un repositorio de Git, la rama actual y un * si hay cambios pendientes de commitear

YELLOW="\[\033[0;33m\]"
GREEN="\[\033[0;32m\]"
LIGHT_BLUE="\[\033[1;34m\]"
WHITE="\[\033[1;37m\]"
COLOR_NONE="\[\e[0m\]"
function parse_git_dirty {
[[ $(git status 2> /dev/null | tail -n1) != "nothing to commit, working directory clean" ]] &&
[[ $(git status 2> /dev/null | tail -n1) != "nothing to commit, working tree clean" ]] &&
[[ $(git status 2> /dev/null | tail -n1) != "nada para hacer commit, el árbol de trabajo está limpio" ]] &&
   echo "*"
}
function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e "s/* \(.*\)/(\1$(parse_git_dirty))/"
}
PS1="$GREEN\u$WHITE@$YELLOW\H:$LIGHT_BLUE\w${COLOR_NONE}\$(parse_git_branch)\$ "

Si has llegado hasta aquí, gracias 🙂
Espero que te haya resultado útil, y nos vemos en el próximo post sobre ramas 👋

Créditos

Cover: https://pixabay.com/es/photos/monta%C3%B1a-moj%C3%B3n-roc-cumbre-2702405/

Git: how to salir de esta

Claudio Sánchez — Tue, 15 Jun 2021 12:29:23 +0000

Cuando se introdujo Git en la primera empresa en lo que lo use fue más o menos así

Git es un muy sencillo.
"git clone" para descargarte el proyecto, "git commit -a" para hacer un commit, "git branch" para crear una rama, "git checkout" para cambiarte de rama, "git pull" para actualizar la rama y "git push" para subir los cambios al repositorio.
Si tienes dudas mira el cheat sheet

Evidentemente no fue tan sencillo, y pronto empezaron a surgir los problemas ¿por qué no se ha añadido este archivo al commit? ¿qué es esto de los conflictos al actualizar la rama? ¿porque no puedo hacer push?
Y es normal, Git es una herramienta muy potente, con muchísimas funcionalidades. Cuesta cogerle el truco, y más cuando nos lanzamos a usarlo con una introducción superficial.

A lo largo de varios posts voy a contar situaciones que me he encontrado usando Git y como he aprendido a salir de ellas, ya que creo que hay multitud de artículos sobre cómo empezar con Git o sobre como hacer un flujo de trabajo, pero pocos sobre como salir del paso; y sí, está Stack Overflow, pero creo que puede ser útil agrupar algunas de las preguntas más comunes y explayarse un poco en la respuestas.

DEV Community: Claudio Sánchez

Git: how to salir de esta, repositorios remotos

How to

Introducción

Trastear con repositorios remotos

Problemas al subir una rama

Modificar algo en el repositorio remoto

Git pull, ese comando problemático

Renombrar una rama

Mantener el entorno limpio: cuando las ramas no dejan ver el bosque

Ramas del repositorio remoto que ya no existen

Ramas locales que se han quedado sin rama remota

Ramas remotas que han sido mergeadas pero no borradas

Modificar un tag

Créditos

Git: how to salir de esta, ramas

How to

Introducción

Orientarse dentro de una rama

Renombrar una rama

Recuperar una rama borrada por error

Git merge, ese comando problemático

Mover commits

Mover ramas

Deshacer un merge

¿Cómo integrar una rama?

Merge commit

Merge squash

Rebase

Trunk base development

Conclusión

HEAD detached o desacoplado

Créditos

Git: how to salir de esta, commits

How to

Introducción

Cambiar el mensaje de un commit

Deshacer un commit: cómo revertir un cambio

Deshacer un commit: borrón y cuenta nueva

Deshacer un git reset

Añadir o quitar algo de un commit

Hacer commit con algunos cambios de un archivo, no del archivo completo

Compartir archivos y cambios sin conflictos

Cómo hacer un commit paso a paso¿o por qué no se ha añadido un archivo o un cambio al hacer commit?

Créditos

Git: how to salir de esta

Cómo hacer un commit paso a paso
¿o por qué no se ha añadido un archivo o un cambio al hacer commit?