Al colaborar con otros desarrolladores utilizando Git, es posible que te encuentres con el error error: failed to push some refs to [repositorio remoto].

Este error ocurre principalmente cuando intentas enviar tus cambios locales a GitHub, pero el repositorio local aún no está actualizado con los cambios realizados en el repositorio remoto.

En esencia, Git te está indicando que actualices el repositorio local con los cambios actuales del repositorio remoto antes de enviar tus propios cambios. Esto es necesario para evitar sobrescribir los cambios realizados por otros.

A continuación, discutiremos dos posibles formas de solucionar este error.

Cómo solucionar el error error: failed to push some refs to en Git

Podemos solucionar el error error: failed to push some refs to [repositorio remoto] en Git utilizando los comandos git pull origin [rama] o git pull --rebase origin [rama]. En la mayoría de los casos, la segunda opción ( git pull --rebase origin [rama]) resuelve el error.

Veamos cómo puedes usar los comandos mencionados.

Cómo solucionar el error error: failed to push some refs to en Git usando git pull

Ejecutar git pull implica obtener los nuevos cambios realizados en el repositorio remoto y fusionarlos con el repositorio local.

Una vez que se haya realizado la fusión, podrás enviar tus propios cambios de código a GitHub.

En este caso, estamos intentando solucionar el error error: failed to push some refs to [repositorio remoto] ejecutando git pull.

Aquí te mostramos cómo hacerlo:

git pull origin main

Si estás trabajando en una rama diferente, deberás reemplazar main en el ejemplo anterior con el nombre de tu rama.

Ten en cuenta que existe la posibilidad de que este comando no logre sincronizar tus repositorios remoto y local, y por lo tanto, no resuelva el error. Si la solicitud se completa correctamente, continúa y ejecuta el siguiente comando para enviar tus propios cambios:

git push -u origin main

Si el error persiste, obtendrás un error que dice: fatal: refusing to merge unrelated histories. En ese caso, utiliza la solución que se presenta en la siguiente sección.

Cómo solucionar el error error: failed to push some refs to en Git usando git pull --rebase

El comando git pull --rebase es útil cuando tu rama local está un commit por detrás de la rama remota.

Para solucionar el error, ejecuta los siguientes comandos:

git pull --rebase origin main
git push -u origin main

Si el primer comando se ejecuta correctamente, deberías obtener una respuesta que diga: Successfully rebased and updated refs/heads/main.

El segundo comando envía el estado actual de tu repositorio local a la rama remota.

Resumen

En este artículo, abordamos el error error: failed to push some refs to [repositorio remoto].

Este error se produce cuando intentas enviar tus cambios locales al repositorio remoto sin actualizar tu repositorio local con los cambios más recientes del repositorio remoto.

Discutimos dos comandos que puedes usar para solucionar este error: git pull origin [rama] y git pull --rebase origin [rama].

Espero que esto te ayude a resolver el error.

¡Feliz codificación!

El SSH (Shell Seguro) es un protocolo cliente-servidor para conectarse y autenticarse a un servidor remoto.

La autenticación significa que el servidor remoto puede verificar que eres tú mismo no alguien más hablando por ti.

Podrías ya estar usando la autenticación SSH de Github, ¿pero sabes cómo funciona en sí? En este artículo, aprenderá qué sucede de forma interna y cómo funciona en realidad la autenticación de SSH.

A lo largo, entenderás los conceptos fundamentales de criptografía que cada desarrollador debería saber: encriptación de clave simétrica, encriptación de clave asimétrica, funciones hash criptográficas, y firmas digitales.

Algunos desarrolladores usualmente no tienen la chance de aprender y entender estos fundamentos de criptografía, pero estos conceptos te ayudarán a la larga. También, te ayudarán en estar en una mejor posición para tomar decisiones de seguridad informadas para tus aplicaciones de web en producción.

Así que vamos, abróchate los cinturones de seguridad, ¡y comencemos!

Esto es lo que cubriremos:

1. Primero, ¿por qué la Autenticación es tan importante?
2. Encriptación de Clave Simétrica
3. Encriptación de Clave Asimétrica
4. Funciones de Hash Criptográficas
5. Firmas Digitales
6. Cómo Funciona la Autenticación SSH
7. Resumiendo Todo

Primero, ¿por qué la Autenticación es tan importante?

Cuando ejecutamos git push, Github necesita verificar que la persona correcta está interactuando con Github. Imagina si un atacante podría llegar a hacer git push por ti.

Entonces todos tus repositorios estarían bajo el control del atacante. Podrían eliminar todo tu código juntamente con todo el historial de las confirmaciones.

Esto suena bastante peligroso, ¿no? Así que para verificar que eres tú el que está hablando con Github, y no un atacante, Github tiene varias formas de autenticarte.

El método más usado para autenticar con Github es la autenticación SSH.

Antes que entendamos cómo funciona la autenticación SSH internamente, necesitaremos entender los conceptos fundamentales de criptografía, a saber – encriptación de clave simétrica, encriptación de clave asimétrica, funciones de hash criptográficas, y firmas digitales.

¡Comencemos!

Encriptación de Clave Simétrica

En los tiempos antiguos, los gobernantes idearon varios métodos de comunicar mensajes militares secretos a sus comandantes del ejército.

En los métodos más primitivos, mayormente usados por los gobernantes Griegos antiguos y posiblemente luego los Romanos, involucrados usando una vara de madera cilíndrica llamado un Escítala.

Antes de una invasión militar, el gobernante tendría las dos mismas varas de madera cilíndricos exactas. Entonces le daría una escítala al comandante del ejército y mantener uno para sí mismo.

El dispositivo funcionaba al enrollar una tira de cuero alrededor de escítala. Después de hacer esto, el gobernante escribiría el mensaje por encima de la tira de cuero enrollada de forma que solo pudiera ser leído cuando estuviere enrollada de forma apropiada nuevamente.

Supón que la escítala le permitiera escribir tres letras alrededor en un circulo y cinco letras de forma recta a lo largo de su longitud. La tira de cuero enrollada con el mensaje attackfromright escrito luciría así:

       |   |   |   |   |   |
       | a | t | t | a | c |  |
     __| k | f | r | o | m |__|
    |  | r | i | g | h | t |
    |  |   |   |   |   |   |

Después de escribir el mensaje en la escítala, el gobernante desenrollaría la tira de cuero y lo enviaría al comandante del ejército. Cuando estaba desenrollada, la tira de cuero tendría el siguiente mensaje desordenado:

----------------
akrtfitrgaohcmt
----------------

Así que ahora lo ves, incluso si la tira de cuero fuera interceptada por un espía enemigo, el mensaje no tendría sentido. ¿No es fascinante? El uso inteligente de una vara de madera y una tira de cuero, ¡podría haber ayudado a algunos gobernantes antiguos ganar batallas!

Cuando la tira de cuero alcanzaba al comandante del ejército, lo envolvería con su propia escítala (que sería exactamente el mismo que el del gobernante), y luego el comandante sería capaz de entender el mensaje apropiadamente.

Esta técnica de la escítala en realidad es un ejemplo de la encriptación de clave simétrica en la práctica.

La encriptación es un proceso en el que el mensaje origina es modificado (o codificado) de tal forma que solamente el recipiente indicado puede decodificar y ver el mensaje actual.

El mensaje original se llama texto plano, mientras que el mensaje codificado se llama texto cifrado. La encriptación convierte el texto plano a texto cifrado con la ayuda de una clave.

Para descifrar el mensaje, que sería convertir el texto cifrado a texto plano, una persona debe tener acceso a la misma llave.

Si lo comparamos a la técnica de la escítala, la escítala es la llave. El gobernantes solamente comparte la llave (escítala) con el comandante del ejército que necesita saber lo que dice el mensaje.

Así es como luce el proceso de encriptación:

El proceso de descifrado lucirá así:

Llamamos a esto encriptación de llave simétrica porque la misma llave se usa tanto para encriptar y descifrar el mensaje.

Esta llave (la escítala) se debe mantener resguardada del acceso del enemigo. Si el enemigo accede a esta llave, entonces será capaz de descifrar los mensajes.

Pero hay otro tipo de encriptación llamada encriptación de llave asimétrica. Ahora que entiendes la encriptación de llave simétrica, sigamos con la encriptación de llave asimétrica.

Encriptación de Llave Asimétrica

En la encriptación de llave simétrica, como vimos arriba, la misma llave era usada por el gobernante y el comandante del ejército para encriptar y descifrar el mensaje.

Pero en una encriptación de llave asimétrica, hay dos llaves (llamado un par de llaves). De las dos llaves, una es una llave privada y la otra es una llave pública.

La llave pública puede ser compartido con todos (el cual por eso se llama pública). Pero la llave privada tiene que mantenerse, ¡en secreto! Nunca debe ser revelado a nadie.

Lo interesante sobre la encriptación de llave asimétrica es eso, si un mensaje es encriptado con la llave pública, entonces puede ser descifrado solamente con la llave privada correspondiente. Ninguna otra llave puede descifrarlo.

Y funciona de la otra forma también. Si un mensaje es encriptado con la llave privada entonces puede ser descifrado solamente usando la llave pública correspondiente.

Las dos llaves – pública y privada – están enlazados matemáticamente uno con el otro. Mientras uno encripta, el otro descifra.

Sólo una pequeña nota, la encriptación de llave asimétrica también se le llama encriptación de llave pública. Estos dos términos son usados de forma intercambiable pero significa lo mismo.

Funciones Hash Criptográficas

Una función hash criptográfica está diseñada para tomar una entrada de cualquier longitud y producir una salida de longitud fijada. La salida de longitud fijada se le denomina valor hash.

Un ejemplo popular de una función hash criptográfica es SHA-256.

La imagen de arriba muestra el valor hash SHA-256 de la entrada "freeCodeCamp.org". Las funciones hash criptográficas tienen tres propiedades que lo hacen muy útiles (lo veremos en las próximas secciones).

Primero, es prácticamente imposible para tomar el valor hash y averiguar la entrada del valor hash.

Por ejemplo, si nos dan el valor hash c9c31315ef2257e4b7698, no hay forma de que averigüemos que la entrada a la función hash fuere "freeCodeCamp.org".

Segundo, si pasamos la misma entrada a la función hash, obtenemos el mismo valor hash como la salida.

Si pasamos "freeCodeCamp.org" nuevamente a la función hash SHA-256, obtendremos la misma salida hash como nuestra llamada previa.

Tercero, dos entradas distintas nunca comparten el mismo valor hash. Inclusive el cambio más ligero en la entrada produce una salida totalmente distinta.

Supón que si proveemos "freeCodeCamp" como entrada en vez de "freeCodeCamp.org" – obtenemos una salida totalmente distinta.

Firmas Digitales

En tus vidas diarias, podrías tener que firma varios documentos. Podrían ser documentos legales, o el boletín de calificaciones de tus hijos, o tal vez algo más.

Cuando tu firma esté presente en el documento, le transmite a la otra parte que eres tú el que está de acuerdo cualquier cosa que esté escrito en ese documento.

Luego, no puedes dar marcha atrás de lo que está escrito en el documento. ¿Correcto?

De forma similar, en el mundo digital, tenemos las firmas digitales – o podemos simplemente llamarlos firmas.

Entendamos cómo funcionan las firmas usando un ejemplo. Tenemos dos usuarios llamados "Alice" y "Bob".

Bob quiere transferir algo de dinero a la cuenta bancaria de Alice. Así que Bob le pide a Alice su información de cuenta bancaria.

Alice sabe sobre las firmas digitales y decidió usar una. Al final, entenderás por qué Alice optó por una firma digital.

Antes de que Alice pueda crear una firma digital. Alice provee a Bib su clave pública (y guarda la clave privada para sí misma).

Luego Alice crea una firma digital y lo color al final del documento.

Una firma digital se crea primero al pasar el contenido del documento a una función hash criptográfica como SHA-256. En el caso de Alice, el contenido del documento es su número de cuenta bancaria.

Una vez que obtenemos el valor hash, se encripta con la clave privada de Alice. La salida de esta encriptación es la firma el cual se coloca al final del documento.

Luego esto se lo envía a Bob por Internet.

Cuando Bob recibe este documento, verifica si la firma es válida o no.

Para verificar la firma, Bob primero descifra la firma con la clave pública de Alice. Si lo recuerdas, Alice generó la firma al encriptar el valor hash.

 plaintext                         ciphertext  
     |                                 |
     |                                 |
     |                                 |
hash value --------encrypt--------> signature

Así que, cuando Bob descifra la firma, obtendrá el valor hash que Alice calculó. Llamemos a este valor hash de Alice.

 ciphertext                         plaintext  
     |                                 |
     |                                 |
     |                                 |
signature --------decrypt--------> hash value

Luego Bob toma el número de la cuenta bancaria que esta presente en el documento y lo pasa a la función hash.

Finalmente, Bob coincide el valor hash de Alice (la firma descifrada) y el valor hash que calculó. Si ambos valores hash coinciden entonces significa que la firma es válida.

Muy bien – ¿pero por qué necesitábamos hacer todo esto? ¿Qué significa si la firma es válida?

Cuando la verificación de la firma es exitosa, prueba dos cosas.

Primero, prueba que el documento ha sido enviado por Alice solamente. Nadie más podría haber enviado este documento.

La garantía de que solamente Alice ha enviado este documento viene del hecho de que fuimos capaces de descifrar la firma usando la clave pública de Alice.

Hemos aprendido de que si algo es encriptado usando una clave privada entonces puede ser descifrado solamente usando su clave pública vinculada.

Asi que, si Bob fue capaz de descifrar la firma usando la clave pública de Alice, significa que fue descifrado utilizando la clave privada de Alice, ¿correcto?

Y solamente Alice tiene acceso a su clave privada. Esto significa que, ¡Alice es la única persona quien podría haber enviado este documento!

Segundo, prueba que el contenido del mensaje no ha sido modificado por un atacante durante la transmisión en red.

Hicimos dos cosas para verificar la firma. Desciframos la firma, y nos dio el valor hash que Alice calculó. Y también hasheamos el número de cuenta bancaria recibido.

Si el valor hash que Alice caluló y el valor hash que Bob calculó son los mismos, significa que Alice y Bob dieron exactamente la misma entrada a la función hash.

Y esto significa que el número de cuenta bancaria que Alice envió y que Bob recibió son exactamente los mismos.

Si un atacante habría cambiado el número de cuenta bancaria antes de que el documento le llegara a Bob, entonces Bob hubiera recibido un número de cuenta bancaria modificado.

Cuando Bob fuera a calcular el valor hash de este número de cuenta bancaria modificado, el valor hash hubiera sido distinto de lo que Alice había calculado.

Así que mientras coincida el valor hash de Alice (firma descifrada) y el valor hash que Bob calculó, la coincidencia fallaría. Y evitaría que Bob transfiera dinero al número de cuenta bancaria errónea.

Para concluir, cuando la firma es verificada con éxito, significa que:

1. El documento es solamente de Alice.
2. El contenido del documento no fue modificado por algún tercero.

Ahora has aprendido sobre encriptación de clave simétrica, encriptación de clave asimétrica, funciones de hash criptográficas, y firmas digitales. ¡Es genial!

Hemos construido una fundación realmente sólido. Ahora entender la autenticación SSH va a ser mucho más fácil para ti.

Cómo Funciona la Autenticación SSH

Si no has configurado la autenticación SSH con Github, entonces después de terminar este artículo puedes seguir la documentación detallada de Github sobre cómo hacerlo. Por ahora, por favor quédate hasta el final.

La cruz del proceso de configuración es que crees un par de claves pública y privada en tu computadora local. Luego subes tu clave pública a tu perfil de Github – ¡y eso es todo!

Después que hemos creado nuestro par de claves pública y privada, en Ubuntu, el par de claves se almacenan dentro de la carpeta ~/.ssh.

La imagen de arriba muestra mi clave pública. Tengo esta clave pública cargada en mi perfil de Github:

Ahora, cuando ejecuto git push o cualquier otro comando que se quiera comunicar con Github, estaré autenticado usando la autenticación SSH.

SSH es un protocolo cliente-servidor. Nuestra computadora que ejecuta git push es el cliente SSH. Github es el servidor SSH.

El cliente comienza con el proceso de autenticación al solicitar nuestra clave pública que tenemos dentro de ~/.ssh.

Luego el cliente prepara un mensaje el cual tiene nuestra clave pública. Y luego el cliente genera la firma usando la clave privada correspondiente.

La clave pública y la firma se envían a Github. Al recibir este mensaje, Github hace dos cosas:

Primero, verifica si la clave pública mencionada en el mensaje se conecta a un perfil de Gihtub o no. Ya que subimos nuestra clave pública a Github, este paso se realizó con éxito.

Segundo, Github verifica la firma usando la clave pública que hemos subido.

Hemos aprendido que si la verificación de la firma termina siendo exitoso significa que solamente la persona quién está en posesión de la clave privada correspondiente podría haber enviado el mensaje.

Ya que solamente tenemos la clave privada vinculada a la clave pública cargada, esto prueba a Github que en realidad somos nosotros intentando comunicarse con Github y no un atacante.

Ahora, Github es 100% seguro que somos la persona correcta, estamos autenticados exitosamente, y a nuestro git push se le permite proceder.

Ves, se volvió fácil de entender la autenticación SSH ya que aprendiste los fundamentos.

La imagen de arriba es del cómic popular xkcd. El personaje allí (llamado Cueball) está pensando en revelar su clave privada. Espero que ahora sepas por qué está mal revelar tu clave privada.

Si revelas tu clave privada entonces alguien más puede autenticarse a Github en tu nombre. No quieres que eso suceda, ¿verdad? ;)

Así que, siempre asegúrate de mantener tu clave privada para ti mismo nada más.

Resumiendo Todo

Si has llegado hasta acá, entonces felicitaciones 🥳.

Has aprendido como funciona en realidad la autenticación SSH – cuando la firma fue verificado exitosamente por Github, le confirma a Github que somos nosotros quienes le estamos hablando, no un atacante.

A lo largo adquiriste una comprensión fundamental de la encriptación de clave simétrica, encriptación de clave asimétrica, funciones hash criptográficas y firmas digitales.

Gracias por estar conmigo en esta, espero que te vayas con algunos nuevos y valiosos aprendizajes.

Pongo ideas y recursos útiles en mi Twitter. Deberías seguirme allí. Respetaré tu tiempo.

Introducción

Git es increíble.

La mayoría de los desarrolladores de software usan Git en el día a día. Pero, ¿cuántos realmente entienden Git? ¿Sientes que sabes lo que está pasando por detrás a medida que usas Git para ejecutar varias tareas?

Por ejemplo, ¿qué sucede cuando usas git commit? ¿Qué se almacena entre las confirmaciones? ¿Es sólo un diff entre la confirmación actual y el anterior? Si es así, ¿cómo se codifica el diff? O, ¿es una copia instantánea entero cada vez que el repositorio se almacena?

La mayoría de las personas que usan Git no saben las respuestas a estas preguntas de arriba. Pero, ¿esto importa realmente? ¿Realmente tienes que saber todas esas cosas?

Yo argumentaría que sí importa. Como profesionales, deberíamos esforzarnos en entender las herramientas que usamos, especialmente si los usamos todo el tiempo, como Git.

Aún más preciso. He encontrado que entender realmente cómo funciona Git es beneficioso en muchos escenarios – si estás resolviendo conflictos de fusión, viendo cómo conducir un rebase interesante, o inclusive cuando algo va mal ligeramente.

Muchísimas veces he recibido preguntas sobre Git de gente con experiencia, ingenieros de software altamente talentosos. He visto desarrolladores maravillosos reaccionar con miedo cuando algo sucede en su historial de confirmaciones, y simplemente no saben qué hacer. Esto no tiene que ser así.

Al leer este libro, obtendrás una nueva perspectiva de Git. Te sentirás con confianza cuando trabajes con Git, y entenderás los mecanismos subyacentes de Git, al menos aquellos que son beneficiosos de entender. Le vas a captar.

Tabla de Contenidos

• Introducción
• Parte 1 - Objetos principales e Introduciendo cambios
• Capítulo 1 - Objetos de Git
• Capítulo 2 - Ramas en Git
• Capítulo 3 - Cómo registrar cambios en Git
• Capítulo 4 - ¿Cómo crear un repo desde cero?
• Capítulo 5 - Cómo trabajar con las ramas en Git – Por debajo
• Parte 2 - Ramificando e Integrando Cambios
• Capítulo 6 - Diffs y Parches
• Capítulo 7 - Entendiendo la Fusión de Git
• Capítulo 8 - Entendiendo Git Rebase
• Parte 3 - Deshacer cambios
• Capítulo 9 - Git Reset
• Capítulo 10 - Herramientas adicionales para deshacer cambios
• Capítulo 11 - Ejercicios
• Parte 4 - Herramientas de Git Fantásticas y Útiles
• Capítulo 12 - Git Log
• Capítulo 13 - Git Bisect
• Capítulo 14 - Otros comandos útiles
• Resumen
• Apéndices

¿Para quién es este Libro?

Para cualquier desarrollador de software que quiera profundizar su conocimiento sobre Git.

Si ya tienes experiencia con Git – Estoy seguro que serás capaz de profundizar tus conocimientos. Inclusive si eres nuevo en Git - empezaré con una vista general del mecanismo de Git, y los términos usados a lo largo de este libro.

Este libro es para ti. Lo escribí así para que puedas aprender más sobre Git, y también llegues a apreciar, o inclusive amar a Git.

También notarás que uso un estilo casual en todo el libro. Creo que aprender Git debe de ser intuitivo y divertido. Aprender cosas nuevas siempre es difícil, y pensé que escribir en un estilo menos casual realmente no haría un buen servicio. Y como ya mencioné - Este libro es para ti.

¿Quién soy yo?

Este libro es sobre ti, y tu jornada con Git. Pero me gustaría decirte un poco sobre por qué pienso que puedo contribuir a tu jornada.

Soy el CTO y uno de los co-fundadores de Swimm.io, una herramienta de gestión de conocimiento para código. Parte de lo que hacemos es enlazar partes del código en repositorios de Git a partes de la documentación, y luego rastrear cambios en el repositorio para actualizar la documentación si es necesario.

En Swimm, tengo que diseccionar partes de Git, entender sus mecanismos subyacentes y también ganar intuición sobre por qué se implementa Git de la manera que se hace.

Antes de fundar Swimm practiqué enseñando en muchos entornos diferentes - entre ellos, gestionar el cyber track del Desafío Tech de Israel, fundar la Academia de Seguridad de Punto de Verificación (en inglés Check Point Security Academy), y escribir un libro completo de texto.

Este libro es mi intento de aprovechar lo máximo de ambos mundos - mi experiencia de enseñanza así como mi experiencia práctica profunda con Git, y darte la mejor experiencia de aprendizaje que puedo.

El enfoque de este libro

Este no es definitivamente el primer libro sobre Git. Cuando me senté a escribirlo, tuve tres principios en mente.

1. Práctico - en este libro, aprenderás cómo lograr las cosas en Git. Cómo introducir cambios, cómo deshacerlos, y cómo arreglar las cosas cuando salen mal. Entenderás cómo funciona Git no sólo por el hecho de entender, sino con una mentalidad práctica. A veces me refiero a esto como el "principio práctico" - el cual me guía en decidir si incluyo ciertos tópicos, y en qué medida.
2. A profundidad - te sumergirás en la forma de operar de Git, entender sus mecanismos. Construirás tu entendimiento gradualmente, y siempre enlazarás tus conocimientos a escenarios reales que podrías encontrar en tu trabajo. Para alcanzar un entendimiento a profundidad, casi siempre prefiero la línea de comandos en vez de interfaces gráficas, así realmente puedes ver qué comandos estoy ejecutando.
3. Visual - a medida que me esfuerzo en proveerte con intuición, los capítulos estarán acompañados de ayudas visuales.

¿Por qué este libro está disponible públicamente?

Pienso que todos deberían tener acceso a contenido de alta calidad sobre Git, y me gustaría que este libro llegue a tantas personas como sea posible.

Si te gustaría apoyar este libro, eres bienvenido en comprar la versión física, un libro electrónico, o comprarme un café. ¡Gracias!

Videos Acompañantes

He cubierto muchos tópicos de este libro en mi canal de Youtube - @BriefVid. Eres bienvenido en verificarlos también.

A trabajar

A lo largo de este libro, mayormente usaré el singular en segunda persona - y directamente te escribiré a ti. También te pediré que trabajes, que ejecutes los comandos tú mismo, así llegas a sentir lo que es usar las cosas con Git, no sólo leerlo.

Los sentimientos de Git

A lo largo de este libro, a veces me refiero a Git con palabras tales como "cree", "piensa", o "quiere". Como puedes argumentar, Git no es humano, y no tiene sentimientos o creencias. Bueno, eso es verdad, pero para que nosotros disfrutemos al jugar con Git, y ayudarte en que disfrutes leer (y yo escribiendo), siento que referirme a Git más que sólo código lo hace muchos más divertido.

Mi configuración

Incluiré capturas de pantalla. No hay necesidad de que configures para coincidir con lo mío, pero si sientes curiosidad sobre mi configuración, entonces:

• Estoy usando Ubuntu 20.04 (WSL).
• Para mi terminal, use Oh My Zsh
• También uso plugins para Oh My Zsh, puedes seguir este tutorial en freeCodeCamp
• El alias git lol
• git-graph (mi alias es gg)

Los comentarios son bienvenidos

Este libro ha sido creado para ayudarte y las personas como tú aprendan, entiendan Git, y apliquen ese conocimiento en la vida real.

Desde el principio, pedí comentarios y fui afortunado en recibirlo de grandes personas (ve reconocimientos) para asegurarte que el libro alcanza estos objetivos. Si te gustó algo sobre este libro, sentiste que algo le faltó, o que algo necesita mejorar - Me encantaría escucharlo de ti. Por favor encuéntrame en: gitting.things@gmail.com.

Nota

Este libro es provisto gratuitamente en freeCodeCamp como se describe arriba y de acuerdo a la licencia Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

Si te gustaría apoyar este libro, eres bienvenido en comprar la versión física, una versión electrónica, o comprarme un café. ¡Gracias!

Parte 1 - Objetos Principales e Introduciendo cambios

Capítulo 1 - Objetos de Git

Es tiempo de empezar tu jornada en las profundidades de Git. En este capítulo - empezamos con lo básico - aprenderás sobre los objetos de Git más importantes, y adoptar una forma de pensar sobre Git. ¡Vamos a ello!

Git como un Sistema para mantener un Sistema de archivos

Siendo que hay diferentes formas de usar Git, adoptaré aquí una forma que he aprendido que es la más clara y útil: viendo a Git como un sistema que mantiene un sistema de archivos, y específicamente - copias instantáneas de ese sistema de archivos con el tiempo.

Un sistema de archivos con un directorio raíz (en sistemas basados en UNIX, /), el cual usualmente contiene otros directorios (por ejemplo, /usr o /bin). Estos directorios contienen otros directorios, y/o archivos (por ejemplo, /usr/1.txt). En una máquina Windows, un directorio raíz de un disco sería C:\, y un sub-directorio podría ser C:\users. Adoptaré la convención de los sistemas basados en UNIX a lo largo de este libro.

Blobs

En Git, los contenidos de los archivos son almacenados en objetos llamados blobs, abreviado para binary large objects (objetos grandes de binario).

La diferencia entre blobs y archivos es que los archivos también contienen meta-datos. Por ejemplo, un archivo "recuerda" cuando fue creado, de esa forma si tu mueves ese archivo de un directorio a otro, su tiempo de creación permanece el mismo.

Los blobs, en contraste, son sólo corrientes de binario de datos, como el contenido de un archivo. Un blob no registra su fecha de creación, su nombre, o cualquier otra cosa más que su contenido.

Cada blob en Git es identificado por su hash SHA-1. Los hashes SHA-1 consisten de 20 bytes, usualmente representados por 40 caracteres en forma hexadecimal. A lo largo de este libro a veces mostraré sólo los primeros caracteres de ese hash. Como los hashes, y específicamente los hashes SHA-1 son ubicuos en Git, es importante que entiendas las características básicas de los hashes.

Hashes

Un hash es una función determinista y matemática unidireccional.

Determinista significa que la misma entrada proveerá la misma salida. Eso es - tomas una corriente de datos, ejecutas una función hash en esa corriente, y obtienes un resultado.

Por ejemplo, si provees la función hash SHA-1 con la corriente hello, obtendrás 0xaaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d. Si ejecutas la función hash SHA-1 nuevamente, desde una máquina diferente, y le provees los mismos datos (hello), obtendrás el mismo valor.

Git usa SHA-1 como su función hash para identificar objetos. Se basa en ella siendo determinista, y de esa forma un objeto siempre tendrá el mismo identificador.

Una función unidireccional es una función que es difícil de invertir dado una entrada. Eso es, es imposible (o al menos, muy difícil) de determinar, dado el resultado de la función hash (por ejemplo 0xaaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d), qué entrada produce ese resultado (en este ejemplo hello).

De vuelta a Git

De vuelta a Git - Blobs, como cualquier otro objeto de Git, tienen hashes SHA-1 asociados a ellos.

Como dije al principio, Git puede ser visto como un sistema para mantener un sistema de archivos. Sistemas de archivos consisten en archivos y directorios. Un blob es el objeto de Git representando los contenidos de un archivo.

Árboles

En Git, el equivalente de un directorio es un árbol. Un árbol es básicamente un listado de directorios, refiriéndose a blobs, así también como otros árboles.

Los árboles son identificados por sus hashes SHA-1 también. Referirse a estos objetos, sean blobs u otros árboles, sucede por medio del hash SHA-1 de los objetos.

Considera el dibujo de arriba. Fíjate que el árbol CAFE7 se refiere al blob F92A0 como el archivo pic.png. En otro árbol, el mismo blob podría tener otro nombre - pero siempre y cuando los contenidos sean lo mismo, será el mismo objeto blob, y todavía tendrá el mismo valor SHA-1.

El diagrama de arriba es equivalente a un sistema de archivos con un directorio raíz que tiene un archivo en /test.js, y un directorio llamado /docs consistiendo de dos archivos: /docs/pic.png, y /docs/1.txt.

Confirmaciones

Ahora es tiempo de tomar una copia instantánea de ese sistema de archivos – y almacenar todos los archivos que existieron en ese tiempo, juntamente con sus contenidos.

En Git, una copia instantánea es una confirmación. Un objeto de confirmación incluye un puntero al árbol principal (el directorio raíz del sistema de archivos), así también como otros meta-datos tales como el confirmador (el usuario que autorizó la confirmación), un mensaje de la confirmación, y el tiempo de la confirmación.

En la mayoría de los casos, una confirmación también tiene uno o más confirmaciones padres – la copia instantánea anterior (o copias instantáneas). Por supuesto, los objetos de confirmación son también identificados por sus hashes SHA-1. Estos son los hashes que probablemente estás acostumbrado de ver cuando usas los comandos tales como git log.

Cada confirmación retiene la copia instantánea completa, no solo las diferencias entre sí mismo y su confirmación o confirmaciones padres.

¿Cómo puede funcionar eso? ¿No significa que Git tiene que almacenar un montón de datos para cada confirmación?

Examina lo que pasa si cambias los contenidos de un archivo. Digamos que editas el archivo 1.txt, y agregas un signo de exclamación – eso es, cambiaste el contenido de HELLO WORLD, a HELLO WORLD!.

Bueno, este cambio significa que Git crea un nuevo objeto blob, con un nuevo hash SHA-1. Esto tiene sentido, ya que sha1("HELLO WORLD") es diferente de sha1("HELLO WORLD!").

Ya que tienes un nuevo hash, entonces el listado del árbol debería también cambiar. Después de todo, tu árbol ya no apunta al blob 73D8A, sino al blob 62E7A. Desde el momento que cambies los contenidos del árbol, también cambias su hash.

Y ahora, ya que el hash de ese árbol es diferente, también necesitas cambiar el árbol padre – ya que el último ya no apunta al árbol CAFE7, sino al árbol 24601. Consecuentemente, el árbol padre también tendrá un nuevo hash.

Casi listo para crear un nuevo objeto de confirmación, y parece que vas a almacenar un montón de datos – el sistema de archivos entero, ¡una vez más! ¿Pero es eso realmente necesario?

En realidad, algunos objetos, específicamente los objetos blob, no han cambiado ya que la confirmación anterior – el blob F92A0 permaneció intacto, y así también el blob F00D1.

Así que este es el truco – siempre y cuando un objeto no cambie, Git no lo almacena nuevamente. En este caso, Git no necesita almacenar el blob F92A0 o el blob F00D1 una vez más. Git se puede referir a ellos usando solamente sus valores hash. Entonces puedes crear tu objeto de confirmación.

Ya que esta confirmación no es la primer confirmación, también tiene una confirmación padre – la confirmación A1337.

Considerando Hashes

Después de introducir blobs, árboles, y confirmaciones - considera los hashes de estos objetos. Digamos que escribí la cadena Git is awesome!, y de ahí creé un objeto blob. Tú hiciste lo mismo en tu sistema. ¿Tendríamos el mismo hash?

La respuesta es – Sí. Ya que los blobs consisten de los mismos datos, tendrán los mismos valores SHA-1.

¿Qué tal si hiciera un árbol que referencia al blob de Git is awesome!, y le diera un nombre específico y metadatos, y tú hicieras exactamente lo mismo en tu sistema? ¿Tendríamos el mismo hash?

De nuevo, sí. Ya que los objetos árboles son los mismos, tendrían el mismo hash.

¿Qué tal si creara una confirmación apuntando a ese árbol con el mensaje de confirmación Hello, y tú también hicieras lo mismo en tu sistema? ¿Tendrían el mismo hash?

En este caso, la respuesta es – No. Aunque nuestros objetos de confirmación se refieren al mismo árbol, tienen diferentes detalles de confirmación – tiempo, confirmador, y así sucesivamente.

¿Cómo son almacenados los Objetos?

Ahora entiendes el propósito de los blobs, los árboles y las confirmaciones. En los próximos capítulos, también crearás estos objetos tú mismo. A pesar de ser interesante, entender en realidad cómo estos objetos son codificados y almacenados no es vital para tu entendimiento.

Pequeña recapitulación - Objetos de Git

Para recapitular, en esta sección introdujimos tres objetos de Git:

• Blob – contenidos de un archivo.
• Árbol – un listado de directorios (de blobs y árboles).
• Confirmación – una copia instantánea del árbol de trabajo.

En el próximo capítulo, entenderemos sobre las ramas en Git.

Capítulo 2 - Las ramas en Git

En el capítulo anterior, sugerí que deberíamos ver a Git como un sistema para mantener un sistema de archivos.

Una de las maravillas de Git es que permite a múltiples personas trabajar en ese sistema de archivos, en paralelo, (mayormente) sin interferir en el trabajo de otros. La mayoría de las personas dirían que están "trabajando en la rama X." ¿Pero qué significa eso en realidad?

Una rama es sólo una referencia nombrada a una confirmación.

Siempre puedes referenciar a una confirmación por su hash SHA-1, pero los humanos usualmente prefieren otras formas de llamar a los objetos. Una rama es una forma de referenciar a una confirmación, pero realmente es eso nada más.

En la mayoría de los repositorios, la línea principal del desarrollo está hecho en una rama llamada main. Esto es sólo un nombre, y es creado cuando usas git init, haciéndolo que sea ampliamente usado. Sin embargo, podrías usar cualquier otro nombre que quisieres.

Típicamente, la rama apunta a la última confirmación en la línea de desarrollo en el que estás trabajando actualmente.

Para crear otra rama, puedes usar el comando git branch. Cuando haces eso, Git crea otro puntero. Si creaste una rama llamada test, usando git branch test, estarías creando otro puntero que apunta a la misma confirmación como la rama en la que se encuentra:

¿Cómo sabe Git la rama en que te encuentras actualmente? Mantiene otro puntero designado, llamado HEAD. Usualmente, HEAD apunta a una rama, que a su vez apunta a una confirmación. En el caso descrito, HEAD podría apuntar a main, que a su vez apunta a la confirmación B2424. En algunos casos, HEAD también puede apuntar a una confirmación directamente.

Para cambiar la rama activa a ser test, puedes usar el comando git checkout test, o git switch test. Ahora ya puedes adivinar lo que hace este comando en realidad – solo cambia a HEAD a que apunte a test.

También podrías usar git checkout -b test antes de crear la rama test, el cual es el equivalente de ejecutar git branch test para crear la rama, y luego git checkout test para mover el HEAD a que apunte a la nueva rama.

Al punto representado en el dibujo de arriba, ¿qué sucedería si hicieras algunos cambios y crearas una nueva confirmación usando git commit? ¿A qué rama será agregada la nueva confirmación?

La respuesta es la rama test, ya que éste es la rama activa (ya que HEAD apunta a éste). Después, el puntero test se moverá a la nueva confirmación agregada recientemente. Fíjate que HEAD todavía apunta a test.

Si vuelves atrás a main usando git checkout main, Git moverá el HEAD a que apunta a main nuevamente.

Ahora, si creas otra confirmación, ¿a qué rama será agregado?

Así es, será agregado a la rama main (y su padre sería la confirmación B2424).

Pequeña recapitulación - Las ramas

• Una rama es una referencia nombrada a una confirmación.
• Cuando uses git commit, Git crea un objeto de confirmación, y mueve la rama a que apunte a la confirmación creada recientemente.
• HEAD es un puntero especial que le dice a Git qué rama es la rama activa (en casos excepcionales, puede apuntar directamente a una confirmación).

En los próximos capítulos, aprenderás cómo introducir cambios a Git. Crearás un repositorio desde cero – sin usar git init, git add, o git commit. Esto te permitirá profundizar tu entendimiento de lo que está pasando por debajo cuando trabajes con Git. También crearás nuevas ramas, cambiarás ramas, y crearás confirmaciones adicionales – todo sin usar git branch o git checkout. No lo sé tú, pero yo ¡ya estoy entusiasmado!

Capítulo 3 - Cómo registrar cambios en Git

Hasta ahora, hemos aprendido sobre cuatros entidades distintas en Git:

1. Blob –  contenidos de un archivo.
2. Árbol – un lista de directorios (de blobs y árboles).
3. Confirmación – una copia instantánea del árbol de trabajo, con algunos metadatos tales como el tiempo o el mensaje de confirmación.
4. Rama – una referencia nombrada a una confirmación.

Los primeros tres son objetos, donde el cuarto es una forma de referirse a objetos (específicamente, confirmaciones).

Ahora, es tiempo de entender cómo introducir cambios en Git.

Cuando trabajas en tu código fuente, trabajas desde un directorio de trabajo. Un dir(ectorio) de trabajo (también llamado "árbol de trabajo") es cualquier directorio en tu sistema de archivos el cual tiene un repositorio asociado. Contiene las carpetas y los archivos de tu proyecto, y también un directorio llamado .git del cual hablaremos más adelante. Recuerda que dijimos que Git es un sistema para mantener un sistema de archivos. El directorio de trabajo es la raíz del sistema de archivos para Git.

Después de que haces algunos cambios, podrías querer registrarlos en tu repositorio. Un repositorio (en corto: "repo") es una colección de confirmaciones, cada uno de los cuales es un archivo de lo que el árbol de trabajo del proyecto parecía en una fecha anterior, sea en tu máquina o la de alguien más. Eso es, como dije antes, una confirmación es una copia instantánea del árbol de trabajo.

Un repositorio también incluye otras cosas además de tus archivos de código, tales como HEAD y ramas.

Fíjate las convenciones del dibujo que uso: incluyo .git dentro del directorio de trabajo, para recordarte que es una carpeta dentro de la carpeta del proyecto en el sistema de archivos. La carpeta .git en realidad contiene los objetos del repositorio, como veremos en el capítulo 4.

Hay otros sistemas de control de versión donde los cambios son confirmados directamente desde el directorio de trabajo al repositorio. En Git, este no es el caso. En sí, los cambios son primero registrados en algo llamado el índice, o el área de staging.

Ambos términos se refieren a la misma cosa, son usados frecuentemente en la documentación de Git. Usaré estos términos indistintamente a lo largo de este libro, ya que te sentirás mas cómodo con ambos.

Puedes imaginarte el agregar cambios al índice como una forma de "confirmando" tus cambios, uno por uno, antes de crear una confirmación (el cual registra todos los cambios aprobados de una sola vez).

Cuando haces checkout a una rama, Git popula el índice y el directorio de trabajo con los contenidos de los archivos ya que existen en la confirmación a la rama al cual está apuntando. Cuando usas git commit, Git crea un nuevo objeto de confirmación basado en el estado de ese índice.

Usando el índice te permite preparar cuidadosamente cada confirmación. Por ejemplo, podrías tener dos archivos con cambios en tu directorio de trabajo:

Por ejemplo, digamos que estos dos archivos son 1.txt y 2.txt. Es posible agregar solamente uno de ellos (por ejemplo, 1.txt) al índice, usando git add 1.txt:

Como resultado, el estado del índice coincide con el estado del HEAD (en este caso, "Commit 2"), con la excepción del archivo 1.txt, el cual coincide el estado de 1.txt en el directorio de trabajo. Ya que no pusiste en el área de preparación a 2.txt, el índice no incluye a la versión actualizada de 2.txt. Así que el estado de 2.txt en el índice coincide con el estado de 2.txt en el "Commit 2".

En detrás de escena - una vez que pones en el área de preparación una versión de un archivo, Git crea un objeto blob con los contenidos del archivo. Este objeto blob es agregado luego al índice. Siempre y cuando solamente modifiques el archivo en el directorio de trabajo, sin ponerlo en el área de preparación, los cambios que hagas no son registrados en los objetos blob.

Cuando consideramos la figura previa, fíjate que no dibujo la versión del área de preparación del archivo como parte del "repositorio", ya que esta representación, el "repositorio" se refiere a un árbol de confirmaciones y sus referencias, y este blob no ha sido parte de ninguna confirmación.

Ahora, puedes usar git commit para registrar el cambio a 1.txt solamente:

Usando git commit ejecuta dos operaciones principales:

1. Crea un nuevo objeto de confirmación. Este objeto de confirmación refleja el estado del índice cuando ejecutaste el comando git commit.
2. Actualiza a la rama activa para que apunte a la confirmación creada recientemente. En este ejemplo, el main ahora apunta al "Commit 3", el nuevo objeto de confirmación.

Cómo crear un repo – La Forma Convencional

Vamos a asegurarnos que entiendas cómo los términos que hemos introducidos se relacionan al proceso de crear un nuevo repositorio. Este es un vistazo rápido de alto nivel, antes de sumergirnos más profundamente en este proceso.

Inicializa un nuevo repositorio usando git init my_repo, y luego cambia tu directorio al repositorio usando cd my_repo:

Usando tree -f .git puedes ver que ejecutando git init my_repo resultó en unos pocos sub-directorios dentro de .git. (El argumento -f incluye archivos en la salida del árbol).

Nota: si estás usando Windows, ejecuta tree /f .git.

Crea un archivo dentro del directorio my_repo:

Este archivo está dentro de tu directorio de trabajo. Si ejecutas git status, verás este archivo no está rastreado:

Los archivos en tu directorio de trabajo puede ser uno de los dos estados: rastreados o no rastreados.

Los archivos rastreados son archivos que Git "conoce". Ellos estuvieron en la última confirmación, o están en el área de preparación ahora (eso es, están en el área staging).

Los archivos no rastreados son todos los demás – cualquier archivo en tu directorio de trabajo que no estuvieron en tu última confirmación, y que no están en tu área de preparación.

El nuevo archivo (f.txt) no está rastreado actualmente, ya que no lo has agregado al área de preparación, y no ha sido incluido en la confirmación anterior.

Ahora puedes agregar este archivo al área de preparación (también referido como poner en staging este archivo) usando git add f.txt. Puedes verificar que ha sido puesto en el área de preparación ejecutando git status:

Así que ahora el estado del índice coincide con el directorio de trabajo:

Ahora puedes crear una confirmación usando git commit:

Si ejecutas git status nuevamente, verás que el estado está limpio - eso es, el estado de HEAD (el cal apunta a tu confirmación inicial) equivale al estado del índice, y también el estado del directorio de trabajo. Usando git log verás en realidad que HEAD apunta a main el cual a su vez apunta a la nueva confirmación:

¿Ha cambiado algo dentro del directorio .git? Ejecuta tree -f .git para verificar:

Aparentemente, un montón ha cambiado. Es tiempo de sumergirnos más profundo en la estructura de .git y entender qué está pasando por detrás cuando ejecutas git init, git add o git commit. Eso es exactamente lo que cubrirá el próximo capítulo.

Recapitulación - Cómo registrar cambios en Git

Aprendiste sobre los tres "estados" distintos del sistema de archivos que Git mantiene:

• Dir(ectorio) de trabajo (también llamado "árbol de trabajo") - cualquier directorio en tu sistema de archivos el cual tiene un repositorio asociado.
• Índice, o el Área de preparación - un espacio de interacción para la próxima confirmación.
• Repositorio (en corto: "repo") - una colección de confirmaciones, el cual cada una es una copia instantánea del árbol de trabajo.

Cuando introduces cambios en Git, casi siempre sigue este orden:

1. Cambias el directorio de trabajo primero
2. Luego pones estos cambios en el área de preparación (o algunos de ellos) al índice
3. Y finalmente, confirmas estos cambios - de esta forma actualiza el repositorio con una nueva confirmación. El estado de esta nueva confirmación coincide con el estado del índice

¿Listo para sumergirte más profundo?

Capítulo 4 - ¿Cómo crear un repo desde cero?

Hasta ahora hemos cubiertos algunos fundamentos de Git, y ahora deberías estar listo para realmente continuar con Git.

Para entender profundamente cómo funciona Git, crearás un repositorio, pero esta vez – lo construirás desde cero. Como en otros capítulos, te animo a intentar los comandos a lo largo de este capítulo.

Cómo configurar .git

Crea un nuevo directorio, y ejecuta git status dentro:

Muy bien, parece que Git no está feliz ya que no tiene una carpeta .git todavía. Lo natural por hacer sería crear ese directorio e intentarlo otra vez:

Aparentemente, crear un directorio .git no es suficiente. Necesitas agregar algún contenido a ese directorio.

Un repositorio de Git tiene dos conceptos principales:

• Una colección de objetos – blobs, árboles, y confirmaciones.
• Un sistema de nombramiento de esos objetos – llamados referencias.

Un repositorio también podría contener otras cosas, tales como hooks, pero a lo menos – debe incluir objetos y referencias.

Crear un repositorio para los objetos en .git/objets, y un directorio para las referencias (en forma corta: "refs") en .git/refs (en sistemas Windows – .git\objects y .git\refs, respectivamente).

Un tipo de referencia son las ramas. Internamente, Git llama a las ramas por el nombre de heads. Crea un directorio para las ramas – .git/refs/heads.

Esto todavía no cambia el resultado de git status:

¿Cómo sabe Git dónde comenzar cuando busca una confirmación en el repositorio? Como expliqué antes, busca el HEAD, el cual apunta a la rama actual activa (o la confirmación, en algunos casos).

Así que, necesitas crear el HEAD, el cual es sólo un archivo que reside en .git/HEAD. Puedes aplicar lo siguiente:

En UNIX:

echo "ref: refs/heads/main" > .git/HEAD

En Windows:

echo ref: refs/heads/main > .git\HEAD

Así que ahora sabes cómo se implementa HEAD – es simplemente un archivo, y su contenido describe a qué apunta.

Siguiendo el comando de arriba, git status parece cambiar su pensamiento:

Fíjate que Git "cree" que estás en la rama llamada main, aunque no has creado esta rama. main es sólo un nombre. También puedes hacer creer a Git que estás en una rama llamada banana si quieres:

Vuelve al main, ya que continuarás trabajando (mayormente) allí a lo largo de este capítulo, sólo para aderirnos a la convención regular:

echo "ref: refs/heads/main" > .git/HEAD

Ahora que tienes tu directorio .git listo, puedes trabajar a tu manera para hacer una confirmación (de nuevo, sin usar git add o git commit).

Comandos de plomería vs comandos de porcelana en Git

A este punto, debería ser bueno hacer una distinción entre dos tipos de comandos de Git: de plomería y de porcelana. La aplicación de los términos extrañamente viene de los baños, tradicionalmente los hechos de porcelana, y la infraestructura de la plomería (las cañerías y los drenajes).

La capa de porcelana provee una interfaz amigable para el usuario en la plomería. La mayoría de la gente solamente manejan la porcelana. Aún así, cuando las cosas van (terriblemente) mal, y alguien quiere entender el por qué, tendrían que remangarse y tratar con la plomería.

Git usa esta terminología como una analogía para separar los comandos de bajo nivel que los usuarios usualmente no necesitan usar directamente (comandos "de plomería") de los comandos de alto nivel (comandos "de porcelana").

Hasta ahora, has lidiado con comandos de porcelana – git init, git add o git commit. Es tiempo de ir más profundo, y que te familiarices con algunos comandos de plomería.

Cómo crear objetos en Git

Empieza por crear un objeto y escríbelo dentro de la base de datos de los objetos de Git, que reside dentro de .git/objects. Para saber el valor del hash SHA-1 de un blob, puedes usar git hash-object. (Sí, un comando de plomería), de la siguiente forma:

En UNIX:

echo "Git is awesome" | git hash-object --stdin

En Windows:

> echo Git is awesome | git hash-object --stdin

Usando --stdin estás instruyendo a git hash-object que tome su entrada de la entrada estándar. Esto te proveerá con el valor del hash relevante:

En realidad para escribir ese blob dentro de la base de datos de objetos de Git, puedes agregar el conmutador -w por git hash-object. Después, verifica el contenido de la carpeta .git, y mira si han cambiado:

Puedes ver que el hash de tu blob es 7a9bd34a0244eaf2e0dda907a521f43d417d94f6. También puedes ver que un directorio ha sido creado como .git/objects, un directorio llamado 7a, y dentro, un archivo con el nombre de 7a9bd34a0244eaf2e0dda907a521f43d417d94f6.

Lo que Git hizo aquí es tomar los primeros dos caracteres del hash SHA-1, y usarlos como el nombre de un directorio. Los caracteres sobrantes son usados como el nombre de archivo para el archivo que en realidad contiene el blob.

¿Por qué eso es así? Considera un repositorio considerablemente grande, uno que tiene 400,000 objetos (blobs, árboles, y confirmaciones) en su base de datos. Buscar un hash dentro de esa lista de 400,000 hashes podría tomar un buen rato. Así, Git simplemente divide ese problema por 256.

Para buscar el hash de arriba, Git primero miraría el directorio llamado 7a dentro del directorio .git/objects, el cual tendría hasta 256 directorios (00 hasta FF). Luego, buscaría dentro de ese directorio, acortando la búsqueda a medida que continúa.

De vuelta al proceso de generar una confirmación. Has creado un objeto solamente. ¿Cuál es el tipo de ese objeto? Puedes usar otro comando de plomería, git cat-file -t (-t significa "type" - "tipo"), para verificar eso:

No sorprendentemente, este objeto es un blob. También puedes usar git cat-file -p (-p significa "pretty-print" - "imprimir-bonito") para ver su contenido:

Este proceso de crear un objeto blob como .git/objects usualmente sucede cuando agregas algo al área de preparación – eso es, cuando usas git add. Así que los blobs no son creados cada vez que guardes un archivo al sistema de archivos (el directorio de trabajo), sino solamente cuando lo pongas en el área de preparación.

Recuerda que Git crea un blob del archivo entero que se pone en el área de preparación. Inclusive si un solo caracter es modificado o agregado, el archivo tiene un nuevo blob con un nuevo hash (como en el ejemplo del capítulo 1 donde agregaste ! al final de la línea).

¿Habrá algún cambio a git status?

Aparentemente, no. Agregar un objeto blob a la base de datos interno de Git no cambia el estado, ya que Git no sabe de ningún archivo con seguimiento (o sin seguimiento) en esta área de preparación.

Necesitas rastrear este archivo – agregarlo al área de preparación. Para hacer eso, puedes usar otro comando de plomería, git update-index, así:

git update-index --add --cacheinfo 100644 <blob-hash> <filename>

Nota: El cacheinfo es un modo de archivo de 16-bits almacenado por Git, siguiendo el diseño de los tipos y modos de POSIX. Esto no está dentro del enfoque de este libro, ya que no es realmente importante para que hagas las cosas.

Ejecutar el comando de arriba resultará en un cambio al contenido de .git:

¿Puedes encontrar el cambio? Un nuevo archivo con el nombre de index ha sido creado. Eso es todo – el famoso índice (o área de preparación), es básicamente un archivo que reside dentro de .git/index.

Así que ahora que tu blob ha sido agregado al índice, ¿esperas que git status luzca diferente?

¡Eso es interesante! Dos cosas pasaron aquí.

Primero, puedes ver que awesome.txt aparece en verde, en el área "Changes to be committed" ("Cambios a ser confirmados"). Eso es así porque el índice ahora incluye a awesome.txt, esperando a ser confirmado.

Segundo, podemos ver que awesome.txt aparece en rojo – porque Git cree que el archivo awesome.txt ha sido eliminado, y el hecho que el archivo ha sido eliminado sino que no está en el área de preparación.

(Nota: te habrás dado cuenta que a veces me refiero a Git con palabras tales como "cree", "piensa", o "quiere". Como expliqué en la introducción de este libro - para que disfrutemos jugando con Git, y leer (y escribir) este libro, siento que referirse a Git más que sólo código lo hace mucho más divertido.)

Esto sucede ya que agregaste el blob con el contenido Git is awesome a la base de datos de los objetos, y actualizaste el índice que el archivo awesome.txt retiene el contenido de ese blob, pero en realidad nunca creaste ese archivo en el disco.

Fácilmente puedes resolver esto tomando el contenido de ese blob y escribirlo a nuestro sistema de archivos, a un archivo llamado awesome.txt:

echo "Git is awesome" > awesome.txt

Como resultado, ya no aparecerá en rojo por git status:

Así que ahora es tiempo de crear un objeto de confirmación desde tu área de preparación. Como expliqué en el capítulo 1, un objeto de confirmación tiene una referencia a un árbol, así que necesitas crear un árbol.

Puedes lograr esto usando el comando git write-tree, el cual registra los contenidos del índice en un objeto árbol. Por supuesto, puedes usar git cat-file -t para ver que en sí es un árbol:

Y puedes usar git cat-file -p para ver su contenido:

Genial, así que creaste un árbol, y ahora necesitas crear un objeto de confirmación que referencia a este árbol. Para hacer eso, puedes usar el comando:

git commit-tree <tree-hash> -m <commit message>

Ahora deberías sentirte cómodo con los comandos usados para verificar el tipo de objeto creado, e imprimir su contenido:

Fíjate que este objeto de confirmación no tiene un padre, porque no es la primer confirmación. Cuando agregas otra confirmación probablemente querrás declarar su padre – no te preocupes, lo harás así más tarde.

El último hash que tuvimos – b6d05ee40344ef5d53502539772086da14ad2b07 – es un hash de la confirmación. En realidad deberías estar acostumbrado en usar estos hashes – probablemente los ves todo el tiempo (cuando usas git log, por ejemplo). Fíjate que el objeto de confirmación apunta a un objeto de árbol, con su propio hash, el cual raramente especificas explícitamente.

¿Cambiará algo en git status?

No, nada ha cambiado. ¿Por qué es eso?

Bueno, para saber que tu archivo ha sido confirmado, Git necesita saber sobre la última confirmación. ¿Cómo sabe Git eso? Va al HEAD:

HEAD apunta a main, pero, ¿qué es main? Aún no lo has creado.

Como explicamos en el capítulo 2, una rama es simplemente una referencia nombrada a una confirmación. Y en este caso, nos gustaría que main se refiriera al objeto de confirmación con el hash b6d05ee40344ef5d53502539772086da14ad2b07.

Puedes lograr esto creando un archivo en .git/refs/heads/main, con el contenido de este hash, así:

En resumen, una rama es sólo un archivo dentro de .git/refs/heads, que contiene un hash de la confirmación a la que se refiere.

Ahora, finalmente, git status y git log parecen apreciar nuestros esfuerzos:

¡Has creado con éxito una confirmación sin usar comandos de porcelana! ¿No es genial eso?

Recapitulación - Cómo crear un repo desde cero

En este capítulo, sin miedo te sumergiste en profundidad en Git. Paraste de usar comandos de porcelana y te cambiaste a los comandos de plomería.

Al usar echo y comandos de nivel bajo tales como git hash-object, fuiste capaz de crear un blob, agregarlo al índice, crear un árbol del índice, y crear un objeto de confirmación apuntando a ese árbol.

También aprendiste que HEAD es un archivo, localizado en .git/HEAD. Las ramas son archivos también, localizados en .git/refs/heads. Cuando entiendes cómo opera Git, esas nociones abstractas de HEAD o "ramas" se vuelven muy tangibles.

En el próximo capítulo profundizarás tu entendimiento de cómo trabajan las ramas por detrás.

Capítulo 5 - Cómo trabajar con las ramas en Git – Por debajo

En el capítulo anterior creaste un repositorio y una confirmación sin usar git init, git add o git commit. En este capítulo, crearemos y cambiaremos entre ramas sin usar comandos de porcelana (git branch, git switch, o git checkout).

Es perfectamente entendible si estás emocionado, ¡yo también lo estoy!

Continuando con lo del capítulo anterior - solamente tienes una rama, llamada main. Para crear otra con el nombre de test (como el equivalente de git branch test), necesitarías crear un archivo llamado test dentro de .git/refs/heads, y el contenido de ese archivo sería el mismo hash de la confirmación al que apunta la rama main.

Si usas git log, puedes ver que esto en sí es el caso – ambos main y test apuntan a esta confirmación:

(Nota: si ejecutas este comando y no ves una salida válida, podrías haber escrito algo más que el hash de la confirmación en .git/refs/heads/test.)

Siguiente, cambiar a nuestra rama creada recientemente (el equivalente de git checkout test). ¿Cómo harías eso? Intenta responderte a ti mismo antes de que nos movamos al siguiente párrafo.

Para cambiar la rama activa, debería cambiar el HEAD a que apunte a tu nueva rama:

Como puedes ver, git status confirma que HEAD ahora apunta a test, el cual es, por lo tanto, la rama activa.

Ahora puedes usar los comandos que ya has usado en el capítulo anterior para crear otro archivo y agregarlo al índice:

Siguiendo los comandos de arriba, tu:

• Creas un blob con el contenido de Another file (usando git hash-object).
• Agregas al índice con el nombre de another_file.txt (usando git update-index).
• Creas un archivo correspondiente en el disco con el contenido del blob (usando git cat-file -p).
• Creas un objeto árbol representando al índice (usando git write-tree).

Ahora es tiempo de crear una confirmación que referencie a este árbol. Esta vez, también deberías especificar el padre de esta confirmación – el cual debería ser la confirmación anterior. Especificas el padre usando el argumento -p de git commit-tree:

Hemos creado una confirmación, con un árbol así también como un padre, como puedes ver:

¿git log nos mostrará la nueva confirmación?

Como puedes ver, git log no nos muestra nada nuevo. ¿Por qué es eso?

Recuerda que git log rastrea las ramas para encontrar confirmaciones relevantes para mostrar. Nos muestra ahora test y la confirmación a la que apunta, y también nos muestra a main el cual apunta a la misma confirmación.

Así es – necesitas hacer que test apunte al nuevo objeto de confirmación. Puedes hacer eso cambiando el contenido de .git/refs/heads/test:

echo 22267a945af8fde78b62ee7f705bbecfdd276b3d > .git/refs/heads/test

Y ahora si ejecutas git log:

¡Funcionó!

git log va al HEAD, el cual le dice a Git que vaya a la rama test, el cual apunta a la confirmación 222..3d, el cual se enlaza a su confirmación padre b6d..07.

Admira la belleza de Git 😊

Al inspeccionar la carpeta de tu repositorio, puedes ver que tienes seis objetos distintos en la carpeta .git/objects - estos son los dos blobs que creaste (uno para awesome.txt y uno para file.txt), dos objetos de confirmación ("Commit 1" y "Commit 2"), y los tres objetos - cada uno apuntado por uno de los objetos de confirmación.

También tienes a .git/HEAD que apunta a la rama o confirmación activa, y dos ramas - dentro de .git/refs/heads.

Recapitulación - Cómo trabajar con las ramas en Git – Por debajo

En este capítulo entendiste cómo trabajan realmente las ramas en Git.

Las cosas principales que cubrimos:

• Una rama es un archivo en la carpeta .git/refs/heads, donde el contenido del archivo es una valor SHA-1 de una confirmación.
• Para crear una nueva rama, Git simplemente crea un nuevo archivo en la carpeta .git/refs/heads con el nombre de la rama - por ejemplo, .git/refs/heads/my_branch para la rama my_branch.
• Para cambiar la rama activa, Git modifica el contenido de .git/HEAD para referirse a la nueva rama activa. .git/HEAD también podría apunta a un objeto de confirmación directamente.
• Cuando se confirma usando git commit, Git crea un objeto de confirmación, y también mueve la rama actual (eso es, el contenido del archivo en .git/refs/heads) a que apunte al objeto de confirmación recientemente creado.

Parte 1 - Resumen

Esta parte te introdujo lo interno de Git. Empezamos cubriendo los objetos básicos – blobs, árboles, y confirmaciones.

Aprendiste que un blob contiene el contenido de un archivo. Un árbol es un listado de directorios, conteniendo blobs y/o sub árboles. Una confirmación es una copia instantánea de nuestro directorio de trabajo, con algunos meta datos tales como el tiempo o el mensaje de confirmación.

Aprendiste sobre las ramas, viendo que no son más que una referencia nombrada a una confirmación.

Aprendiste el proceso de registrar cambios en Git, y que involucra el directorio de trabajo, un directorio que tiene un repositorio al que se asocia, el área de preparación (índice) el cual contiene el árbol para la próxima confirmación, y el repositorio, el cual es una colección de confirmaciones y referencias.

Clarificamos cómo estos términos se relacionan a los comandos de Git que conocemos al crear un nuevo repositorio y confirmando un archivo usando los comandos bien conocidos git init, git add y git commit.

Luego creaste un nuevo repositorio desde cero, usando echo y comandos de bajo nivel tales como git hash-object. Creaste un blob, le agregaste al índice, creaste un objeto de árbol representando al índice, e inclusive creaste un objeto de confirmación apuntando a ese árbol.

También fuiste capaz de crear y cambiar entre ramas modificando los archivos directamente. ¡Felicitaciones para aquellos que lo intentaron por sí mismos!

Todo junto ya, después de seguirme en esta parte, deberías sentir que has profundizado tu entendimiento de lo que está pasando por debajo cuando trabajas con Git.

La próxima parte explorarás diferentes estrategias para integrar cambios cuando se trabaja en diferentes ramas en Git - específicamente, merge y rebase.

Parte 2 - Ramificando e Integrando Cambios

Capítulo 6 - Diffs y Parches

En la parte 1 aprendiste cómo funciona Git por detrás, los diferentes objetos de Git, y cómo crear un repo desde cero.

Cuando los equipos trabajan con Git, introducen secuencias de cambios, usualmente en ramas, y luego necesitan combinar diferente historiales de cambios juntos. Para realmente entender cómo se logra esto, deberías aprender cómo trata Git a los diffs y a los parches. Luego aplicarás tus conocimientos para entender el proceso de merge y rebase.

Muchos de los procesos interesantes de Git como fusión, rebasing, o inclusive confirmar están basados en los diffs y parches. Los desarrolladores trabajan con diffs todo el tiempo, estés usando Git directamente o basándote en la vista diff del IDE. En este capítulo, aprenderás cómo son los diffs y parches, su esctructura, y cómo aplicar parches.

Como recordatorio del capítulo de Objetos de Git, una confirmación es una copia instantánea del árbol de trabajo en un cierto punto en el tiempo, además de algunos metadatos.

Aún así, es realmente difícil entender las confirmaciones individuales al mirar el árbol entero de trabajo. En sí, es más útil mirar cuán diferente es una confirmación de su confirmación padre, eso es, la diff entre estas confirmaciones.

Así que, ¿a qué me refiero cuando digo "diff"? Empecemos con algo de historia.

La historia de diff de Git

El diff de Git está basado en la utilidad diff de sistemas UNIX. diff fue desarrollado a principios de los '70 en el sistema operativo Unix. La primer versión lanzada se envió con la Quinta Edición de Unix en 1974.

git diff es un comando que toma dos entradas, y calcula la diferencia entre ellos. Las entradas pueden ser confirmaciones, pero también archivos, e inclusive archivos que nunca han sido introducidos al repositorio.

Esto es importante - git diff calcula la diferencia entre dos cadenas, el cual la mayor de las veces llega a consistir en código, pero no necesariamente.

Tiempo de manos a la obra

Como siempre, se te anima a que ejecutes los comandos tu mismo al leer este capítulo. A menos que se diga otra cosa, usaré el siguiente repositorio:

https://github.com/Omerr/gitting_things_repo.git

Lo puedes clonar localmente y tener el mismo punto de comienzo que estoy usando para este capítulo.

Considera este archivo de texto corto en mi máquina, llamado file.txt, el cual consiste de 6 líneas:

Ahora, modifica este archivo un poco. Quita la segunda línea, e inserta una nueva línea como la línea cuatro. Agrega un signo de admiración (!) al final de la última línea, así obtienes este resultado:

Guarda este archivo con un nuevo nombre, new_line.txt.

Ahora puedes ejecutar git diff para calcular la diferencia entre los archivos así:

git diff --no-index file.txt new_file.txt

(Explicaré el argumento --no-index de este comando más tarde. Por ahora es suficiente saberlo para que nos permita comparar dos archivos que no son partes de un repositorio de Git.)

La salida de git diff muestra bastante cosas.

Enfócate en la parte empezando con This is a file. Puedes ver que la línea agregada (// new test) es precedida por un signo +. La línea eliminada es precedida por un símbolo -.

Curiosamente, fíjate que Git ve a la línea modificada como una secuencia de dos cambios - borrar una línea y agregar una nueva. Así que el parche incluye eliminar la última línea, y agregar una nueva línea que es igual a esa línea, con la suma de un !.

Ahora sería bueno discutir los términos "patch" y "diff". Estos dos son usados con frecuencia indistintamente, aunque hay una distinción, al menos históricamente.

Un diff muestra las diferencias entre dos archivos, o copias instantáneas, y puede ser bastante mínimo en hacerlo así. Un patch (parche) es una extensión de un diff, aumentado con más información tales como líneas de contexto y nombre de archivos, el cual le permite ser aplicado más ampliamente. Es un documento de texto que describe cómo alterar un archivo existente o base de código.

En estos días, el programa diff de Unix, y git diff, pueden producir parches de varios tipos.

Un parche es una representación compacta de las diferencias entre dos archivos. Describe cómo convertir un archivo en otro.

En otras palabras, si aplicas las "instrucciones" producidas por git diff en file.txt - eso es, quitar la segunda línea, insertar // new test como la cuarta línea, quitar la última línea, y agregar una línea con el mismo contenido y ! - tendrás el contenido de new_file.txt.

Otra cosa importante a notar es que un parche es asimétrico: el parche de file.txt a new_file.txt no es el mismo que el parche para la otra dirección. Generar un parche entre new_file.txt y file.txt, en este orden, significaría exactamente las instrucciones opuestas que antes - agregar la segunda línea en vez de quitarla, y así sucesivamente.

Inténtalo:

git diff --no-index new_file.txt file.txt

El formato del parche usa contexto, así también como números de líneas, para localizar diferentes regiones de archivos. Esto permite a un parche ser aplicado a alguna versión más antigua o más reciente de la primera línea a aquel del que se derivó, siempre y cuando el programa que se aplica aún pueda localizar el contexto del cambio. Veremos cómo son usados exactamente.

La Estructura de un Diff

Es tiempo de indagar más profundamente.

Genera un diff de file.txt a new_file.txt nuevamente, y considera la salida más cuidadosamente:

git diff --no-index file.txt new_file.txt

La primer línea introduce los archivos comparados. Git siempre le da a un archivo el nombre de a, y al otro el nombre de b. Así que en este caso file.txt se llama a, donde new_file.txt se llama b.

Luego la segunda línea, comenzando con index, incluye los SHAs del blob de estos archivos. Así que aunque en nuestro caso inclusive no se guardan dentro de un repo de Git, Git muestra sus valores SHA-1 correspondientes.

El tercer valor en esta línea, 100644, es el "modo bits", indicando que esto es un archivo "regular": no ejecutable y no es un enlace simbólico.

El uso de dos puntos (..) aquí entre los SHAs del blob es sólo como un separador (a diferencia de otros casos donde se usa dentro de Git).

Otras líneas de encabezado pueden indicar el modo bits antiguo y nuevo si han cambiado, nombres de archivos antiguos y nuevos si los archivos fueron renombrados, y así sucesivamente.

Los SHAs del blob (también llamados "blob IDs") son útiles si este parche luego se aplica por Git al mismo proyecto y hay conflictos al aplicarse. Entenderás mejor qué significa esto cuando aprendas sobre las fusiones en el próximo capítulo.

Luego de los IDs del blob, tenemos dos líneas: una comenzando con signos -, y los otros comenzando con signos +. Este es el encabezado "diff unificado" tradicional, de nuevo mostrando los archivos siendo comparados y la dirección de los cambios: signos - muestra líneas en la versión A que faltan de la versión B, y signos - muestra líneas que faltan en la versión A pero que están presentes en el B.

Si el parche de este archivo estuviera siendo agregado o eliminado en su totalidad, entonces uno de estos serían /dev/null para señalar eso.

Considera el caso donde eliminas un archivo:

rm awesome.txt

Y luego usa git diff:

La versión A, representando el estado del índice, es actualmente awesome.txt, comparado al directorio de trabajo donde este archivo no existe, así que es /dev/null. Todas las líneas son precedidas por signos - ya que existen solamente en la versión A.

Por ahora, deshace la eliminación (más sobre deshaciendo cambios en la Parte 3):

git restore awesome.txt

Volviendo al diff con el que comenzamos:

Después de este encabezado diff unificado, llegamos a la parte principal del diff, consistiendo de "secciones de diferencia", también llamados "hunks" o "chunks" en Git. Fíjate que estos términos son usados indistintamente, y podrías encontrarte con uno de ellos en la documentación y tutoriales de Git, así también como código fuente de Git.

Cada hunk comienza con una sola línea, comenzando con dos signos @. Estos signos son seguidos en la mayoría de veces por cuatro números, y luego un encabezado para el chunk - el cual es una suposición educada por Git. Usualmente, incluirá el comienzo de una función o una clase, cuando fuese posible.

En este ejemplo no incluye nada ya que este es un archivo de texto, así que considera otro ejemplo por un momento:

git diff --no-index example.py example_changed.py

En la imagen de arriba, el encabezado del hunk incluye el comienzo de la función que incluye las líneas cambiados - def example_function(x).

De vuelta a nuestro ejemplo previo:

Después de dos signos @, encontrarás cuatro números:

Los primeros números son precedidos por un signo - ya que se refieren a file A. El primer número representa el número de línea correspondiente a la primer línea en file A a la que este hunk se refiere. En el ejemplo de arriba, es 1, lo que significa que la línea This is a file corresponde al número de línea 1 en la versión de file A.

Este número es seguido por una coma (,), y luego el número de líneas del que este chunk consiste en el file A. Este número incluye todas las líneas de contexto (las líneas precedidas con un espacio en el diff), o líneas marcadas con un signo -, ya que son parte de file A, pero no las líneas marcadas con un signo +, ya que no existen en file A.

En nuestro ejemplo, este número es 6, contando la línea de contexto This is a file, la línea - es It has a nice poem:, luego las tres líneas de contexto, y por último Are belong to you.

Como puedes ver, las líneas que comienzan con un caracter de espacio son líneas de contexto, lo que significa que aparecen como se muestran en ambos file A y file B.

Luego, tenemos un signo + para marcar a los dos números que se refieren a file B. Primero, está el número de línea correspondiente a la primer línea en file B, seguido del número de líneas del que este chunk consiste en file B.

Este número incluye todas las líneas de contexto, así también como las líneas marcadas con el signo +, ya que son parte de file B, pero no las líneas marcadas con un signo -.

Estos cuatros números son seguidos por dos signos @ adicionales.

Después del encabezado del chunk, obtenemos las líneas actuales - sean las líneas de contexto, - o +.

Típicamente y por defecto, un hunk comienza y termina con tres líneas de contexto. Por ejemplo, si modificas las líneas 4-5 en un archivo con diez líneas:

• Línea 1 - línea de contexto (antes de las líneas cambiadas)
• Línea 2 - línea de contexto (antes de las líneas cambiadas)
• Línea 3 - línea de contexto (antes de las líneas cambiadas)
• Línea 4 - línea cambiada (antes de las líneas cambiadas)
• Línea 5 - otra línea cambiada
• Línea 6 - línea de contexto (después de las líneas cambiadas)
• Línea 7 - línea de contexto (después de las líneas cambiadas)
• Línea 8 - línea de contexto (después de las líneas cambiadas)
• Línea 9 - esta línea no será parte del hunk

Así que por defecto, cambiar las líneas 4-5 resulta en un hunk consistiendo de las líneas 1-8, eso es, tres líneas antes y tres líneas después de las líneas modificadas.

Si ese archivo no tiene nueve líneas, sino seis líneas - entonces el hunk contendrá solamente una línea de contexto después de las líneas cambiadas, y no tres. De forma similar, si cambias la segunda línea de un archivo, entonces habría solamente una línea de contexto antes de las líneas cambiadas.

Cómo producir diffs

El último ejemplo que consideramos muestra un diff entre dos archivos. Un solo archivo parche puede contener las diferencias para cualquier número de archivos, y git diff produce diffs para todos los archivos alterados en el repositorio en un solo parche.

Frecuentemente, verás la salida de git diff mostrando dos versiones del mismo archivo y la diferencia entre ellos.

Para demostrar, considera el estado en otra rama llamada diffs:

git checkout diffs

De nuevo, te animo a ejecutar los comandos conmigo - asegúrate de clonar el repositorio de

https://github.com/Omerr/gitting_things_repo.git

En el estado actual, el directorio activo es un repositorio de Git, con una estado limpio:

Toma un archivo existente, my_file.py:

Y cambia la segunda línea de print('An example function!') a print('An example function! And it has been changed!'):

Guarda tus cambios, pero no lo pongas en el área de preparación o no lo confirmes. Luego, ejecuta git diff:

La salida de git diff muestra la diferencia entre las versiones de my_file.py en el área de preparación, el cual en este caso es el mismo que la última confirmación (HEAD), y la versión en el directorio de trabajo.

Cubrí los términos "directorio de trabajo", "área de preparación", y "confirmación" en el capítulo de objetos de Git, así que échale un vistazo en caso que te gustaría refrescar tu memoria. Como un recordatorio, los términos "área de preparación" e "índice" son intercambiables, y ambos son ampliamente usados.

Para ver la diferencia entre el directorio de trabajo y el área de preparación, usa git diff, sin ningún argumento adicional.

Como puedes ver, git diff aquí lista file A y file B apuntando a my_file.py. file A aquí se refiere a la versión de my_file.py en el área de preparación, donde file B se refiere a su versión en el directorio de trabajo.

Fíjate que si modificas my_file.py en un editor de texto, y no guardas el archivo, entonces git diff no estará al tanto de los cambios que has hecho. Esto se debe a que no han sido guardados en el directorio de trabajo.

Podemos proveer unos pocos cambios a git diff para obtener el diff entre el directorio de trabajo y una confirmación específica, o entre el área de preparación y la última confirmación, o entre dos confirmaciones, y así sucesivamente.

Primero crea un nuevo archivo, new_file.txt, y guárdalo:

Actualmente el archivo está en el directorio de trabajo, y actualmente está sin seguimiento en Git.

Ahora pónlo en el área de preparación y confirma este archivo:

git add new_file.txt
git commit -m "Commit 3"

Ahora, el estado de HEAD es el mismo que el estado del área de preparación, así también como el árbol de trabajo:

Luego, edita new_file.txt agregando una nueva línea al principio y otra nueva línea al final:

Como resultado, el estado es como sigue:

Un lindo truco sería usar git add -p, el cual te permite dividir los cambios inclusive dentro de un archivo, y considerar cuáles te gustaría ponerlos en el área de preparación.

En este caso, agrega la primera línea al índice, pero no la última línea. Para hacer eso, puedes dividir el hunk usando s, luego acepta el primer hunk al área de preparación (usando y), y no la segunda parte (usando n).

Si no estás seguro qué significa cada letra, siempre puedes usar un ? y Git te dirá.

Así que ahora el estado en HEAD están sin ninguna de esas nuevas líneas. En el área de preparación tienes la primer línea pero no la última línea, y en el directorio de trabajo tienes las dos nuevas líneas.

Si usas git diff, ¿qué sucederá?

Bueno, como se dijo antes, obtienes el diff entre el área de preparación y el árbol de trabajo.

¿Qué sucede si quiere obtener el diff entre el HEAD y el área de preparación? Para eso, puedes usar git diff --cached:

¿Y qué pasa si quieres la diferencia entre el HEAD y el árbol de trabajo? Para eso puedes ejecutar git diff HEAD:

Para resumir los diferentes cambios para git diff que hemos visto hasta ahora, aquí hay un diagrama:

Como un recordatorio, al principio de este capítulo usaste git diff --no-index. Con el conmutador --no-index, puedes comparar dos archivos que no son parte del repositorio - o de cualquier área de preparación.

Ahora, confirma los cambios que tienes en el área de preparación:

git commit -m "Commit 4"

Para observar el diff entre esta confirmación y su confirmación padre, puedes ejecutar el siguiente comando:

git diff HEAD~1 HEAD

Por cierto, puedes omitir el 1 de arriba y escribir HEAD~, y obtener el mismo resultado. Usando 1 es la forma explícita para expresar que te refieres al primer padre de la confirmación.

Fíjate que escribir la confirmación padre aquí, HEAD~1, primero resulta en un diff mostrando cómo obtener de la confirmación padre a la confirmación actual. Por supuesto, podría también generar el diff en reversa al escribir:

git diff HEAD HEAD~1

Para resumir todos los diferentes cambios para git diff que cubrimos en esta sección, mira este diagrama:

Una forma corta de ver el diff entre una confirmación y su padre es usando git show, por ejemplo:

git show HEAD

Esto es lo mismo que escribir:

git diff HEAD~ HEAD

Ahora podemos actualizar nuestro diagrama:

Puedes volver a este diagrama como una referencia cuando sea necesario.

Como un recordatorio, las confirmaciones de Git son copias instantáneas - del directorio de trabajo completo del repositorio, en un cierto punto en el tiempo. A pesar de todo, a veces no es útil considerar a una confirmación como una copia instantánea completa, sino más bien por los cambios que esta confirmación específica introdujo. En otras palabras, por el diff entre una confirmación padre a la confirmación siguiente.

Como aprendiste en el capítulo de Objetos de Git, Git almacena las copias instantáneas enteros. El diff es generado dinámicamente de los datos de la copia instantánea - al comparar los árboles principales de la confirmación y su padre.

Por supuesto, Git puede comparar cualquiera de las dos copias instantáneas en el tiempo, no sólo confirmaciones adyacentes, y también generar un diff de archivos que no son incluidos en un repositorio.

Cómo aplicar Parches

Al usar git diff puedes ver un parche que Git genera, y luego puedes aplicar este patch usando git apply.

Nota Histórica

En realidad, compartir parches solía ser la principal forma de compartir código al comienzo del código abierto. Pero ahora - virtualmente todos los proyectos se han movido a compartir confirmaciones de Git directamente a través de pull requests (llamados "merge requests - peticiones de fusión" en algunas plataformas).

El mayor problema con usar parches es que es difícil de aplicar un parche cuando tu directorio de trabajo no coincide con la confirmación previa del emisor. Perder el historial de la confirmación lo vuelve difícil para resolver conflictos. Entenderás mejor esto a medida que indagues más profundamente en el proceso de git apply, especialmente en el próximo capítulo donde cubrimos las fusiones.

Un Simple Parche

¿Qué significa aplicar un parche? ¡Es tiempo de intentarlo!

Toma la salida de git diff:

git diff HEAD~1 HEAD

Y almacénalo en un archivo:

git diff HEAD~1 HEAD > my_patch.patch

Usa reset para deshacer la última confirmación:

git reset --hard HEAD~1

No te preocupes del último comando - te lo explicaré en detalle en la Parte 3, donde discutimos deshacer cambios. En breve, nos permite "resetear" el estado a donde HEAD está apuntando, así también como el estado del índice y del directorio de trabajo. En el ejemplo de arriba, todos están puestos al estado de HEAD~1, o "Confirmación 3" en el diagrama.

Así que después de ejecutar el comando reset, los contenidos del archivo son como sigue (el estado de "Confirmación 3"):

nano new_file.txt

Y aplicarás este parche que recién has guardado:

nano my_patch.patch

Este parche le dice a Git que encuentre las líneas:

This is a new file
With new content!

Esas líneas solían ser el número de línea 1 y número de línea 2 en new_file.txt, y agrega una línea con el contenido START! justo arriba de ellos.

Ejecuta este comando para aplicar el parche:

git apply my_patch.patch

Y como resultado, obtienes esta versión de tu archivo, justo como la confirmación que has creado antes:

nano new_file.txt

Entendiendo la Líneas de Contexto

Para entender la importancia de las líneas de contexto, considera un escenario más avanzado. ¿Qué sucede si los números de líneas han cambiado desde que creaste el archivo parche?

Para probar, comienza por crear otro archivo:

nano test.text

Pónlo en el área de preparación y confirma este archivo:

git add test.txt

git commit -m "Test file"

Ahora, cambia este archivo al agregar una nueva línea, y también eliminando la línea antes de la última:

Observa la diferencia entre la versión original del archivo y la versión incluyendo tus cambios:

git diff -- test.txt

(Usando --test.txt le dice a Git que ejecute el comando diff, tomando en consideración solamente a test.txt, así no obtienes el diff para otros archivos.)

Almacena este diff en un archivo parche:

git diff -- test.txt > new_patch.patch

Ahora, resetea tu estado a ese antes de introducir los cambios:

git reset --hard

Si llegaras a aplicar new_patch.patch ahora, simplemente funciona.

Ahora consideremos un caso más interesante. Modifica a test.txt nuevamente al agregar una nueva línea al principio:

Como resultado, los números de líneas son diferentes de la versión original donde el parche ha sido creado. Considera el parche que creaste antes:

Asume que la línea With more text es la segunda línea en test.txt, el cual no es más el caso. Así que... ¿funcionará git apply?

git apply new_patch.patch

¡Funcionó!

Por defecto, Git busca las 3 líneas de contexto antes y después de cada cambio introducido en el parche - como puedes ver, son incluidos en el archivo parche. Si tomas tres líneas antes y después de la línea agregada, y tres líneas antes y después de la línea eliminada (en realidad solamente una línea después, ya que no existen otras líneas) - llegas al archivo parche. Si todas estas líneas existen - entonces aplicar el parche funciona, inclusive si los números de línea cambiaron.

Resetea el estado de nuevo:

git reset --hard

¿Qué sucede si cambias una de las líneas de contexto? Intenta cambiando la línea With more text a With more text!:

Y ahora:

git apply new_patch.patch

Bueno, no. El parche no se aplica. Si no estás seguro por qué, o solo quieres entender mejor el proceso que Git está realizando, puedes agregar el argumento --verbose a git apply, así:

git apply --verbose new_patch.patch

Parece que Git buscó líneas del archivo, incluyendo la línea "With more text", justo antes de la línea "It has some really nice lines". Esta secuencia de líneas ya no existen en el archivo. Ya que Git no puede encontrar esta secuencia, no puede aplicar el parche.

Como se mencionó antes, por defecto, Git busca 3 líneas de contexto antes y después de cada cambio introducido en el parche. Si las tres líneas circundantes no existen, Git no puede aplicar el parche.

Le puedes pedir a Git que se base en menos líneas de contexto, usando el argumento -C. Por ejemplo, para pedir a Git que busque 1 línea de contexto circundante, ejecuta el siguiente comando:

git apply -C1 new_patch.patch

¡El parche se aplica!

¿Por qué es eso? Considera el parche nuevamente:

Cuando se aplica el parche con la opción -C1, Git está buscando las líneas:

Like this one
And that one

para agregar la línea !!!This is the new line!!! entre estas dos líneas. Estas líneas existen (e, importantemente, aparecen justo después de la otra). Como resultado, Git puede agregar la línea entre ellos con éxito, aunque los números de línea cambiaron.

De manera similar, Git buscaría las líneas:

How wonderful
So we are writing an example
Git is awesoome!

Ya que Git puede encontrar estas líneas, Git puede eliminar el del medio.

Si cambiamos una de estas líneas, digamos, cambiamos "How wonderful" a "How very wondeful", entonces Git no sería capaz de encontrar la cadena de arriba, y así el parche no se aplicaría.

Recapitulando - Git Diff y Patch

En este capítulo, aprendiste qué es un diff, y la diferencia entre un diff y un parche. Aprendiste cómo generar varios parches usando diferentes conmutadores para git diff. También aprendiste cómo luce la salida de git diff, y cómo se construye. Por último, aprendiste cómo se aplican los patches, y específicamente la importancia del contexto.

Entender los diff es un hito importante para entender muchos otros procesos dentro de Git - por ejemplo, fusionando o rebasing, los cuales exploraremos en los próximos capítulos.

Capítulo 7 - Entendiendo la Fusión de Git

Al leer este capítulo, vas a entender realmente git merge, una de las operaciones más comunes que ejecutarás en tus repositorios de Git.

¿Qué es un Merge (Fusión) en Git?

Fusionar es el proceso de combinar los cambios recientes de varias ramas en una sola nueva confirmación. Esta confirmación apunta a estas ramas.

De una forma, fusionar es el complemento de ramificación en control de versiones: una rama te permite trabajar de manera simultánea con otros en un conjunto particular de archivos, donde una fusión te permite luego combinar trabajos separados en ramas que difieren de una confirmación padre en común.

Muy bien, vamos poco a poco.

Recuerda que en Git, una rama es sólo un nombre que apunta a una confirmación única. Cuando pensamos sobre las confirmaciones como si estuvieran sólo "en" una rama específica, en realidad son accesibles a través de la cadena principal desde la confirmación a la que la rama está apuntando.

Eso es, si consideras este gráfico de confirmación:

Ves la rama feature_1, el cual apunta a una confirmación con el valor de SHA-1 de ba0d2. Como en los capítulos previos, solamente escribo los primeros 5 dígitos del valor de SHA-1 para brevedad.

Fíjate que la confirmación 54a9d está también "en" esta rama, ya que es la confirmación antecesora de bad0d2. Si comienzas desde el puntero de feature_1, llegas a ba0d2, el cual luego apunta a 54a9d. Puedes continuar en la cadena de padres, y todas estas confirmaciones accesibles son considerados estar "en" el feature_1.

Cuando fusionas con Git, fusionas confirmaciones. Casi siempre, fusionamos dos confirmaciones al referirnos a ellos con los nombres de rama a los que apuntan. De esa forma decimos que "fusionamos ramas" - aunque por debajo, en realidad fusionamos confirmaciones.

Tiempo de manos a la obra

Para este capítulo, usaré el siguiente repositorio:

https://github.com/Omerr/gitting_things_merge.git

Como en capítulos previos, te animo a clonarlo localmente y tener el mismo punto de comienzo que estoy usando para este capítulo.

Muy bien, digamos que tenemos este simple repositorio aquí, con una rama llamada main, y unas pocas confirmaciones con los mensajes de confirmación de "Commit 1", "Commit 2", y "Commit 3":

Luego, crea una rama feature al escribir git branch new_feature:

Y cambia a HEAD para que apunte a esta nueva rama, usando git checkout new_feature (o git switch new_feature). Puedes ver la salida usando git log:

Como recordatorio, podrías también escribir git checkout -b new_feature, el cual crearía una nueva rama y cambiar el HEAD a que apunte a esta nueva rama.

Si necesitas un recordatorio sobre las ramas y cómo son implementados por debajo, por favor mira el capítulo 2. Sí, míralo. 😇

Ahora, en la rama new_feature, implementa una nueva característica. En este ejemplo, editaré un archivo que ya existe que luce así antes de editarlo:

Y ahora lo editaré para que incluya una nueva función:

Y afortunadamente, este no es un libro de programación, así que esta función es correcta 😇

Luego, colócalo en el área de preparación y confirma esta confirmación:

git add code.py

git commit -m "Commit 4"

Viendo al historial, tienes el branch new_feature, ahora apuntando a "Commit 4", el cual apunta a su antecesor, "Commit 3". La rama principal también está apuntando a "Commit 3".

¡Es tiempo de fusionar la nueva característica! Eso es, fusionar estas dos ramas, main y new_feature. O, en la jerga de Git, fusionar new_feature dentro de main. Esto significa fusionar "Commit 4" y "Commit 3". Esto es muy trivial, ya que después de todo, "Commit 3" es un ancestro de "Commit 4".

Verifica la rama principal (con git checkout main), y ejecuta la fusión usando git merge new_feature:

Ya que new_feature en realidad nunca difirió de main, Git podría realizar una fusión directa. Así que, ¿qué pasó aquí? Considera el historial:

Aunque usaste git merge, no hubo una fusión en sí aquí. En realidad, Git hizo algo muy sencillo - resetea la rama principal para que apunte a la misma confirmación como la rama new_feature.

En caso que no quieres que eso suceda, sino que quieres que Git realmente realice una fusión, podrías cambiar la configuración de Git, o ejecutar el comando de fusión con el argumento --no-ff.

Primero, deshace la última confirmación:

git reset --hard HEAD~1

Recordatorio: si esta forma de usar reset no te queda claro, no te preocupes - los cubriremos en detalle en la Parte 3. No es crucial para esta introducción de merge. Por ahora, es importante entender que básicamente deshace la operación de fusión.

Sólo para clarificar, ahora si verificas a new_feature nuevamente:

git checkout new_feature

El historial luciría igual como antes de la fusión:

Luego, realiza la fusión con el argumento --no-fast-forward (en corto --no-ff):

git checkout main
git merge new_feature --no-ff

Ahora, si miramos el historial usando git lol:

(Recordatorio: git lol es un alias que agregué a Git para ver visiblemente el historial de una manera gráfica. Lo puedes encontrar, junto con los otros componentes de mi configuración, en la parte de Mi Configuración del capítulo de Introducción.)

Considera este historial, puedes ver que Git creó una nueva confirmación, una confirmación de fusión.

Si consideras esta confirmación un poco más de cerca:

git log -n1

Verás que esta confirmación en realidad tiene dos padres - "Commit 4", el cual fue la confirmación a la que new_feature apuntó cuando ejecutaste git merge, y "Commit 3", el cual fue la confirmación a la que main apuntó.

Una confirmación de fusión tiene dos padres: las dos confirmaciones que fusionó.

La confirmación de fusión nos muestra el concepto de fusión bastante bien. Git toma dos confirmaciones, usualmente referenciados por dos ramas diferentes, y los fusiona juntos.

Después de la fusión, comenzaste el proceso desde main, estás todavía en main, y el historial de new_feature ha sido fusionado dentro de esta rama. Ya que comenzaste con main, luego "Commit 3", a la que apuntó main, es el primer antecesor de la confirmación de fusión, mientras que "Commit 4", la cual la fusionaste dentro de main, es el segundo antecesor de la confirmación de fusión.

Fíjate que empezaste en main cuando éste apuntaba a "Commit 3", y Git te ayudó bastante. Cambió el árbol de trabajo, el índice, y también el HEAD y creó un nuevo objeto de confirmación. Al menos cuando usas git merge sin el argumento --no-commit y cuando no es una fusión directa, Git hace todo eso.

Esto fue un caso super sencillo, donde las ramas que fusionaste no difirieron para nada. Pronto consideraremos casos más interesantes.

A propósito, puedes usar git merge para fusionar más de dos confirmaciones - en realidad, cualquier número de confirmaciones. Esto se hace raras veces, y para adherirnos al principio de practicidad de este libro, no lo profundizaremos.

Otra forma de ver a git merge es uniendo dos o más historiales de desarrollo juntos. Eso es, cuando fusionas, incorporas cambios desde las confirmaciones nombradas, desde el momento en que sus historiales difirieron de la rama actual, en la rama actual. Usé el término "rama" aquí, pero estoy enfatizando esto nuevamente - en realidad estamos fusionando confirmaciones.

Es tiempo de un Caso más Avanzado

Es tiempo de considerar un caso más avanzado, lo cual es probablemente el caso más común donde usamos git merge explícitamente - donde necesitas fusionar ramas que sí difieren uno del otro.

Supón que tenemos dos personas trabajando en este repo ahora, John y Paul.

John creó una rama:

git checkout -b john_branch

Y John ha escrito una nueva canción en un nuevo archivo, lucy_in_the_sky_with_diamonds.md. Bueno, creo que John Lennon realmente no escribió en formato Markdown, o no usó Git para ese asunto, pero pretendamos que lo hizo para esta explicación.

git add lucy_in_the_sky_with_diamonds.md
git commit -m "Commit 5"

Mientras John estaba trabajando en esta canción, Paul también estaba escribiendo, en otra rama. Paul había comenzado desde main:

git checkout main

Y creó su propia rama:

git checkout -b paul_branch

Y Paul escribió su canción en un archivo llamado penny_lane.md. Paul puso en el área de preparación y confirmó este archivo:

git add penny_lane.md
git commit -m "Commit 6"

Así que ahora nuestro historial luce así - donde tenemos dos ramas distintas, que se ramifican desde main, con historiales distintos:

John está feliz con su rama (eso es, su canción), así que él decide fusionarlo en la rama main:

git checkout main
git merge john_branch

En realidad, este es una fusión directa, como hemos aprendido antes. Puedes validar eso al ver el historial (usando git lol, por ejemplo):

A este punto, Paul también quiere fusionar su rama dentro de main, pero ahora una fusión directa ya no es relevante - hay dos diferentes historiales aquí: el historial de main y el de paul_branch. No es que paul_branch solamente agrega confirmaciones encima de la rama main o vice versa.

Ahora las cosas se ponen interesante. 😎😎

Primero, dejemos a Git que haga el trabajo duro por ti. Después de eso, entenderemos lo que en realidad está sucediendo por debajo.

git merge paul_branch

Considera este historial ahora:

Lo que tienes es una nueva confirmación, con dos antecesores - "Commit 5" y "Commit 6".

En el directorio de trabajo, puedes ver que la canción de John así también como la canción de Paul están ahí (si usas ls, verás ambos archivos en el directorio de trabajo).

Bien, Git realmente fusionó los cambios por ti. ¿Pero cómo hace que eso suceda?

Deshace la última confirmación:

git reset --hard HEAD~

Cómo realizar una Fusión de Tres Vías en Git

Es tiempo de entender lo que realmente está pasando por debajo. 😎

Lo que Git ha hecho aquí se le llama una fusión de 3 vías. Al delinear el proceso de una fusión de 3 vías, usaré el término "rama" para simplicidad, pero deberías recordar que podrías también fusionar dos (o más) confirmaciones que no son referenciados por una rama.

El proceso de fusión de 3 vías incluye estas etapas:

Primero, Git localiza el ancestro común de las dos ramas. Eso es, la confirmación común desde el cual las ramas de fusión difirieron más recientemente. Técnicamente, esto en realidad es la primer confirmación que es accesible desde ambas ramas. A esta confirmación entonces se le llama la base de fusión.

Segundo, Git calcula dos diffs - un diff de la base de fusión a la primer rama, y otro diff desde la base de fusión a la segunda rama. Git genera parches basados en esos diffs.

Tercero, Git aplica ambos parches a la base de fusión usando un algoritmo de fusión de 3 vías. El resultado es el estado de la nueva confirmación de fusión.

Así que, devuelta a nuestro ejemplo.

En el primer paso, Git mira desde ambas ramas - main y paul_branch - y atraviesa el historial para encontrar la primera confirmación que es accesible desde ambos. En este caso, este sería.. ¿cuál confirmación?

Correcto, la confirmación de fusión (el que tiene a "Commit 3" y "Commit 4" como sus predecesores).

Si no estás seguro, siempre puedes preguntarle a Git directamente:

git merge-base main paul_branch

A propósito, este es el caso más común y sencillo, donde tenemos una única elección obvia para la base de fusión. En casos más complicados, podría haber múltiples posibilidades para una base de fusión, pero esto no está dentro de nuestro enfoque.

En el segundo paso, Git calcula las diferencias. Así que primero calcula la diferencia entre la confirmación de fusión y "Commit 5":

git diff 4f90a62 4683aef

(Los valores de SHA-1 serán distintas en tu máquina.)

Si no te sientes cómodo con la salida de git diff, puedes leer el capítulo anterior donde lo describí en detalle.

Puedes almacenar esa diferencia en un archivo:

git diff 4f90a62 4683aef > john_branch_diff.patch

Luego, Git calcula la diferencia entre la confirmación de fusión y "Commit 6":

git diff 4f90a62 c5e4951

Escribe esto en un archivo también:

git diff 4f90a62 c5e4951 > paul_branch_diff.patch

Ahora Git aplica esos parches en la base de fusión.

Primero, intenta eso directamente - aplica los parches (te lo explicaré en un momento). Esto no es lo que realmente hace Git por defecto, pero te ayudará a ganar un mejor entendimiento de por qué Git necesita hacer algo distinto.

Verifica la base de fusión primero, eso es, la confirmación de fusión:

git checkout 4f90a62

Y aplica el parche de John primero (como recordatorio, este es el parche que se muestra en la imagen con el subtítulo "The diff between the merge commit and "Commit 5""):

git apply --index john_branch_diff.patch

Fíjate que por ahora no hay una confirmación de fusión. git apply actualiza el directorio de trabajo así también como el índice, ya que usamos el conmutador --index.

Puedes observar el estado usando git status:

Así que ahora la nueva canción de John se incorpora en el índice. Aplica el otro parche:

git apply --index paul_branch_diff.patch

Como resultado, el índice contiene los cambios desde ambas ramas.

Ahora es tiempo de confirmar tu fusión. Ya que el comando de porcelana git commit siempre genera una confirmación con un solo predecesor, necesitarías el comando de plomería subyacente - git commit-tree.

Si necesitas un recordatorio sobre los comandos de porcelana vs de plomería, mira el capítulo 4 donde expliqué estos términos, y creé un repo entero desde cero.

Recuerda que cada objeto de confirmación de Git apunta a un sólo árbol. Así que necesitas registrar los contenidos del índice en un árbol:

git write-tree

Ahora obtienes el valor de SHA-1 del árbol creado, y puedes crear un objeto de confirmación usando git commit-tree:

git commit-tree <TREE_SHA> -p <COMMIT_5> -p <COMMIT_6> -m "Merge commit!"

Genial, ¡así que has creado un objeto de confirmación!

Recuerda que git merge también cambia el HEAD para que apunte al nuevo objeto de confirmación de fusión. Así que puedes simplemente hacer lo mismo:

git reset --hard db315a

Si miras al historial ahora:

(Nota: en este estado, HEAD está "separado" - eso es, directamente apunta a un objeto de confirmación en vez de una referencia nombrada. gg no muestra el HEAD cuando está "separado", así que no te confundas si no puedes ver el HEAD en la salida de gg.)

Esto es casi lo que queríamos. Recuerda que cuando ejecutaste git merge, el resultado fue HEAD apuntando a main el cual apuntó a la nueva confirmación creada (como se muestra en la imagen con el subtítulo "When you merge paul_branch), obtienes una nueva confirmación de fusión". ¿Qué deberías hacer entonces?

Bueno, lo que quieres es modificar a main, así que lo puedes apuntar a la nueva confirmación:

git checkout main
git reset --hard db315a

Y ahora tienes el mismo resultado cuando ejecutaste git merge: main apunta a la nueva confirmación, el cual tiene "Commit 5" y Commit 6" como sus predecesores. Puedes usar git lol para verificar eso.

Así que esto es exactamente el mismo resultado como la fusión hecha por Git, con la excepción de la marca de tiempo y así el valor de SHA-1, por supuesto.

Sobretodo, tienes que fusionar los contenidos de las dos confirmaciones - eso es, el estado de los archivos, y también el historial de esas confirmaciones - creando una confirmación de fusión que apunta a ambos historiales.

En este caso sencillo, podrías en realidad aplicar los parches usando git apply y todo funciona bastante bien.

Rápida recapitulación de una Fusión de tres vías

Así que para recapitular rápidamente, en una fusión de tres vías, Git:

• Primero, localiza la base de fusión - el ancestro común de las dos ramas. Eso es, la primer confirmación que es accesible de ambas ramas.
• Segundo, Git calcula los dos diffs - un diff de la base de fusión a la primera rama, y otro diff de la base de fusión a la segunda rama.
• Tercero, Git aplica ambos parches a la base de fusión, usando un algoritmo de fusión de tres vías. No he explicado la fusión de tres vías todavía, pero lo explicaré más tarde. El resultado es el estado de la nueva confirmación de fusión.

También puedes entender por qué se llama una "fusión de 3 vías": Git fusiona, tres estados diferentes - el de la primera rama, el de la segunda rama, y su ancestro en común. En nuestro ejemplo anterior, main, paul_branch, y la confirmación de fusión (con "Commit 3" y "Commit 4" como predecesores), respectivamente.

Esto es improbable, digamos, los ejemplos directos que vimos antes. Los ejemplos directos son en realidad un caso de una fusión de dos vías, ya que Git solamente compara dos estados - por ejemplo, a donde main apuntó, y a donde john_branch apuntó.

Continuando

Todavía, esto fue un sencillo caso de una fusión de 3 vías. John y Paul crearon canciones distintos, así que cada uno de ellos tocaron un archivo distinto. Fue bastante directo para ejecutar la fusión.

¿Qué hay sobre casos más interesantes?

Digamos que ahora John y Paul son co-autores de una nueva canción.

Así que, John verificó la rama main y comenzó a escribir la canción:

git checkout main

Él lo puso en el área de preparación y lo confirmó ("Commit 7"):

git add a_day_in_the_life.md
git commit -m "Commit 7"

Ahora, Paul hace una rama:

git checkout -b paul_branch_2

Y edita la canción, agregando otro verso:

Por supuesto, la canción original no incluye el título "Paul's Verse", pero lo agregué para claridad.

Paul pone en el área de preparación y confirma los cambios:

git add a_day_in_the_life.md
git commit -m "Commit 8"

John también hace una rama tomando de main y agrega unas dos líneas adicionales al final:

git checkout main
git checkout -b john_branch_2

John pone en el área de preparación y confirma sus cambios también ("Commit 9"):

git add a_day_in_the_life.md
git commit -m "Commit 9"

Este es el historial resultante:

Así que, Paul y John modificó el mismo archivo en diferentes ramas. ¿Tendrá éxito Git al fusionarlos?

Digamos que ahora no vamos por main, sino que John intentará fusionar la nueva rama de Paul en su rama:

git merge paul_branch_2

¡Espera! ¡No ejecutes este comando! ¿Por qué le dejarías a Git hacer todo el trabajo duro? Estás intentando de entender el proceso aquí.

Así que, primero, Git necesita encontrar la base de fusión. ¿Puedes ver cual confirmación sería?

Correcto, sería la última confirmación en la rama main, donde los dos difieren - eso es, "Commit 7".

Puedes verificar eso usando:

git merge-base john_branch_2 paul_branch_2

Cambia a la base de fusión así más tarde puedes aplicar los parches que crearás:

git checkout main

Genial, ahora Git debería calcular los diffs y generar los parches. Puedes observar los diffs directamente:

git diff main paul_branch_2

¿Tendrá éxito en aplicar este parche? Bueno, sin problema, Git tiene todas las líneas de contexto en lugar.

Cambia a la base de fusión (el cual es "Commit 7", también referenciado por main), y pide a Git que aplique este parche:

git checkout main
git diff main paul_branch_2 > paul_branch_2.patch
git apply --index paul_branch_2.patch

Y esto funcionó, sin problemas para nada.

Ahora, calcula la diff entre la nueva rama de John y la base de fusión. Fíjate que no has confirmado los cambios aplicados, así que john_branch_2 todavía apunta a la misma confirmación como antes, "Commit 9":

git diff main john_branch_2

¿Funcionará si se aplica este diff?

Bueno, de hecho, sí. Fíjate que aunque los números de líneas han cambiado en la versión actual del archivo, gracias a las líneas de contexto que Git es capaz de localizar donde necesita agregar estas líneas...

Guarda este parche y luego aplícalo:

git diff main john_branch_2 > john_branch_2.patch
git apply --index john_branch_2.patch

Observa el archivo resultante:

Genial, exactamente lo que queríamos.

Ahora puedes crear el árbol y la confirmación relevante:

git write-tree

No te olvides de especificar ambos predesores:

git commit-tree <TREE-ID> -p paul_branch_2 -p john_branch_2 -m "Merging new changes"

¿Viste cómo usé los nombres de rama aquí? Después de todo, sólo son punteros a las confirmaciones que queremos.

Genial, mira el log de la nueva confirmación:

Exactamente lo que queríamos.

También puedes dejar a Git que haga el trabajo para ti. Puedes cambiar a john_branch_2, el cual no has movido - así que todavía apunta a la misma confirmación como lo hizo antes de la fusión. Así que todo lo que necesitas es ejecutar:

git checkout john_branch_2
git merge paul_branch_2

Observa el historial resultante:

Como antes, tienes una confirmación de fusión apuntando a "Commit 8" y "Commit 9" como sus predecesores. "Commit 9" es el primer predecesor ya que lo fusionaste.

Pero esto fue bastante sencillo... John y Paul trabajaron en el mismo archivo, pero en partes muy distintas. También podrías directamente aplicar los cambios de Paul a la rama de John. Si vuelves a la rama de John antes de la fusión:

git reset --hard HEAD~

Y ahora aplica los cambios de Paul:

git apply --index paul_branch_2.patch

Obtendrías el mismo resultado.

Pero, ¿qué sucede cuando las dos ramas incluyen cambios en los mismos archivos, en las mismas ubicaciones?

Casos de Fusión de Git más avanzados

¿Qué sucedería si John y Paul fueran a coordinar una nueva canción, y lo realizan juntos?

En este caso, John crea la primer versión de esta canción en la rama main:

git checkout main
nano everyone.md

A propósito, este texto es de hecho tomado de la versión que John Lennon grabó para una demo en 1968. Pero esto no es un libro sobre los Beatles. Si estás interesado sobre el proceso por el que los Beatles atravesaron mientras escribían esta canción, puedes seguir los enlaces al final de este capítulo.

git add everyone.md
git commit -m "Commit 10"

Ahora John y Paul se separon. Paul crea un nuevo verso al principio:

git checkout -b paul_branch_3
nano everyone.md

También, mientras hablando con John, decidieron cambiar la palabra "feet" a "foot", así que Paul agrega este cambio también.

Y Paul agrega y confirma sus cambios al repo:

git add everyone.md
git commit -m "Commit 11"

Puedes observar los cambios de Paul, comparando este estado de la rama al estado de la rama main:

git diff main

Almacena este diff en un archivo parche:

git diff main > paul_3.patch

Ahora devuelta a main...

git checkout main

John decide hacer otro cambio, en su propia nueva rama:

git checkout -b john_branch_3

Y reemplaza la línea "Everyone had the boot in" con la línea "Everyone had a wet dream". Además, John cambió la plabra "feet" a "foot", siguiendo su charla con Paul.

Observa el diff:

git diff main

Almacena esta salida también:

git diff main > john_3.patch

Ahora, pónlo en el área de preparación y confirma:

git add everyone.md
git commit -m "Commit 12"

Este debería ser tu historial actual:

Fíjate que eliminé john_branch_2 y paul_branch_2 para simplicidad. Por supuesto, puedes eliminarlos de Git usando git branch -D <branch_name>. Como resultado, estos nombres de ramas no aparecerán en la salida de git log u otros comandos similares.

Esto también se aplica a las confirmaciones que ya no son accesibles desde ninguna referencia nombrada, tales como "Commit 8" o "Commit 9". Ya que ya no son accesibles desde ninguna referencia nombrada por medio de la cadena de los antecesores, no serán incluidos en la salida de comandos tales como git log.

Devuelta a nuestra historia - Paul y John han agregado un nuevo verso, así que a John le gustaría fusionar los cambios de Paul.

¿Puede John simplemente aplicar el parche de Paul?

Considera el parche de nuevo:

git diff main paul_branch_3

Como puedes ver, este diff se basa en la línea "Everyone had the boot in", pero esta línea ya no existe en la rama de John. Como resultado, podrías esperar que aplicar el parche falle. Continúa, inténtalo:

git apply paul_3.patch

De hecho, puedes ver que falló.

¿Pero debería fallar realmente?

Como expliqué anteriormente, git merge usa un algoritmo de 3 vías, y esto puede ser útil aquí. ¿Cuál sería el primer paso de este algoritmo?

Bueno, primero, Git encontraría la base de fusión - eso es, el ancestro común de la rama de Paul y de la rama de John. Considera el historial:

Así que el ancestro común de "Commit 11" y Commit 12" es "Commit 10". Puedes verificarlo ejecutando el comando:

git merge-base john_branch_3 paul_branch_3

Ahora podemos tomar los parches que generamos desde los diffs en ambas ramas, y aplicarlos al main. ¿Funcionaría?

Primero, intenta aplicar el parche de John, y luego el parche de Paul.

Considera el diff:

git diff main john_branch_3

Podemos almacenarlo en un archivo:

git diff main john_branch_3 > john_3.patch

Y aplicar este parche en el main:

git checkout main
git apply john_3.patch

Consideremos el resultado:

nano everyone.md

La línea cambió como se esperaba. Bien 😎

Ahora, ¿puede Git aplicar el parche de Paul? Para recordarte, este es el parche. Bueno, Git no puede aplicar este parche, porque este parche asume que la línea "Everyone had the boot in" existe. Tratar de aplicarlo es probable que falle:

Bueno, Git no puede aplicar este parche, porque este parche asume que la línea "Everyone had the boot in" existe. Tratar de aplicarlo es probable que falle:

git apply -v paul_3.branch

Lo que intentaste de hacer ahora, aplicar el parche de Paul en la rama main después de aplicar el parche de John, es lo mismo que estar en john_branch_3, e intentar de aplicar el parche. Eso es, ejecutando:

git apply paul_3.patch

¿Qué sucedería si intentaramos al revés?

Primero, limpia el estado:

git reset --hard

Y comienza desde la rama de Paul:

git checkout paul_branch_3

¿Podemos aplicar el parche de Paul? Como recordatorio, este es el estado de everyone.md en esta rama:

Y este es el parche de John:

¿Funcionaría aplicar el parche de John?

Intenta contestarte a tí mismo antes de continuar leyendo.

Puedes intentar:

git apply john_3.patch

Bueno, ¡no! De nuevo, si estás seguro de lo que pasó, siempre puedes pedir con git apply para que sea un poco más verboso:

git apply -v john_3.patch

Git está buscando "Everyone put the feet down", pero Paul ya ha cambiado esta línea así que ahora consiste de la palabra "foot" en vez de "feet". Como resultado, aplicar este parche falla.

Fíjate que cambiar el número de las líneas de contexto aquí (eso es, usando git apply con el argumento -C, como se discutió en el capítulo anterior) es irrelevante - Git es incapaz de localizar la línea actual que el parche está intentando de eliminar.

Pero en realidad, Git puede hacer que esto funcione, si sólo agregas un argumento para aplicar, diciéndole que haga una fusión de tres vías por debajo:

git apply -3 john_3.patch

Y considera el resultado:

¡Exactamente lo que queríamos! ¡Tienes el verso de Paul, y los de John!

Así que, ¿cómo Git fue capaz de lograr eso?

Bueno, como mencioné, Git realmente hizo una fusión de 3 vías, y con este ejemplo, será un buen momento para indagar lo que esto realmente significa.

Cómo funciona el Algoritmo de Fusión de 3 vías de Git

Vuelve al estado antes de aplicar este parche:

git reset --hard

Ahora tienes tres versiones: la base de fusión, el cual es "Commit 10", la rama de Paul, y la rama de John. En términos generales, podemos decir que estos son el merge base, commit A y commit B. Fíjate que el merge base es por definición un ancestro de ambos commit A y commit B.

Para realizar una fusión, Git mira al diff entre las tres diferentes versiones del archivo en cuestión de estas tres revisiones. En tu caso, es el archivo everyone.md, y las revisiones son "Commit 10", la rama de Paul - eso es, "Commit 11", y la rama de John, eso es, "Commit 12".

Git hace la decisión de fusión basado en el estado de cada línea en cada una de estas versiones.

En caso que no todas las tres versiones coincidan, eso es un conflicto. Git puede resolver muchos de estos conflictos automáticamente, como veremos ahora.

Consideremos líneas específicas.

Las primeras líneas aquí existen solamente en la rama de Paul:

Esto significa que el estado de la rama de John es igual al estado de la base de fusión. Así que la fusión de 3 vías va a la par con la versión de Paul.

En general, si el estado de la base de fusión es el mismo que el A, el algoritmo va la par con B. La razón se debe a que la base de fusión es el ancestro de A y de B, Git asume que esta línea no ha cambiado en A, y ha cambiado en B, el cual es la versión más reciente para esa línea, y por lo tanto debería ser tomado en cuenta.

Luego, puedes ver líneas donde toda las tres versiones están de acuerdo - están en la base de fusión, A y B, con datos iguales.

En este caso el algoritmo tiene una opción trivial - sólo toma esa versión.

En un ejemplo previo, vimos que si la base de fusión y A están de acuerdo, y la versión de B es diferente, el agoritmo toma B. Esto funciona en la otra dirección también - por ejemplo, aquí tienes una línea que existe en la rama de John, distinto al de la base de fusión y al de la rama de Paul.

Por lo tanto, la versión de John es elegida:

Ahora considera otro caso, donde A y B están de acuerdo en una línea, pero el valor en el que están de acuerdo es distinta del de la base de fusión: ambos John y Paul acordaron en cambiar la línea "Everyone put their feet down" a "Everyone put their foot down":

En este caso, el algoritmo toma la versión de A y de B.

Fíjate que esto no es un voto democrático. En el caso previo, el algoritmo tomó la versión minoritaria, ya que se parecía a la versión más reciente de esta línea. En este caso, llega a tomar la mayoría - pero solamente porque A y B son las revisiones que acordan en la nueva versión.

Lo mismo sucedería si usaramos git merge:

git merge john_branch_3

Sin especificar ningún argumento, git merge por defecto usará una fusión de 3 vías.

El estado de everyone.md después de ejecutar git merge john_branch sería el mismo que el resultado que alcanzaste al aplicar los parches con git apply -3.

Si consideras el historial:

Verás que la confirmación de fusión tiene dos antecesores: el primero es el "Commit 11", eso es, a donde apuntó paul_branch_3 antes de la fusión. El segundo es "Commit 12", a donde john_branch_3 apuntó, y a donde todavía apunta ahora.

¿Qué sucederá si ahora fusionas desde main? Eso es, cambiar a la rama main, el cual apunta al "Commit 10":

git checkout main

¿Y luego fusionar la rama de Paul?

git merge paul_branch_3

De hecho, obtenemos una fusión directa - como antes de ejecutar este comando, main era un ancestro de paul_branch_3.

Así que, esto es una fusión de 3 vías. En general, si todas las versiones acuerdan en una línea, luego esta línea es usada. Si A y la base de fusión coinciden, y B tiene otra versión, B es tomado. En el caso opuesto, donde la base de fusión y B coinciden, la versión A es seleccionado. Si A y B coinciden, esta versión es tomada, sea que la base de fusión esté de acuerdo o no.

Esta descripción deja una pregunta abierta: ¿qué sucede en casos donde todas las tres versiones están en desacuerdo?

Bueno, eso es un conflicto que Git no lo resuelve automáticamente. En estos casos, Git pide ayuda de un humano.

Cómo resolver conflictos de fusión

Siguiendo hasta ahora, deberías entender las bases del comando git merge, y cómo Git puede resolver automáticamente algunos conflictos. También entiendes qué casos son resueltos automáticamente.

Ahora, consideremos un caso más avanzado.

Digamos que Paul y John continúan trabajando en esta canción.

Paul crea una nueva rama:

git checkout -b paul_branch_4

Y él decide agregar algunos "Yeah" a la canción, así que él cambia este verso como sigue:

Así que Paul pone en el área de preparación y confirma estos cambios:

git add everyone.md
git commit -m "Commit 13"

Paul también crea otra canción, let_it_be.md y lo agrega al repo:

git add let_it_be.md
git commit -m "Commit 14"

Este es el historial:

Volviendo a main:

git checkout main

John también crea una rama:

git checkout -b john_branch_4

Y John también trabaja en la canción "Everyone had a hard year", luego para ser llamado "I've got a feeling" (de nuevo, esto no es un libro sobre los Beatles, así que no daré mas detalles aquí. Mira los enlaces adicionales si tienes curiosidad).

John decide cambiar todas las ocurrencias de "Everyone" to "Everybody":

Él pone en el área de preparación y confirma esta canción al repo:

git add everyone.md
git commit -m "Commit 15"

Bien. Ahora John también crea otra canción, across_the_universe.md. Él lo agrega al repo también:

git add across_the_universe.md
git commit -m "Commit 16"

Observa el historial nuevamente:

Puedes ver que el historial difiere de main, a dos ramas distintas - paul_branch_4, y john_branch_4.

A este punto, a John le gustaría fusionar los cambios introducidos por Paul.

¿Qué va a pasar aquí?

Recuerda los cambios introducidos por Paul:

git diff main paul_branch_4

¿Qué piensas? ¿La fusión funcionará?

Inténtalo:

git merge paul_branch_4

¡Tenemos un conflicto!

Git no puede fusionar estas ramas por sí mismo. Puedes obtener una vista general del estado de fusión, usando git status:

Los cambios que Git no tuvo problema resolviendo están en el área de preparación para confimar. Y hay una sección separada para "rutas no fusionadas" - estos son archivos con conflictos que Git no podría resolver por sí mismo.

Es tiempo de entender por qué y cuando estos conflictos suceden, cómo resolverlos, y también cómo Git los maneja por debajo.

¡Muy bien entonces! Espero que al menos estés emocionado como yo. 😇

Recordemos lo que sabemos sobre fusiones de 3 vías:

Primero, Git buscará la base de fusión - el ancestro común de john_branch_4 y paul_branch_4. ¿Cuál confirmación sería ese?

Sería la punta de la rama main, la confirmación en el cual fusionamos john_branch_3 en paul_branch_3.

De vuelta, si no estás seguro, puedes verificar eso ejecutando:

git merge-base john_branch_4 paul_branch_4

Y en el estado actual, git status sabe qué archivos están en el área de preparación y cuáles no.

Considera el proceso para cada archivo, el cual es el mismo que el algoritmo de fusión de 3 vías que consideramos por línea, pero a nivel de archivo:

across_the_universe.md existe en la rama de John, pero no existe en la base de fusión o en la rama de Paul. Así que Git elige incluir este archivo. Ya que ya estás en la rama de John y este archivo es incluido en la punta de esta rama, no es mencionado por git status.

let_it_be.md existe en la rama de Paul, pero no existe en la base de fusión o en la rama de John. Así que git merge "elige" incluirlo.

¿Qué hay sobre everyone.md? Bueno, aquí tenemos tres estados distintos de este archivo: su estado en la base de fusión, su estado en la rama de John, y su estado en la rama de Paul. Mientras se realiza una fusión, Git almacena todas estas versiones en el índice.

Observemos eso mirando directamente al índice con el comando git ls-files:

git ls-files -s --abbrev

Puedes ver que everyone.md tiene tres entradas diferentes. Git le asigna a cada versión un número que representa la "fusión" del archivo, y esta es una propiedad distinta de una entrada de índice, junto con el nombre del archivo y el modo bits.

Cuando no hay conflicto de fusión en cuanto a un archivo, su "área de preparación" es 0. Esto es de hecho el estado para across_the_universe.md, y para let_it_be.md.

En un estado de conflicto, tenemos:

• Estado 1 - el cual es la base de fusión.
• Estado 2 - el cual es "tu" versión. Eso es, la versión del archivo en la rama en la que estás fusionando. En nuestro ejemplo, este sería john_branch_4.
• Estado 3- el cual es "su" versión, también llamado el MERGE_HEAD. Eso es, la versión en la rama que estás fusionando (en la rama actual). En nuestro ejemplo, ese es paul_branch_4.

Para observar los contenidos del archivo en un estado específico, puedes usar un comando que introduje en un post previo, git cat-file, y proveer el SHA del blob:

git cat-file -p <BLOB_SHA_FOR_STAGE_2>

Y justamente, este es el contenido que esperábamos - de la rama de John, donde las líneas comienzan con "Everybody" en vez de "Everyone".

Un lindo truco que te permite ver el contenido rápidamente sin proveer el valor SHA-1 del blob, es usando git show, así:

git show :<STAGE>:everyone.md

Por ejemplo, para obtener el contenido de la misma versión como con git cat-file -p <BLOB_SHA_FOR_STAGE_2>, puedes escribir git show :2:everyone.md.

Git registra los tres estados de los tres confirmaciones en el índice de esta forma al comienzo de la fusión. Luego continúa con el algoritmo de fusión de tres vías para resolver rápidamente los casos sencillos.

En el caso que todas las tres áreas de preparación coincidan, entonces la selección es trivial.

Si un lado hiciera un cambio mientras los otros no lo hicieron - eso es, área de preparación 1 coincide con el área de preparación 2 - entonces elegimos el área de preparación 3, o vice versa. Eso es exactamente lo que sucedió con let_it_be.md y across_the_universe.md.

En caso de una supresión en la rama entrante, por ejemplo, y dado que no hubieron cambios en la rama actual, entonces veríamos que el stage 1 coincide con el stage 2, pero no hay stage 3. En este caso, git merge quita el archivo para la versión fusionada.

Lo que es realmente interesante aquí es para coincidir, Git no necesita los archivos actuales. Más bien, se puede basar en los valores SHA-1 de los blobs correspondientes. De esta forma, Git puede detectar fácilmente el estado en el que se encuentra un archivo.

Para everyone.md tiene este caso especial - donde el área de preparación 1, el área de preparación 2 y el área de preparación 3 son todos distintos uno del otro. Eso es, tienen SHAs de blob distintos. Es momento de ir más profundo y entender el conflicto de fusión. 😊

Una forma de hacer eso sería simplemente usar git diff. En un capítulo anterior, examinamos git diff en detalle, y vimos que muestra las diferencias entre varias combinaciones del árbol de trabajo, del índice o de las confirmaciones.

Pero git diff también tiene un modo especial para ayudar con los conflictos de fusión:

git diff

Esta salida podría ser confuso al principio, pero una vez que te acostumbras, es bastante claro. Empecemos por entenderlo, y luego veamos cómo puede resolver los conflictos con otras herramientas mas visuales.

La sección en conflictos está separado por los signos "iguales"  (===), y marcado con las ramas correspondientes. En este contexto, "el nuestro" es la rama actual. En este ejemplo, sería john_branch_4, la rama a la que HEAD estaba apuntando cuando iniciamos el comando git merge. "El suyo" es el MERGE_HEAD, la rama que estamos fusionando - en este caso, paul_branch_4.

Así que git diff sin ningun argumento especial muestra los cambios entre el árbol de trabajo y el índice - el cual en este caso son los conflictos aún por resolver. La salida no incluye cambios en el área de preparación, lo cual es conveniente para resolver el conflicto.

Es tiempo de resolver esto manualmente. ¡Qué divertido!

Así, ¿por qué esto es un conflicto?

Para Git, Paul y John hicieron distintos cambios a la misma línea, por unas pocas líneas. John lo cambió a una cosa, y Paul lo cambió a otra cosa. Git no puede decidir cuál es el correcto.

Este es no es el caso para las últimas líneas, como la línea solía ser "Everyone had a hard year" en la base de fusión. Paul no ha cambiado esta línea, o las líneas que le rodean, así su versión en paul_branch_4 o "el suyo" en nuestro caso, se pone de acuerdo con el merge_base. Aunque la versión de John, "el nuestro", es distinto. Así git merge puede decidir fácilmente que tome esta versión.

Pero, ¿qué hay sobre las líneas en conflicto?

En este caso, sé lo que quiero, y eso es en realidad una combinación de estas líneas. Quiero que las líneas comiencen con "Everybody", siguiendo el cambio de John, pero también que incluya los "yeah" de Paul. Así que ve y crea la versión deseada editando a everyone.md:

nano everyone.md

Para comparar el archivo resultante con lo que tenías en la rama previa a la fusión, puedes ejecutar:

git diff --ours

De manera similar, si deseas ver cuánto difiere el resultado de la fusión de la rama que fusionaste en nuestra rama, puedes ejecutar:

git diff --theirs

Inclusive puedes ver cuán distinto es el resultado de ambos lados usando:

git diff --base

Ahora puedes poner en el área de preparación la versión arreglada:

git add everyone.md

Después de poner en el área de preparación, si miras en git status, no verás conflictos:

Ahora puedes simplemente usar git commit, y Git te presentará con un mensaje de confirmación conteniendo los detalles sobre la fusión. Puedes modificarlo si quisieras, o dejarlo como está. Sin importar del mensaje de confirmación, Git creará un "mensaje de fusión" - eso es, una confirmación con más de un precesor.

Para validar eso, considera el historial:

john_branch_4 ahora apunta a la nueva confirmación de fusión. La rama entrante, "el suyo", en este caso, paul_branch_4, se mantiene donde estaba.

Cómo usar VS Code para resolver los conflictos

Ahora verás cómo resolver el mismo conflicto usando una herramienta gráfica. Para este ejemplo, use VS Code, el cual es un editor de código popular y gratis. Hay muchas otras herramientas, pero el proceso es similar, así que solo mostraré VS Code como un ejemplo.

Primero, volvamos al estado antes de la fusión:

git reset --hard HEAD~

E intentemos fusionar otra vez:

git merge paul_branch_4

Deberías estar nuevamente al mismo estado:

Veamos cómo aparece esto en VS Code:

VS Code marca las distintas versiones con "Current Change" - el cual es la versión de la "nuestra", el actual HEAD, y "Cambio Entrante" para la rama que estamos fusionando en la rama activa. Puedes aceptar uno de los cambios (o ambos) haciendo clic en una de las opciones.

Si hiciste clic en Resolver en Editor de Fusión, obtendrás una vista mas visual del estado. VS Code muestra el estado de cada línea:

Si miras con atención, verás que VS Code muestra cambios dentro de las palabras - por ejemplo, muestra que "Everyone" fue cambiado a "Everybody", marcando las partes cambiadas.

Puedes aceptar cualquier versión, o puedes aceptar una combinación. En este caso, si haces clic en "Aceptar Combinación", obtienes este resultado:

¡VS Code hizo un excelente trabajo! El mismo algoritmo de fusión de tres vías fue implementado aquí y usado a el nivel de palabra en vez a nivel de línea. Así que VS Code fue capaz en realidad de resolver este conflicto de una forma impresionante. Por supuesto, puedes modificar la sugerencia de VS Code, pero proveyó un comienzo muy bueno.

Una Herramienta Poderosa adicional

Bueno, este fue la primera vez en este libro que he usado una herramienta con una interfaz de usuario gráfica. De hecho, las interfaces gráficas pueden ser convenientes para entender lo que está sucediendo cuando estás resolviendo conflictos de fusión.

Sin embargo, como en muchos otros casos, cuando necesitamos realmente entender lo que está sucediendo, la línea de comando se vuelve práctico. Así que, volvamos a la línea de comandos y aprendamos una herramienta que nos puede venir bien en casos mas complicados.

De nuevo, vuelve al estado antes de la fusión:

git reset --hard HEAD~

Y fusiona:

git merge paul_branch_4

Y digamos, no estás seguro exactamente de lo que pasó. ¿Por qué hay un conflicto? Un comando muy útil sería:

git log -p --merge

Como recordatorio, git log muestra el historial de confirmaciones que son alcanzables desde HEAD. Agregando -p le dice a git log que muestre las confirmaciones juntamente con los diffs que introdujeron. El argumento --merge hace que el comando muestre todas las confirmaciones que contienen cambios relevantes a cualquier archivo que no están en el área de preparación, en cualquier rama, junto con sus diffs.

Esto te puede ayudar en identificar los cambios en el historial que llevaron a los conflictos. Así que en este ejemplo, verías:

La primer confirmación que vemos es "Commit 15", ya que en ésta confirmación John modificó everyone.md, un archivo que todavía tiene conflictos. Luego, Git muestra "Commit 13", donde Paul cambió everyone.md:

Fíjate que git log --merge no mencionó confirmaciones previas que cambiaron a everyone.md antes de "Commit 13", ya que no afectaron el conflicto actual.

De esta forma, git log te dice que todo lo que necesitas saber para entender el proceso que te llevó al estado de conflicto actual. ¡Genial! 😎

Usando la línea de comandos, también puedes preguntarle a Git que tome solamente un lado de los cambios - sea "el nuestro" o "el suyo", inclusive para un archivo específico.

También puedes instruir a Git que tome algunas partes de los diffs de un archivo y otro de otro archivo. Proveeré enlances que describen cómo hacer eso en los recursos adicionales de este capítulo en el apéndice.

Para la mayor parte, puedes lograr eso bastante fácil, sea manualmente o desde la UI de tu IDE favorito.

Por ahora, es tiempo de recapitular.

Recapitulando - Entendiendo Git Merge

En este capítulo, tuviste una vista general extensiva de fusión con Git. Aprendiste que fusionar es el proceso de combinar los cambios recientes desde varias ramas en una sola confirmación. La nueva confirmación tiene dos predecesores - esas confirmaciones los cuales han sido las puntas de las ramas que fueron fusionados.

Consideramos una fusión directa sencilla, lo cual es posible cuando una rama difiere de la rama base, y luego agregamos confirmaciones por encima de la rama base.

Luego consideramos fusiones de tres vías, y explicamos el proceso de tres estados:

• Primero, Git localiza la base de fusión. Como recordatorio, este es la primer confirmación que es alcanzable desde ambas ramas.
• Segudno, Git calcula los dos diffs - un diff desde la base de fusión a la primer rama, y otro diff desde la base de fusión a la segunda rama. Git genera parches basados en esos diffs.
• Tercero y último, Git aplica ambos parches a la base de fusión usando un algoritmo de fusión de 3 vías. El resultado es el estado de la nueva confirmación de fusión.

Indagamos profundamente en el proceso de fusión de 3 vías, sea a nivel de archivo o a nivel de hunk. Consideramos cuando Git es capaz de basarse en una fusión de 3 vías para resolver automáticamente los conflictos, y cuando no puede.

Viste la salida de git diff cuando estamos en un estado de conflicto, y cómo resolver los conficltos manualmente o con VS Code.

Hay mucho más que decir sobre las fusiones - diferentes estrategias de fusión, fusiones recursivas, y así sucesivamente. Con todo, creo que este capítulo cubrió todo lo necesario de esa forma tienes un entendimiento robusto de lo que es una fusión, y qué sucede por debajo en la vasta mayoría de casos.

Recursos relacionados a los Beatles

• https://www.the-paulmccartney-project.com/song/ive-got-a-feeling/
• https://www.cheatsheet.com/entertainment/did-john-lennon-or-paul-mccartney-write-the-classic-a-day-in-the-life.html/
• http://lifeofthebeatles.blogspot.com/2009/06/ive-got-feeling-lyrics.html

Capítulo 8 - Entendiendo Git Rebase

Una de las herramientas más poderosas que tiene un desarrollador en su caja de herramientas es git rebase. Aunque es notorio por ser complejo e incomprendido.

La verdad es, si entiendes lo que hace en realidad, git rebase es una herramienta muy elegante, y directa para alcanzar muchísimas cosas diferentes en Git.

En los capítulos previos en esta parte, aprendiste qué son los diffs de Git, lo que es una fusión, y cómo Git resuelve los conflictos de fusión. En este capítulo, entenderás lo que es rebase de Git, por qué es diferente de merge, y cómo hacer rebase (sobrescribir la base) con confianza.

Recapitulación Corta - ¿Qué es Git Merge?

Por debajo, git rebase y git merge son cosas muy muy distintas. Entonces, ¿por qué la gente los compara todo el tiempo?

La razón es su uso. Cuando se trabaja con Git, usualmente trabajamos en distintas ramas e introducimos cambios a esas ramas.

En el capítulo previo, consideramos el ejemplo donde John y Paul (de los Beatles) eran co-autores de nueva canción. Comenzaron desde la rama main, y luego cada uno difirió, modificaron la letra, y confirmaron sus cambios.

Luego, los dos querían integrar sus cambios, lo cual es algo que sucede muy frecuente cuando se trabaja con Git.

Hay dos formas principales para integrar cambios introducidos en diferentes ramas en Git, o en otras palabras, en diferentes confirmaciones e historiales de confirmación. Estos son merge y rebase.

En el capítulo anterior, llegamos a saber git merge bastante bien. Vimos que cuando realizamos una fusión, creamos una confirmación de fusión - donde los contenidos de esta confirmación son una combinación de las dos ramas, y también tiene dos predecesores, una en cada rama.

Así que, digamos que estás en la rama john_branch (asumiendo el historial representado en el dibujo de arriba), y ejecutas git merge paul_branch. Llegarás a este estado - donde en john_branch, hay una nueva confirmación con dos predecesores. El primero será la confirmación en la rama john_branch donde el HEAD estaba apuntando a un estado antes de realizar la fusión - en este caso, "Commit 6". El segundo será la confirmación a la que apunta paul_branch, "Commit 9".

Mira otra vez al gráfico del historial: creaste un historial divergente. Puedes ver dónde se ramificó y dónde se fusionó nuevamente.

Así que cuando usas git merge, no puedes reescribir el historial - sino, que agregas una confirmación al historial existente. Y específicamente, una confirmación que crea un historial divergente.

¿Cómo se diferencia git rebase de git merge?

Cuando se usa git rebase, algo distinto ocurre.

Comencemos con el panorama general: si estás en paul_branch, y usas git rebase john_branch, Git va al ancestro común de la rama de John y de Paul. Luego tomas los parches introducidos en las confirmaciones de la rama de Paul, y aplicar esos cambios a la rama de John.

Así que aquí, usas rebase para tomar los cambios que fueron confirmados en una rama - la rama de Paul - y reproducirlos en una rama distinta, john_branch.

Espera, ¿qué significa eso?

Ahora tomaremos esto poco a poco para asegurarnos que entiendes completamente lo que estás sucediendo por debajo 😎.

cherry-pick como una base para Rebase

Es útil pensar de rebase como realizar git cherry-pick - un comando que toma una confirmación, calcula el parche que ésta confirmación introduce al calcular la diferencia entre la confirmación del predecesor y la confirmación misma, y luego cherry-pick "repite" esta diferencia.

Hagamos esto manualmente.

Si miramos la diferencia introducido por "Commit 5" al hacer git diff main <SHA_OF_COMMIT-5>:

Como siempre, se te anima en ejecutar los comandos tú mismo mientras lees este capítulo. A menos que se diga otra cosa, usaré el siguiente repositorio:

https://github.com/Omerr/rebase_playground.git

Te recomiendo que lo clones de forma local y tener el mismo punto de inicio que estoy usando para este capítulo.

Puedes ver eso en esta confirmación, John comenzó trabajando en una canción llamada "Lucy in the Sky with Diamonds":

Como recordatorio, también puedes usar el comando git show para obtener la misma salida:

git show <SHA_OF_COMMIT_5>

Ahora, si haces cherry-pick a esta confirmación, introducirás este cambio específicamente, en la rama activa. Cambia a main primero:

git checkout main (or git switch main)

Y crea otra rama:

git checkout -b my_branch (or git switch -c my_branch)

Luego, haz cherry-pick a "Commit 5":

git cherry-pick <SHA_OF_COMMIT_5>

Considera el log (salida de git lol):

Parece que copiaste-pegaste el "Commit 5". Recuerda que inclusive tiene el mismo mensaje de confirmación, e introduce los mismos cambios, e inclusive apunta al mismo objeto de árbol como el "Commit 5" original en este caso - todavía es un objeto de confirmación distinto, como si fuese creado con una marca de tiempo distinto.

Mirando a los cambios, usando git show HEAD

Son lo mismo como los "Commit 5".

Y por supuesto, si miras al archivo (digamos, usando nano lucy_in_the_sky_with_diamonds.md), estará en el mismo estado que estaba después del "Commit 5" original.

¡Genial! 😎

Ahora puedes quitar la nueva rama así no aparece en tu historial cada vez:

git checkout main
git branch -D my_branch

Más allá de cherry-pick - Cómo usar git rebase

Puedes ver a git rebase como una forma de realizar múltiples cherry-pick uno después del otro - eso es, "repetir" múltiples confirmaciones. Esto no es lo único que puedes hacer con rebase, pero es un buen punto de comienzo para nuestra explicación.

¡Es tiempo de jugar con git rebase!

Antes, hiciste fusión de paul_branch en john_branch. ¿Qué debería de pasar si hicieras rebase de paul_branch por encima de john_branch? Obtendrías un historial muy distinto.

En esencia, parecería como si tomáramos los cambios introducidos en las confirmaciones de paul_branch, y repitiéramos en john_branch. El resultado sería un historial linear.

Para entender el proceso, te proveeré la vista de alto nivel, y luego indagaré más profundo en cada paso. El proceso de hacer rebase en una rama por encima de otra rama es como lo siguiente:

1. Encuentra el ancestro común.
2. Identifica las confirmaciones a ser "repetidos".
3. Para cada confirmación X, calcula diff(parent(X), X), y lo almacena como un patch(X).
4. Mueve a HEAD a la nueva base.
5. Aplica los parches generados en orden en la rama de destino. Cada vez, crea un nuevo objeto de confirmación con el nuevo estado.

El proceso de hacer nuevas confirmaciones con el mismo conjunto de cambios que los existentes también se le llama "repetir" esas confirmaciones, un término que ya hemos usado.

Tiempo de practicar con Rebase

Antes de ejecutar el siguiente comando, asegúrate de tener a john_branch localmente, así que ejecuta:

git checkout john_branch

Comienza desde la rama de Paul:

git checkout paul_branch

Este es el historial:

Y ahora, la parte emocionante:

git rebase john_branch

Y observa el historial:

Con git merge agregaste al historial, mientras que con git rebase reescribes el historial. Creas nuevos objetos de confirmación. Además, el resultado es un gráfico de historial linear - en vez de un gráfico divergente.

En esencia, "copiaste" las confirmaciones que estaban en paul_branch y que fueron introducidos después de "Commit 4", y los "pegaste" por encima de john_branch.

El comando se llama "rebase", porque cambia la confirmación base de la rama de donde se ejecuta. Eso es, en tu caso, antes de ejecutar git rebase, la base de paul_branch era "Commit 4" - ya que aquí es donde la rama "nació" (desde main). Con rebase, le pediste a Git que le diera otra base - eso es, pretender que haya nacido desde "Commit 6".

Para hacer eso, Git tomó lo que solía ser "Commit 7", y "repitió" los cambios introducidos en esta confirmación en "Commit 6". Luego creó un nuevo objeto de confirmación. Este objeto difiere del "Commit 7"  original en tres aspectos:

1. Tiene una marca de tiempo distinto.
2. Tiene una confirmación antecesora distinta - "Commit 6", en vez de "Commit 4".
3. El objeto árbol al que está apuntado es distinto - como si los cambios fueran introducidos en el árbol apuntado por "Commit 6", y no el árbol apuntado por "Commit 4".

Fíjate la última confirmación aquí, "Commit 9".  La copia instantánea que representa (eso es, el árbol al que apunta) es exactamente el mismo árbol que obtendrías al hacer fusión de las dos ramas. El estado de los archivos en tu repositorio Git sería el mismo como si usaras git merge. Es solamente el historial que es diferente, y los objetos de confirmación por supuesto.

Ahora, puedes usar simplemente:

git checkout main
git merge paul_branch

Hm..... ¿qué sucedería si ejecutas este último comando? Considera el historial de confirmación de nuevo, después de verificar a main:

¿Qué significaría el hacer fusión de main y paul_branch?

En efecto, Git puede simplemente hacer una fusión directa, ya que el historial es completamente linear (si necesitas un recordatorio sobre fusiones directos, mira el capítulo previo). Como resultado, main y paul_branch ahora apunta a la misma confirmación:

Rebase avanzado en Git

Ahora que entiendes lo básico de rebase, es tiempo de considerar casos más avanzados, donde conmutadores y argumentos adicionales al comando rebase serán útiles.

En el ejemplo previo, cuando solamente usaste rebase (sin conmutadores adicionales), Git repitió todas las confirmaciones desde el ancestro común a la punta de la rama actual.

Pero rebase es un super poder. Es un comando todopoderoso capaz de.. bueno, reescribir el historial. Y puede ser útil si quieres modificar el historial para hacer el tuyo propio.

Deshaz la última fusión haciendo que main apunte a "Commit 4" nuevamente:

git reset --hard <ORIGINAL_COMMIT 4>

Y deshaz el rebasing usando:

git checkout paul_branch
git reset --hard <ORIGINAL_COMMIT 9>

Fíjate que obtuviste exactamente el mismo historial que solías tener:

Para ser claro, "Commit 9" no sólo desaparece cuando no es alcanzable desde el HEAD actual. Al contrario, todavía es almacenado en la base de datos de objetos. Y como usaste git reset ahora para hacer que HEAD apunte a esta confirmación, fuiste capaz de recuperarlo, y también sus confirmaciones antecesoras ya que también están almacenados en la base de datos. Bastante genial, ¿hah? 😎

Aprenderás más sobre git reset en la próxima parte, donde discutimos sobre deshacer cambios en Git.

Mira los cambios que Paul introdujo:

git show HEAD

Sigue yendo hacia atrás en el gráfico de confirmación:

git show HEAD~

Y una confirmación más allá:

git show HEAD~2

Tal vez Paul no quiere este tipo de historial. Más bien, quiere que parezca como si se introdujera los cambios en "Commit 7" y "Commit 8" como una sola confirmación.

Para eso, puedes usar un rebase interactivo. Para hacer eso, agregamos el conmutador -i (o --interactive) al comando rebase:

git rebase -i <SHA_OF_COMMIT_4>

O, ya que main está apuntando a "Commit 4" , podemos ejecutar:

git rebase -i main

Ejecutando este comando, le dices a Git que use una nueva base, "Commit 4". Así que le pides a Git que vuelva atrás a todas las confirmaciones que fueron introducidos después de "Commit 4" y que son alcanzables  desde el HEAD actual, y repita esas confirmaciones.

Para cada confirmación que es repetido, Git nos pregunta que nos gustaría hacer con él:

En este contexto es útil imaginarse de una confirmación como un parche. Eso es, "Commit 7", como "el parche que "Commit 7" introdujo por encima de su antecesor".

Una opción es usar pick. Este es el comportamiento predeterminado, el cual le dice a Git que repita los cambios introducidos en esta confirmación. En este caso, si sólo lo dejas como está - y haces pick de todas las confirmaciones - obtendrás el mismo historial, y Git no creará nuevos objetos de confirmación.

Otra opción es squash. Una confirmación aplastada (del inglés "squashed") tendrá su contenido "doblado" (del inglés "folded") en los contenidos de la confirmación que le precede. Así que en nuestro caso, a Paul le gustaría aplastar "Commit 8" en "Commit 7":

Como puedes ver, git rebase -i provee opciones adicionales, pero no lo veremos en este capítulo. Si permites a rebase que se ejecute, se te mostrará una ventana para seleccionar un mensaje de confirmación para la nueva confirmación creada (eso es, el que introdujo los cambios de "Commit 7" y "Commit 8"):

Y mira el historial:

¡Exactamente lo que queríamos! En paul_branch, tenemos "Commit 9" (por supuesto, es un objeto distinto que el "Commit 9" original). Este objeto apunta a "Commit 7+8", el cual es una confirmación única que introduce los cambios del "Commit 7" original y el "Commit 8" original. El antecesor de la confirmación es "Commit 4", a donde main está apuntando.

Oh wow, ¿no es genial? 😎

git rebase te concede control sin límites sobre la figura de cualquier rama. Puedes usarlo para re-ordenar confirmaciones, o para quitar cambios incorrectos, o modificar un cambio en retrospectiva. Alternativamente, tal vez podrías mover la base de tu rama en otra confirmación, cualquier confirmación que desees.

Cómo usar el conmutador --onto de git rebase

Consideremos un ejemplo más. Vuelve a main nuevamente:

git checkout main

Y elimina los punteros de paul_branch y john_branch así ya no los ves en el gráfico de la confirmación:

git branch -D paul_branch
git branch -D john_branch

Luego, haz una nueva rama desde main:

git checkout -b new_branch

Este es el historial limpio que deberías tener:

Ahora, cambia el archivo code.py (por ejemplo, agrega una nueva función) y confirma tus cambios:

nano code.py

git add code.py
git commit -m "Commit 10"

Vuelve a main:

git checkout main

E introduce otro cambio - agregando una cadena de documentos al principio del archivo:

Es tiempo de poner en el área de preparación y confirmar estos cambios:

git add code.py
git commit -m "Commit 11"

Y aún otro cambio, tal vez agrega @Author a la cadena de documentos:

Confirma este cambio también:

git add code.py
git commit -m "Commit 12"

Oh espera, ahora me doy cuenta que quería que tú hicieras los cambios introducidos en "Commit 11" como parte de new_branch. Ugh. ¿Qué puedes hacer?

Considera el historial:

En vez de tener que "Commit 11" resida solamente en la rama main, quiero que esté en ambas ramas main y new_branch. Visualmente, quisiera moverlo hacia abajo en el gráfico aquí:

¿Puedes ver a dónde estoy yendo? 😇

Bueno, rebase te permite básicamente repetir los cambios introducidos en new_branch, aquellos introducidos en "Commit 10", como si hayan sido originalmente realizados sobre "Commit 11", en vez de "Commit 4".

Para hacer eso, puedes usar otros argumentos de git rebase. Específicamente, puedes usar git rebase --onto, el cual opcionalmente toma tres parámetros:

git rebase --onto <new_parent> <old_parent> <until>

Eso es, tomas todas las confirmaciones entre old_parent y until, y los "cortas" y "pegas" en new_parent.

En este caso, le dirías a Git que quieres tomar todo el historial introducidos entre el ancestro común de main y new_branch, el cual es "Commit 4", y que sea la nueva base para ese historial "Commit 11". Para hacer eso, usa:

git rebase --onto <SHA_OF_COMMIT_11> main new_branch

¡Y mira nuestro hermoso historial! 😍

Consideremos otro caso.

Digamos que empecé a trabajar en una nueva característica, y por error comencé a trabajar desde feature_branch_1, en lugar de main.

Así que para emular esto, crea feature_branch_1:

git checkout main
git checkout -b feature_branch_1

Y elimina new_branch así ya no lo ves en el gráfico:

git branch -D new_branch

Crea un archivo Python sencillo llamado 1.py:

Pónlo en el área de preparación y confirma este archivo:

git add 1.py
git commit -m  "Commit 13"

Ahora haz una nueva rama desde feature_branch_1 (este es el error arreglará luego):

git checkout -b feature_branch_2

Y crea otro archivo, 2.py:

Pónlo en el área de preparación y confirma este archivo también:

git add 2.py
git commit -m  "Commit 14"

E introduce algo de código a 2.py:

Pónlo en el área de preparación y confirma estos cambios también:

git add 2.py
git commit -m  "Commit 15"

Hasta ahora tendrías este historial:

Vuelve a feature_branch_1 y edita 1.py:

git checkout feature_branch_1

Ahora pónlo en el área de preparación y confirma:

git add 1.py
git commit -m  "Commit 16"

Tu historial debería lucir así:

Digamos que ahora te das cuenta que cometiste un error. En realidad querías que feature_branch_2 naciera de la rama main, en vez de feature_branch_1.

¿Cómo puedes lograr eso?

Trata de imaginarlo dado el gráfico del historial y lo que has aprendido sobre el argumento --onto para el comando rebase.

Bueno, quieres "reemplazar" el antecesor de tu primera confirmación en feature_branch_2, el cual es "Commit 14", que está por encima de la rama main - en este caso, "Commit 12" - en vez del comienzo de feature_branch_1 - en este caso, "Commit 13". Así que devuelta, estarás creando una nueva base, esta vez para la primera confirmación en feature_branch_2.

¿Cómo harías eso?

Primero, cambia a feature_branch_2:

git checkout feature_branch_2

Y ahora puedes usar:

git rebase --onto main <SHA_OF_COMMIT_13>

Esto le dice a Git que tome el historial con "Commit 13" como una base, y cambia esa base para que sea "Commit 12" (apuntado por main).

Como resultado, tienes a feature_branch_2 que tiene su base en main en vez de feature_branch_1:

La sintaxis del comando es:

git rebase --onto <new_parent> <old_parent>

Cómo hacer rebase en una sola rama

También puedes usar git rebase mientras miras el historial de una sola rama.

Veamos si puedes ayudarme aquí.

Digamos que trabajé en feature_branch_2, específicamente edité el archivo code.py. Comencé cambiando todas las cadenas para que sean envueltos por doble comillas en vez de comillas simples.

Luego, los puse en el área de preparación y los confirmé:

git add code.py
git commit -m "Commit 17"

Luego decidí agregar una nueva función al principio del archivo:

Nuevamente, los puse en el área de preparación y confirmé:

git add code.py
git commit -m "Commit 18"

Y ahora me doy cuenta que en realidad me olvidé de cambiar las comillas simples a comillas dobles envolviendo a __main__ (como has notado), así que hice eso también:

Por supuesto. puse este cambio en el área de preparación y confirmé:

git add code.py
git commit -m "Commit 19"

Ahora, considera el historial:

¿No es genial, no? O sea, tengo dos confirmaciones que están relacionados el uno al otro, "Commit 17" y "Commit 19" (cambiando los ' a "), pero están separados por "Commit 18" que no está relacionado (donde agregué una nueva función). ¿Qué podemos hacer? ¿Puedes ayudarme?

Intuitivamente, quiero editar el historial aquí:

Así que, ¿qué harías?

¡Exacto!

Puedo hacer rebase del historial de "Commit 17" a "Commit 19", por encima de "Commit 15". Para hacer eso:

git rebase --interactive --onto <SHA_OF_COMMIT_15> <SHA_OF_COMMIT_15>

Fíjate que especifiqué "Commit 15" como el comienzo del rango de confirmaciones, excluyendo esta confirmación. Y no necesité especificar explícitamente a HEAD como el último parámetro.

(Nota: si sigues los pasos de arriba con mi repositorio y obtienes un conflicto de fusión, podrías tener una configuración distinta al de mi máquina debido a los caracteres de espacio en blanco en las líneas finales. En ese caso, puedes agregar el argumento --ignore-whitespace) al comando rebase, resultando en el siguiente comando: git rebase --ignore-whitspace --interactive --onto <SHA_OF_COMMIT_15> <SHA_OF_COMMIT_15>. Si quisieras saber más sobre este problema, busca autocrlf.)

Después de seguir tu consejo y ejecutar el comando rebase (¡gracias! 😇) obtengo la siguiente pantalla:

Así que, ¿qué haría? Quiero poner a "Commit 19" antes de "Commit 18", de esa forma viene después de "Commit 17". Puedo ir más lejos y hacer squash (aplastarlos juntos), así:

Ahora cuando se me aparece una ventana para un mensaje de confirmación, puedo proveer el mensaje "Commit 17+19":

Y ahora, mira nuestro hermoso historial:

¡Gracias nuevamente!

Más casos de uso de Rebase + Más práctica

Por ahora espero que te sientas cómodo con la sintaxis de rebase. La mejora forma de entenderlo en sí es considerar varios casos y averiguar cómo resolverlos tú mismo.

Con los casos que vienen, te recomiendo enérgicamente que dejes de leer después de lo que introduje en cada caso de uso, y luego intentes resolverlo por ti mismo.

Cómo excluir confirmaciones

Digamos que tienes este historial en otro repo:

Antes de jugar con él, almacena una etiqueta a "Commit F" así puedes recuperarlo más tarde:

git tag original_commit_f

(Una etiqueta es una referencia nombrada a una confirmación, como una rama - pero no cambia cuando agregas confirmaciones adicionales. Es como una referencia nombrada constante.)

Ahora, en realidad no quieres los cambios en "Commit C" y "Commit D" que sean incluidos. Podrías usar un rebase interactivo como antes y quitar sus cambios. O, podrías usar git rebase --onto de nuevo. ¿Cómo usarías --onto para "quitar" estas dos confirmaciones?

Puedes hacer rebase de HEAD por encima de "Commit B", donde el antecesor viejo era en realidad "Commit D", y ahora debería ser "Commit B". Considera el historial nuevamente:

Hacer rebase para que "Commit B" sea la base de "Commit E" significa "mover" ambos "Commit E" y "Commit F", y darles otra base - "Commit B". ¿Puedes idearte el comando tú mismo?

git rebase --onto <SHA_OF_COMMIT_B> <SHA_OF_COMMIT_D> HEAD

Fíjate que usar la sintaxis de arriba (exactamente como se proveyó) no haría que main apunte a la nueva confirmación, para que el resultado sea un HEAD "separado". Si usas gg u otra herramienta que muestra el historial alcanzable desde las ramas, te podría confundir:

Pero si simplemente usas git log (o mi alias git lol), verás el historial deseado:

No sé tú, pero este tipo de cosas me hacen realmente feliz. 😊😇

Por cierto, podría omitir el HEAD del comando previo como si este fuera el valor predeterminado para el tercer parámetro. Así que usar:

git rebase --onto <SHA_OF_COMMIT_B> <SHA_OF_COMMIT_D>

Tendría el mismo efecto. El último parámetro en realidad le dice a Git donde está el final de la secuencia actual de las confirmaciones para hacerles rebase. Así que la sintaxis de git rebase --onto con los tres argumentos es:

git rebase --onto <new_parent> <old_parent> <until>

Cómo mover confirmaciones a través de las ramas

Así que digamos que obtenemos el mismo historial que antes:

git checkout original_commit_f

Y ahora quiero solamente que "Commit E" esté en una rama que tenga su base en "Commit B". Eso es, quiero tener una nueva rama, que venga desde "Commit B", que tenga solamente a "Commit E".

Así que, ¿qué significa esto en términos de rebase? Considera la imagen de arriba. ¿Qué confirmación (o confirmaciones) debería hacer rebase, y qué confirmación debería ser la nueva base?

Sé que puedo contar contigo aquí 😉

Lo que quiero es tomar el "Commit E", y solamente esta confirmación, y cambiar su base para que sea "Commit B". En otras palabras, repetir los cambios introducidos en "Commit E" en "Commit B".

¿Puedes aplicar esa lógica a la sintaxis de git rebase?

Aquí está (esta vez estoy escribiendo <COMMIT_X> en vez de <SHA_OF_COMMIT_X>, para brevedad):

git rebase --onto <COMMIT_B> <COMMIT_D> <COMMIT_E>

Ahora el historial luce así:

Fíjate que rebase movió a HEAD, pero ninguna otra referencia nombrada (tales como una rama o una etiqueta). En otras palabras, estás en un estado de HEAD separado. Así que aquí también, usando gg u otra herramienta que muestre el historial alcanzable desde las ramas y de las etiquetas te podría confundir. Puedes usar git log (o mi alias git lol) para mostrar el historial alcanzable desde HEAD.

¡Genial!

Una Nota sobre los Conflictos

Fíjate que cuando haces un rebase, podrías entrar en conflictos así como al fusionar. Podrías tener conflictos porque, cuando haces rebase, estás intentando aplicar parches en una base distinta, tal vez donde los parches no apliquen.

Por ejemplo, considera el repositorio nuevamente, y específicamente, considera el cambio introducido en "Commit 12", que es apuntado por main:

git show main

Ya cubrí el formato de git diff en detalle en el capítulo 6, pero como un recordatorio rápido, esta confirmación le instruye a Git que agregue una línea después de las dos líneas de contexto:

```
This is a sample file

Y antes de estas tres líneas de contexto:

```
def new_feature():
  print('new feature')

Digamos que estás intentando hacer rebase de "Commit 12" en otra confirmación. Si, por alguna razón, estas líneas de contexto no existen como sí existen en el parche de la confirmación en la que estás haciendo rebase, entonces tendrías un conflicto.

Aléjandose para ver el panorama general

Al principio de este capítulo, comencé mencionando la similaridad entre git merge y git rebase: ambos son usados para integrar cambios introducidos en historiales distintos.

Pero, como ahora sabes, son muy distintos en cómo operan. Mientras se fusionan resultados en un historial divergente, hacer rebase resulta en un historial linear. Los conflictos son posibles en ambos casos. Y hay una columna más descrita en la tabla de arriba que requiere más atención.

Ahora que sabes qué es "Git rebase", y cómo usar el rebase interactivo o rebase --onto, como espero que estés de acuerdo, git rebase es una herramienta super poderosa. Aunque, tiene una desventaja grande cuando se compara con fusionar.

Git rebase cambia el historial.

Esto significa que no deberías hacer rebase de las confirmaciones que existen fuera de tu copia local del repositorio, y que otras personas podrían tener su base en sus confirmaciones.

En otras palabras, si sólo las confirmaciones en cuestión son aquellos que creaste de manera local - adelante, use rebase, enloquécete.

Pero si las confirmaciones han sido empujados (enviados), eso puede llevarte a un gran problema - ya que alguien más podría basarse en estas confirmaciones que tu luego sobreescribas, y después tú y ellos tendrás distintas versiones del repositorio.

Esto es distinto a merge el cual, como hemos visto, no modifica el historial.

Por ejemplo, considera el último caso donde cambiamos la base y resultó en este historial:

Ahora, digamos que ya empujé esta rama al remoto. Y después que he empujado la rama, otro desarrollador lo empujó e hizo una rama desde "Commit C". El otro desarrollador no sabía que mientras tanto, estuve haciendo rebase de mi rama de forma local, y luego lo subiría (empujaría) nuevamente.

Esto resulta en una inconsistencia: el otro desarrollador trabaja desde una confirmación que ya no está disponible en mi copia del repositorio.

No elaboraré exactamente lo que esto causa en este libro, ya que mi mensaje principal es que deberías evitar definitivamente tales casos. Si estás interesado en qué sucedería en sí, te dejaré un enlace a un recurso útil en las referencias adicionales. Por ahora, resumamos lo que hemos cubierto.

Recapitulación - Entendiendo Git rebase

En este capítulo, aprendiste sobre git rebase, una herramienta super poderosa para reescribir el histoiral en Git. Consideraste unos pocos casos donde git rebase puede ser útil, y cómo usarlo en uno, dos, o tres parámetros, con y sin el conmutador --onto.

Espero que haya sido capaz de convencerte que git rebase es poderoso - pero también que es bastante sencillo una vez que entiendes la esencia. Es una herramienta que puedes usar para "copiar-pegar" confirmaciones (o, más acertadamente, parches). Y es una herramienta útil para tener en tu cinto. En esencia, git rebase toma los parches introducidos por las confirmaciones, y repetirlos en un otra confirmación. Como se describió en este capítulo, esto es útil en muchos escenarios distintos.

Parte 2 - Resumen

En esta parte aprendiste a hacer ramas e integrar cambios en Git.

Aprendiste lo que es un diff, y la diferencia entre un diff y un parche. También aprendiste cómo se construye la salida de git diff.

Entender los diffs es un hito mayor para entender muchos otros procesos dentro de Git tales como fusionar o hacer rebase.

Después, tuviste una vista general extensiva sobre fusionar con Git. Aprendiste que la fusión es el proceso de combinar los cambios recientes de varias ramas en una sola nueva confirmación. La nueva confirmación tiene múltiples antecesores - esas confirmaciones han sido las puntas de las ramas que fueron fusionadas. En la mayoría de los casos, la fusión combina los cambios de dos ramas, y entonces la confirmación de fusión resultante tiene dos predecesores - uno de cada rama.

Consideramos una fusión sencilla y directa, la cual es posible cuando una rama difiere de la rama base, y luego agregamos confirmaciones por encima de la rama base.

Después consideramos fusiones de tres vías, y explicamos el proceso de tres etapas:

• Primero, Git localiza la base de fusión. Como recordatorio, este es la primera confirmación que es alcanzable desde ambas ramas.
• Segundo, Git calcula dos diffs - un diff desde la base de fusión a la primer rama, y otro diff desde la base de fusión a la segunda rama. Git genera parches basados en esos diffs.
• Tercero y último, Git aplica ambos parches a la base de fusión usando un algoritmo de fusión de 3 vías. El resultado es el estado de la nueva confirmación de fusión.

Viste la salida de git diff cuando estamos en un estado de conflicto, y cómo resolver conflictos sea de forma manual o con VS Code.

Por último, aprendiste Git rebase. Viste que git rebase es poderoso - pero también es bastante sencillo una vez que entiendes lo que hace. Es una herramienta para "copiar-pegar" confirmaciones (o, más específicamente, parches).

Ambos git merge y git rebase se usan para integrar cambios introducidos en diferentes historiales.

Aunque, difieren en cómo operan. Mientras que la fusión resulta en un historial divergente, los resultados de hacer rebase resulta en un historial linear. git rebase cambia el historial, mientras que git merge agrega al historial existente.

Con este entendimiento profundo de diffs, parches, fusión y rebase, deberías sentirte confiado al introducir cambios a un repositorio git.

La próxima parte se enfocará en lo que sucede cuando las cosas salen mal - cómo puedes cambiar el historial (con o sin git rebase), o encontrar confirmaciones "perdidas".

Parte 3 - Deshacer cambios

Alguna vez llegaste a un punto donde dijiste: "Oh-oh, ¿qué es lo que hice?" Supongo que lo hiciste, así como cualquiera que usa Git.

Tal vez confirmaste a la rama equivocada. Tal vez perdiste algo de código que has escrito. Tal vez confirmaste algo que no era tu intención de hacer.

Esta parte te dará las herramientas para reescribir el historial con confianza, de esa forma "deshacer" todo tipos de cambios en Git.

Así como las otras partes del libro, esta parte será practica aunque a profundidad - así que en vez de proveerte una lista de qué a hacer cuando las cosas salen mal, entenderemos los mecanismos subyacentes, así te sentirás confiable cuando sea que llegues al momento "oh-oh". En realidad, encontrarás estos momentos como oportunidades para un desafió interesante, en vez de un escenario espantoso.

Capítulo 9 - Git Reset

Nuestro trayecto comienza con un comando potente que puede ser usado para deshacer muchas diferentes acciones con Git - git reset.

Un pequeño recordatorio - Registrando cambios

En el capítulo 3, aprendiste cómo registrar cambios en Git. Si recuerdas todo de esta parte, puedes saltar la próxima sección.

Es útil imaginarse a Git como un sistema para registrar copias instantáneas de un sistema de archivos en el tiempo. Considerando un repositorio de Git, tiene tres "estados" o "árboles":

1. El directorio de trabajo, un directorio que tiene un repositorio asociado.
2. El área de preparación (índice) el cual tiene el árbol para la próxima confirmación.
3. El repositorio, el cual es una colección de confirmaciones y referencias.

Fíjate que con respecto a las convenciones de dibujo que utilizo: incluyo .git dentro del directorio de trabajo, para recordarte es una carpeta dentro de la carpeta del proyecto en el sistema de archivos. La carpeta .git en realidad contiene los objetos y las referencias del repositorio, como se explicó en el capítulo 4.

Demostración práctica

Usa git init para inicializar un nuevo repositorio. Escribe algo de texto en un archivo llamado 1.txt:

mkdir my_repo
cd my_repo
git init
echo Hello world > 1.txt

De los tres estados descritos arriba, ¿dónde está 1.txt ahora?

En el árbol de trabajo, ya que todavía no ha sido introducido al índice.

Para ponerlo en área de preparación, para agregarlo al índice, usa:

git add 1.txt

Fíjate que una vez que pones en el área de preparación 1.txt, Git crea un objeto blob con el contenido de este archivo, y lo agrega a la base de datos de objetos interno (dentro de la carpeta .git), como se cubrió en el capítulo 3 y capítulo 4. No lo dibujo como parte del "repositorio" ya que en esta representación, el "repositorio" se refiere a un árbol de confirmaciones y sus referencias, y este blob no ha sido parte de ninguna confirmación.

Ahora, usa git commit para confirmar tus cambios al repositorio:

git commit -m "Commit 1"

Creaste un nuevo objeto de confirmación, el cual incluye un puntero a un árbol que describe todo el árbol de trabajo. En este caso, este árbol consiste solamente de 1.txt dentro de la carpeta raíz. Además de un puntero al árbol, el objeto de confirmación incluye metadatos, tales como marcas de tiempo e información del autor.

Cuando se considera los diagramas, fíjate que solamente tenemos una sola copia del archivo 1.txt en el disco, y un objeto blob correspondiente en la base de datos de objetos de Git. El árbol del "repositorio" ahora muestra este archivo ya que es parte de la confirmación activa - eso es, el objeto de confirmación "Commit 1" apunta a un árbol que apunta al blob con los contenidos de 1.txt, el mismo blob al que el índice está apuntando.

Para más información sobre los objetos en Git (tales como confirmaciones y árboles), ve al capítulo 1.

Luego, crea un nuevo archivo, y agrégalo al índice, como antes:

echo second file > 2.txt
git add 2.txt

Luego, confirma:

git commit -m "Commit 2"

Muy importante, git commit hace dos cosas:

Primero, crea un objeto de confirmación, así que hay un objeto dentro de la base de datos de objetos interno de Git con un valor SHA-1 correspondiente. Este nuevo objeto de confirmación también apunta a la confirmación antecesor. Ese es la confirmación al que HEAD estaba apuntando cuando escribiste el comando git commit.

Segundo, git commit mueve el puntero de la rama activa – en nuestro caso, eso sería main, a que apunte al objeto de confirmación creado recientemente.

Introduciendo git reset

Ahora aprenderás cómo revertir el proceso de introducir una confirmación. Para eso, aprenderás el comando git reset.

git reset --soft

El último paso que hiciste antes fue git commit, el cual en realidad significa dos cosas – Git creó un objeto de confirmación y movió a main, la rama activa. Para deshacer este paso, usa el siguiente comando:

git reset --soft HEAD~1

La sintaxis HEAD~1 se refiere al primer antecesor de HEAD. Considera un caso donde tenía más de una confirmación en el gráfico de confirmaciones, digamos que "Commit 3" está apuntando a "Commit 2", el cual, en sí, está apuntando a "Commit 1". Y considera que HEAD estaba apuntando a "Commit 3". Podrías usar HEAD~1 para referirte a "Commit 2", y HEAD~2 se referiría a "Commit 1".

Así que, devuelta al comando: git reset --soft HEAD~1.

Este comando le pide a Git que cambie cualquier HEAD al que está apuntando. (Nota: En los diagramas de abajo, uso *HEAD para "cualquier HEAD al que está apuntando".) En nuestro ejemplo, el HEAD está apuntando a main. Así que Git solamente cambiará el puntero de main a que apunte a HEAD~1. Eso es, main apuntará al "Commit 1".

Sin embargo, este comando no afectará el estado del índice o el árbol de trabajo. Así que si usas git status verás que 2.txt está en el área de preparación, justo como antes que ejecutaste git commit:

El estado es ahora:

(Nota: quité 2.txt del "repositorio" en el diagrama ya que no es parte de la confirmación activa - eso es, el árbol apuntado por el "Commit 1" no referencia a este archivo. Sin embargo, no ha sido quitado del sistema de archivos - ya que existe en el árbol de trabajo y el índice.)

¿Qué hay sobre git log? Comenzará desde el HEAD, va al main, y luego a "Commit 1":

Fíjate que esto significa que "Commit 2" ya no es alcanzable desde nuestro historial.

¿Eso significa que el objeto de confirmación de "Commit 2" se elimina?

No, no se elimina. Todavía residen dentro de la base de datos de objetos interno de Git.

Si subes el historial actual ahora, usando git push, Git no empujará el "Commit 2" al servidor remoto (ya que no es alcanzable desde el HEAD actual), pero el objeto de confirmación todavía existe en tu copia local del repositorio.

Ahora, confirma nuevamente - y use el mensaje de confirmación de "Commit 2.1" para diferenciar este nuevo objeto desde el "Commit 2" original:

git commit -m "Commit 2.1"

Este el estado resultante:

Omití el "Commit 2" ya que no es alcanzable desde el HEAD, aunque su objeto existe en la base de datos de objetos interno de Git.

¿Por qué "Commit 2" y "Commit 2.1" son distintos? Inclusive si usáramos el mismo mensaje de confirmación, y aunque apunten al mismo objeto de árbol (de la carpeta raíz consistiendo de 1.txt y 2.txt), todavía tienen distintas marcas de tiempo, ya que fueron creados en diferentes tiempos. Ambos "Commit 2" y "Commit 2.1" ahora apuntan a "Commit 1", sino que solamente "Commit 2.1" es alcanzable desde el HEAD.

git reset --mixed

Es tiempo de deshacer aún mas allá. Esta vez, usa:

git reset --mixed HEAD~1

(Nota: --mixed es el conmutador predeterminado para git reset.)

Este comando comienza de la misma forma que git reset --soft HEAD~1. Eso es, el comando toma el puntero de cualquier HEAD que está apuntando ahora, el cual es la rama main, y lo establece a HEAD~1, en nuestro ejemplo - "Commit 1".

Luego, Git va más allá, efectivamente deshaciendo los cambios que hicimos al índice. Eso es, cambiar el índice para que coincida con el HEAD actual, el nuevo HEAD después de establecerlo en el primer paso.

Si ejecutáramos git reset --mixed HEAD~1, entonces el HEAD (main) sería puesto al HEAD~1 ("Commit 1"), y luego Git coincidiría el índice al estado de "Commit 1" - en este caso, significa que 2.txt ya no sería parte del índice.

Es tiempo de crear una nueva confirmación con el estado del "Commit 2" original. Esta vez necesita poner en el área de preparación a 2.txt nuevamente antes de crearlo:

git add 2.txt
git commit -m "Commit 2.2"

De forma similar a "Commit 2.1", "nombro" a esta confirmación "Commit 2.2" para diferenciarlo del del "Commit 2" original o "Commit 2.1" - estas confirmaciones resultan en el mismo estado que el "Commit 2" original, pero son distintos objetos de confirmación.

git reset --hard

Continúa, ¡deshaz aún más!

Esta vez, usa el conmutador --hard, y ejecuta:

git reset --hard HEAD~1

Una vez más, Git comienza con el paso --soft, estableciendo cualquier HEAD que esté apuntando a (main), a que apunte a HEAD~1 ("Commit 1").

Luego, moviéndonos al siguiente paso --mixed, coincidiendo con el índice con HEAD. Eso es, Git deshace el paso de 2.txt.

Luego viene el paso de --hard, donde Git va mas allá y coincide con el directorio de trabajo con la etapa del índice. En este caso, significa también quitar 2.txt del directorio de trabajo.

(Nota: en este caso específico, el archivo no está registrado, así que no será eliminado del sistema de archivos; no es realmente importante para entender git reset.)

Así que para introducir un cambio en Git, tienes tres pasos: cambias el directorio de trabajo, el índice, o el área de preparación, y luego confirmas una nueva copia instantánea con esos cambios. Para deshacer estos cambios:

• Si usamos git reset --soft, deshacemos el último paso.
• Si usamos git reset --mixed, también deshacemos el paso del copia instantánea.
• Si usamos git reset --hard, deshacemos los cambios al directorio de trabajo.

Escenarios de la vida real

Escenario #1

Así que en un escenario de la vida real, escribe "I love Git" en un archivo (love.txt), ya que todos amamos Git 😍. Adelante, pónlo en el área de preparación y confirmas esto también:

echo I love Git > love.txt
git add love.txt
git commit -m "Commit 2.3"

También, guarda una etiqueta así puedes volver a esta confirmación más tarde si es necesario:

git tag scenario-1

Oh, oops!

En realidad, no quería que lo confirmaras.

Lo que en realidad quería que hicieras era escribir algunas otras palabras lindas en este archivo antes de confirmarlo.

¿Qué puedes hacer?

Bueno, una forma de superar esto sería usar git reset --mixed HEAD~1, efectivamente deshaciendo tanto la confirmación y las acciones del área de preparación que tomaste:

git reset --mixed HEAD~1

Así que main apunta a "Commit 1" nuevamente, y love.txt ya no es una parte del índice. Sin embargo, el archivo permanece en el directorio de trabajo. Ahora puedes agregarle mas contenido:

echo and Gitting Things Done >> love.txt

Pónlo en el área de preparación y confirma tu archivo:

git add love.txt
git commit -m "Commit 2.4"

¡Bien hecho!

Lo tienes claro, lindo historial de "Commit 2.4" apuntando a "Commit 1".

Ahora tienes una nueva herramienta en tu caja de herramientas, git reset.

Esta herramienta es super, super útil, y puedes logar casi cualquier cosa con él. No es siempre la herramienta más conveniente, pero es capaz de resolver casi cualquier escenario de reescritura de historial si lo usas con cuidado.

Para principiantes, te recomiendo usar solamente git reset para casi cualquier vez que quieras deshacer en Git. Una vez que te sientas cómodo con él, continúa con otras herramientas.

Escenario #2

Consideremos otro caso.

Crea un nuevo archivo llamado new.txt; pónlo en el área de preparación y confirma:

echo this is a new file > new.txt
git add new.txt
git commit -m "Commit 3"

(Nota: En el dibujo omití los archivos del repositorio para evitar desorden. Commit 3 incluye 1.txt, love.txt y new.txt en esta etapa.)

Ups. En realidad, eso es un error. Estabas en main, y quería que crearas esta confirmación en una rama feature. Mi culpa 😇

Hay dos herramientas mas importantes que quiero que tomes de este capítulo. El segundo es git reset. El primero y el más importante es limpiar el estado actual versus el estado en el que quieres que esté.

Para este escenario, el estado actual y el estado deseado lucen así:

(Nota: En las diagramas siguientes, me referiré al estado actual como el estado "original" - antes de empezar el proceso de reescribir el historial.)

Notarás tres cambios:

1. main apunta a "Commit 3" (el azul) en el estado actual, pero apunta a "Commit 2.4" en el estado deseado.
2. feature_branch no existe en el estado actual, aunque existe y apunta al "Commit 3" en el estado deseado.
3. HEAD apunta a main en el estado actual, y apunta a feature_branch en el estado deseado.

Si lo puedes dibujar y sabes cómo usar git reset, puedes definitivamente salir de esta situación.

Así que nuevamente, lo más importante es tomar un respiro y dibujarlo.

Observando el dibujo de arriba, ¿cómo llegas al estado deseado del estado actual?

Hay unas pocas formas por supuesto, pero te presentaré una opción solamente para cada escenario. Siéntete libre de jugar con otras opciones también.

Puedes comenzar usando git reset --soft HEAD~1. Esto pondría a main a que apunte a la confirmación previa, "Commit 2.4":

git reset --soft HEAD~1

Mirando el diagrama actual-vs-deseado (original-vs-desired) nuevamente, puedes ver que necesitas una nueva rama, ¿no? Puedes usar git switch -c feature_branch para eso, o git checkout -b feature_branch (el cual hace lo mismo):

git switch -c feature_branch

Este comando también actualiza el HEAD a que apunte a la nueva rama.

Ya que usaste git reset --soft, no cambiaste el índice, así que actualmente tiene exactamente el estado que quieres confirmar - ¡qué conveniente! Puedes simplemente confirmar a feature_branch:

git commit -m "Commit 3.1"

Y llegas al estado deseado.

Escenario #3

¿Listo para aplicar tus conocimientos para casos adicionales?

Todavía en feature_branch, agrega algunos cambios a love.txt, y crea un nuevo archivo llamado cool.txt. Pónlos en el área de preparación y confirma:

echo Some changes >> love.txt
echo Git is cool > cool.txt
git add love.txt
git add cool.txt
git commit -m "Commit 4"

Oh, ups, en realidad quería que crearas dos confirmaciones separadas, una con cada cambio...

¿Quieres intentar este por ti mismo (antes de seguir leyendo)?

Puedes deshacer los pasos de confirmación y del área de preparación:

git reset --mixed HEAD~1

Siguiendo este comando, el índice ya no incluye esos dos cambios, pero todavía están en tu sistema de archivos:

Así que ahora, si solamente pones en el área de preparación a love.tx, puedes confirmarlo de forma separada:

git add love.txt
git commit -m "Love"

Luego, haz lo mismo para cool.txt:

git add cool.txt
git commit -m "Cool"

¡Genial!

Escenario #4

Para limpiar el estado, cambia a main y usa reset --hard para hacer que apunte a "Commit 3.1", mientras pones el índice y el directorio de trabajo al estado de "Commit 3.1":

git checkout main
git reset --hard <SHA_OF_COMMIT_3_1>

Crea otro archivo (another.txt) con algo de texto, y agrega algo de texto a love.txt. Pónlos en el área de preparación ambos cambios, y confirmarlos:

echo Another file > another.txt
echo More love >> love.txt
git add another.txt
git add love.txt
git commit -m "Commit 4.1"

Este debería ser el resultado:

Ups...

Así que esta vez, quería que esté en otra rama, pero no una nueva rama, sino - una rama ya existente.

Así que, ¿qué puedes hacer?

Te daré una pista. La respuesta es realmente corta y fácil. ¿Qué hacemos primero?

No, no reset. Dibujemos. Esto es lo primero en hacer, ya que haría todo lo demás más fácil. Así que este es el estado actual:

¿Y el estado deseado?

¿Cómo obtienes el estado actual al estado deseado, qué sería más fácil?

Una forma sería usar git reset como hiciste antes, pero hay otra forma que me gustaría intentar.

Fíjate que los siguientes comandos en sí asumen que la rama existing existe en tu repositorio, aunque no lo has creado anteriormente. Para coincidir un estado donde esta rama existe, puedes usar los siguientes comandos:

git checkout <SHA_OF_COMMIT_1>
git checkout -b existing
echo "Hello" > x.txt
git add x.txt
git commit -m "Commit X"
git checkout <SHA_OF_COMMIT_3_1> -- love.txt
git commit -m "Commit Y"
git checkout main

(El comando git checkout <SHA_OF _COMMIT_3_1> -- love.txt copia los contenidos de love.txt desde "Commit 3.1" al  índice y el directorio de trabajo, así puedes confirmarlo en la rama existing. Necesitamos el estado de love.txt en el "Commit Y" que sea lo mismo que "Commit 3.1" para evitar conflictos.)

Ahora tu historial debería coincidir con el que se muestra en la imagen con el subtítulo "Queremos que la confirmación "blue" esté en otra rama, existing".

Primero, haz que el HEAD apunte a la rama existente:

git switch existing

Intuitivamente, lo que quieres hacer es tomar los cambios introducidos en el "Commit 4.1", y aplicar estos cambios ("copiar-pegar") por encima de la rama exisitng. Y Git tiene una herramienta para eso.

Para pedirle a Git que tome los cambios introducidos entre una confirmación y su confirmación antecesor y sólo aplicar estos cambios en la rama activa, puedes usar git cherry-pick, un comando que introducimos en el capítulo 8. Este comando toma los cambios introducidos en la versión específicada y aplicarlos al estado de la confirmación activa. Ejecuta:

git cherry-pick <SHA_OF_COMMIT_4_1>

Puedes especificar el identificador SHA-1 de la confirmación deseada, pero también puedes usar git cherry-pick main,  como la confirmación cuyos cambios estás aplicando es al que está apuntando main.

git cherry-pick también crea un nuevo objeto de confirmación, y actualiza la rama activa a que apunte a este nuevo objeto, así que el estado resultante sería:

Marco a la confirmación como "Commit 4.2" ya que tiene una marca de tiempo, un antecesor y un valor SHA-1 distinto de "Commit 4.1", aunque los cambios que introducen son los mismos.

Hiciste buen progreso - la confirmación deseada está ahora en la rama ¡existing! Pero no queremos que estos cambios existan el rama main.  git cherry-pick solamente aplicó los cambios a la rama existente. ¿Cómo puedes quitarlos del main?

Una forma sería volver a main, y luego hacer reset:

git switch main
git reset --hard HEAD~1

Y el resultado:

¡Lo hiciste!

Fíjate que git cherry-pick en realidad calcula la diferencia entre la confirmación especificada y su antecesor, y luego aplica la diferencia a la confirmación activa. Esto significa que a veces, Git no será capaz de aplicar esos cambios debido a un conflicto.

También, fíjate que puedes pedirle a Git que haga cherry-pick de los cambios introducidos en cualquier confirmación, no solamente las confirmaciones referenciadas por una rama.

Recapitulación - Git Reset

En este capítulo, aprendimos cómo git reset opera, y clarificó sus tres modos principales de operación:

• git reset --soft <commit>, el cual cambia cualquier HEAD al que esté apuntando - a <commit>.
• git reset --mixed <commit>, el cual pasa por la etapa --soft, y también establece el estado del índice para que coincida con el de HEAD.
• git reset --hard <commit>, el cual pasa por las etapas --soft y --mixed, y luego pone el estado del directorio de trabajo para que coincide con el del índice.

Luego aplica tus conocimientos sobre git reset para que resuelva algunos problemas de la vida real que surgen cuando se usa Git.

Al entender la forma en que Git opera, y al limpiar el estado actual versus el estado deseado, puedes abarcar con toda confianza todo tipo de escenarios.

En capítulos futuros, cubriremos comandos de Git adicionales y cómo nos pueden ayudar a resolver todo tipos de situaciones no deseadas.

Capítulo 10 - Herramientas adicionales para deshacer cambios

En el capítulo previo, conociste a git reset. De hecho, git reset es una herramienta super poderosa, y te recomiendo mucho usarlo hasta que te sientas completamente confiado con él.

Aunque, git reset no es la única herramienta a nuestra disposición. Algunas veces, no es la herramienta más conveniente para usar. En otras veces, no es suficiente. Este corto capítulo abordo algunas herramientas que son útiles para deshacer cambios en Git.

git commit --amend

Considera el Escenario #1 del capítulo anterior nuevamente. Como recordatorio, escribiste "I love Git" en un archivo (love.txt), lo pusiste en el área de preparación y confirmaste este archivo:

Y luego me di cuenta que no quería que lo confirmaras a ese estado, sino - que escribieras algunas palabras de amor en este archivo antes de confirmarlo.

Para coincidir con este estado, simplemente revisa la etiqueta que creaste, el cual apunta a "Commit 2.3":

git checkout scenario-1

En el capítulo previo, cuando introdujimos git reset, resolviste este error usando git reset --mixed HEAD~1, deshaciendo efectivamente las acciones de confirmación y las acciones puesto en el área de preparación que hiciste.

Ahora me gustaría considerar otro enfoque. Continúa trabajando en el estado de la última confirmación introducida ("Commit 2.3", referenciado por la etiqueta "scenario-1"), y haz los cambios que quieras:

echo And I love this book >> love.txt

Agrega este cambio al índice:

git add love.txt

Ahora, puedes usar git commit con el conmutador --ammend, el cual le dice que sobreescriba la confirmación al que HEAD está apuntando. En realidad, creará otra nueva confirmación, que apunta a HEAD~1 ("Commit 1" en nuestro ejemplo), y hará que HEAD apunte a esta nueva confirmación creada. Proveyendo el argumento -m puedes especificar un nuevo mensaje de confirmación también:

git commit --amend -m "Commit 2.4"

Después de ejecutar este comando, HEAD apunta a main, el cual apunta a "Commit 2.4", el cual en sí apunta a "Commit 1". El "Commit 2.3" previo ya no es alcanzable desde el historial.

Esta herramienta es útil cuando quieras sobrescribir rápidamente la última confirmación que creaste. De hecho, podrías usar git reset para lograr lo mismo, pero puedes ver git commit --ammend como un atajo más conveniente.

git revert

Muy bien, otro día, otro problema.

Agrega el siguiente texto a love.txt, pónlo en el área de preparación y confirma como sigue:

echo This is more tezt >> love.txt
git add love.txt
git commit -m "Commit 3"

Y empújalo al servidor remoto:

git push origin HEAD

Am, ups 😓…

Noté algo. Tuve un error de tipado aquí. Escribí "This is more tezt" en vez de "This is more text". Woops. Así que, ¿cuál es el problema grande ahora? Hice push, lo que significa que alguien más ya podría haber hecho push de esos cambios.

Si sobrescribo esos cambios usando git reset, tendremos historiales distintos, y todo el infierno podría desatarse. Puedes sobrescribir tu propia copia del repo  tanto como quieras hasta que hagas push.

Una vez que hagas push del cambio, necesitas estar seguro que nadie más ha solicitado esos cambios si vas a reescribir el historial.

De forma alternativa, puedes usar otra herramienta llamada git revert. Este comando toma la confirmación que le estás proveyendo y calcula el diff de su confirmación antecesor, así como git cherry-pick, pero esta vez, calcula los cambios inversos. Eso es, si en la confirmación especificada agregaste una línea, el servidor eliminaría la línea, y vice versa.

En nuestro caso estamos revirtiendo "Commit 3", así que la reversa sería eliminar la línea "This is more tezt" de love.txt. Ya que "Commit 3" está referenciado por main y HEAD, podemos usar cualquier de las referencias nombradas en este comando:

git revert creó un nuevo objeto de confirmación, lo cual significa que es una adición al historial. Al usar git revert, no reescribiste el historial. Admitiste tu error pasado, y esta confirmación es un reconocimiento que cometiste un error y ahora lo arreglaste.

Alguno diría esta es la forma más madura. Alguno diría que no es un historial tan limpio como lo obtendrías si usaras git reset para reescribir la confirmación previa. Pero este es una forma de evitar reescribir el historial.

Ahora puedes arreglar el error de tipado y confirmar nuevamente:

echo This is more text >> love.txt
git add love.txt
git commit -m "Commit 3.1"

Puedes usar git revert para revertir una confirmación que no sea HEAD. Digamos que quieres revertir el antecesor de HEAD, puedes usar:

git revert HEAD~1

O podrías proveer el SHA-1 de la confirmación para revertir.

Fíjate ya que Git aplicará el parche de reversa del parche anterior - esta operación podría fallar, ya que el parche ya no se podría aplicar y tendrías un conflicto.

Git Rebase como una herramienta para deshacer cosas

En el capítulo 8, aprendiste sobre Git rebase. Lo consideramos principalmente como una herramienta para combinar cambios introducidos en diferentes ramas. Sin embargo, siempre y cuando no hayas hecho push de tus cambios, usando rebase en tu propia rama puede ser una forma muy conveniente para reordenar tu historial de confirmaciones.

Para ello, usualmente harías rebase en una sola rama, y usa el rebase interactivo. Considera nuevamente este ejemplo abarcado en el capítulo 8, donde trabajé desde feature_branch_2, y específicamente edité el archivo code.py. Comencé por cambiar todas las cadenas para que sean envueltas por comillas dobles en vez de comillas simples:

Luego, lo puse en el área de preparación y confirmé:

git add code.py
git commit -m "Commit 17"

Luego decidí agregar una nueva función al principio del archivo:

Nuevamente, lo puse en el área de preparación y confirmé:

git add code.py
git commit -m "Commit 18"

Y ahora me di cuenta que en realidad me olvidé de cambiar las comillas simples a comillas dobles al envuelto de __main__ (como lo has visto), así que hice eso también:

Por supuesto, lo puse en el área de preparación y confirmé este cambio:

git add code.py
git commit -m "Commit 19"

Ahora, considera el historial:

Como expliqué en el capítulo 8, obtuve un estado con dos confirmaciones que están relacionados uno con el otro, "Commit 17" y "Commit 19" (cambiando ' a "), pero están separados por el "Commit 18" que no está relacionado (donde agregué una nueva función).

Este es un caso básico donde git rebase sería práctico, para deshacer los cambios locales antes de hacer push de un historial limpio.

Intuitivamente, quiero editar el historial aquí:

Puedo hacer rebase del historial desde "Commit 17" a "Commit 19", por encima de "Commit 15". Para hacer eso:

git rebase --interactive --onto <SHA_OF_COMMIT_15> <SHA_OF_COMMIT_15>

Esto resulta en la siguiente pantalla:

Así que, ¿qué haría? Quiero poner a "Commit 19" antes de "Commit 18", así viene justo después de "Commit 17". Puedo ir más lejos y hacerles squash ("aplastarlos", de manera figurativa), así:

Ahora cuando recibo una pantalla para escribir un mensaje de confirmación, puedo proveer el mensaje "Commit 17+19":

Y ahora, vemos nuestro precioso historial:

La sintaxis usada arriba, git rebase --interactive --onto <COMMIT X> <COMMIT X> sería la sintaxis más usada comúnmente por aquellos que usan rebase regularmente. La manera de pensar que estos desarrolladores usualmente tienen es crear confirmaciones atómicas mientras trabajan, todo el tiempo, sin asustarse de cambiarlos luego. Entonces, antes de hacer push de sus cambios, harían rebase a todo el conjunto de cambios desde el último push, y re-arreglarlo así el historial se vuelve coherente.

git reflog

Es tiempo de considerar un caso más alarmante.

Vuelve al "Commit 2.4":

git reset --hard <SHA_OF_COMMIT_2_4>

Haz algo, escribe algo de código, y agrégalo a love.txt. Pónlo en el área de preparación a este cambio, y confírmalo:

echo lots of work >> love.txt
git add love.txt
git commit -m "Commit 3.2"

(Estoy usando "Commit 3.2" para indicar que este no es la misma confirmación que "Commit 3" que usamos cuando explicamos sobre git revert.)

Hice lo mismo en mi máquina, y usé la tecla flecha arriba Up en mi teclado para volver a los comandos anteriores, y luego presioné Enter, y... Wow.

Whoops.

¿Acaso usé git reset --hard? 😨

¿Pero qué pasó en realidad? Como aprendiste en el capítulo previo, Git movió el puntero a HEAD~1, de esa forma la última confirmación, con todo mi trabajo precioso, no es alcanzable desde el historial actual. Git también quitó todos los cambios desde el área de preparación, y luego hice coincidir el directorio de trabajo con el del estado del área de preparación.

Eso es, todo coincide con este estado donde mi trabajo... se ha ido.

Momento de terror. Me voy asustando.

Pero, realmente, ¿hay una razón para asustarse? No realmente... Somos personas relajadas. ¿Qué hacemos? Bueno, intuitivamente, ¿realmente, realmente se ha ido la última confirmación?

No. ¿Y por qué no? Todavía existe dentro de la base de datos interno de Git.

Si tan solo supiera dónde está, sabría el valor SHA-1 que identifica a esta confirmación, y podríamos restaurarlo. Inclusive podría deshacer lo deshecho, y hacer reset y volver a esta confirmación.

En realidad, lo único que realmente necesito aquí es el SHA-1 de la confirmación "eliminada".

Ahora la pregunta es, ¿cómo lo encuentro? ¿git log sería útil?

Bueno, no realmente. git log iría al HEAD, el cual apunta a main, el cual apunta a la confirmación antecesora de la confirmación que estamos buscando. Luego, git log recorrería a través de la cadena de antecesores, el cual no incluye la confirmación con mi trabajo precioso.

Afortunadamente, los genios que crearon Git también crearon un plan de recuperación para nosotros, y se llama el reflog.

Mientras trabajas con Git, cuando sea que cambies el HEAD, lo cual lo puedes hacer usando git reset, pero también con otros comandos como git switch o git checkout, Git agrega una entrada al reflog.

¡Encontramos nuestra confirmación! Es el que comienza con 0fb929e.

También podemos relacionarlo por su "nickname" - HEAD@{1}. De forma similar Git usa al HEAD~1 para obtener el primer antecesor de HEAD, y HEAD~2 para que se refiera al segundo antecesor de HEAD, y así sucesivamente, Git usa HEAD@{1} para referirse al primer reflog antecesor de HEAD, eso es, a donde apuntaba HEAD en el paso anterior.

También podemos pedirle a git rev-parse que nos muestre su valor:

Nota: En caso que estés usando Windows, podrías necesitar envolverlo con comillas - así:

git rev-parse "HEAD@{1}"

Otra forma de ver el reflog es usando git log -g, el cual le pide a git log que considere el reflog:

Puedes ver en la salida de git log -g que la entrada de reflogHEAD@{0}, justo como el HEAD, apunta a main, el cual apunta a "Commit 2". Pero el antecesor de esa entrada en el reflog apunta a "Commit 3".

Así que para volver a "Commit 3", puedes usar git reset --hard HEAD@{1} (o el valor SHA-1 de "Commit 3"):

Y ahora, si haces git log:

¡Nos salvamos!

¿Qué sucedería si usara este comando nuevamente? ¿Y ejecutara git reset --hard HEAD@{1}?

Git pondría al HEAD a dónde HEAD estaba apuntando antes del último reset, lo que significa a "Commit 2". Podemos continuar todo el día:

Recapitulación - Herramientas adicionales para Deshacer Cambios

En el capítulo anterior, aprendiste cómo usar git reset para deshacer cambios.

En este capítulo, agrandaste tu caja de herramientas para deshacer cambios en Git con algunos comandos nuevos:

• git commit --ammend - el cual "sobreescribe" la última confirmación con el área de preparación del índice. Mayoritariamente útil cuando confirmaste algo y quieres modificar la última confirmación.
• git revert - el cual crea una nueva confirmación, que revierte una confirmación anterior agregando una nueva confirmación al historial con los cambios revertidos. Especialmente útil cuando la confirmación "defectuosa" ya ha sido subida al remoto.
• git rebase - el cual ya los conocías desde el capítulo 8, y es útil para reescribir el historial de confirmaciones múltiples, especialmente antes de empujarlos.
• git reflog (y git log -g) - el cual rastrea todos los cambios hasta el HEAD, así puedes encontrar el valor SHA-1 de una confirmación al que necesitas volver.

La herramienta más importante, inclusive más importante que las herramientas que listé, es limpiar la situación actual vs el desado. Créeme en esta, hará que cada situación parezca menos intimidante y la solución más clara.

Hay herramientas adicionales que te permiten revertir cambios en Git (proveeré enlaces en el apéndice), pero la colección de herramientas que cubrí aquí debería prepararte para abarcar cualquier desafío con confianza.

Capítulo 11 - Ejercicios

Este capítulo incluye algunos ejercicios para profundizar tus conocimientos de las herramientas que aprendiste en la Parte 3. La versión completa de este libro también incluye soluciones detalladas de cada una.

Los ejercicios se encuentran en este repositorio:

https://github.com/Omerr/undo-exercises.git

Cada ejercicio está en una rama con el nombre exercise_XX, así que el Ejercicio 1 se encuentra en la rama exercise_01, el Ejercicio 2 se encuentra en la rama exercise_02 y así sucesivamente.

Nota: como se explicó en los capítulos previos, si trabajas con confirmaciones que pueden ser encontradas en un servidor remoto (los cuales son en la que estás en este caso, ya que estás usando mi repositorio "undo-exercises"), deberías probablemente usar git revert en vez de git reset. De la misma forma con git rebase, el comando git reset también reescribe el historial - y así te refrenas de usarlo en las confirmaciones en las que otros podían basarse.

Para los propósitos de estos ejercicios, puedes asumir que nadie ha clonado o haya descargado (pull) el código del repositorio remoto. Sólo recuerda - en la vida real, probablemente deberías usar git revert en vez de comandos que reescriben el historial en tales casos.

Ejercicio 1

En la rama execise_01, considera el archivo hello.txt:

Este archivo incluye un error de tipado (en el último caracter). Encuentra la confirmación que introdujo este error de tipado.

Ejercicio (1a)

Quita esta confirmación del historial alcanzable usando git reset (con los argumentos correctos), arregla el error de tipado, y confirma nuevamente. Considera tu historial.

Revierte al estado previo.

Ejercicio (1b)

Quita la confirmación defectuosa usando git commit --ammend, y vuelve al mismo estado del historial como al final del ejercicio (1a).

Revierte al estado previo.

Ejercicio (1c)

Haz revert de la confirmación defectuosa usando git revert y arregla el error de tipado. Considera tu historial.

Revierte al estado previo.

Ejercicio (1d)

Usando git rebase, vuelve al misma estado como al final del ejercicio (1a).

Ejercicio 2

Cambia a la rama exercise_02, y considera los contenidos de exercise_02.txt:

Un archivo sencillo, con un caracter en cada línea.

Considera el historial (usando git lol):

Oh mi. Cada caracter fue introducido en una confirmación separada. ¡Eso no tiene sentido!

Usa las herramientas que has adquirido para crear un historial donde la creación de exercise_02.txt está hecho en una sola confirmación.

Ejercicio 3

Considera el historial en la rama exercise_03:

Esto parece un desastre. Notarás que:

• El orden está sesgado. Necesitamos que "Commit 1" sea la primera confirmación en esta rama, y tenga a "Initial Commit" como su antecesor, seguido de "Commit 2" y así sucesivamente.
• No deberíamos tener "Commit 2a" y "Commit 2b", o "Commit 4a" y "Commit 4b" - estos dos pares necesitan ser combinados en una sola confirmación cada uno - "Commit 2" y "Commit 4".
• Hay un error de tipado en el mensaje de confirmación de "Commit 1", no debería tener 3 m.

Arregla estos errores, pero básate en los cambios de cada confirmación original. El historial resultante debería lucir así:

Ejercicio 4

Este ejercicio en realidad consiste de tres ramas: exercise_04, exercise_04_a, y exercise_04_b.

Para ver el historial de estas ramas sin las otras, usa la siguiente sintaxis:

git lol --branches="exercise_04*"

El resultado es:

Tu objetivo es hacer que exercise_04_b sea independiente de exercise_04_a. Eso es, obtener este historial:

¡Buena suerte!

Parte 4 - Herramientas de Git Fantásticas y Útiles

Git tiene un montón de comandos, y estos comandos tienen muchísimas opciones y argumentos. Podría intentar cubrirlos todos (aunque cambian con el tiempo), pero no veo el punto en ello. Probablemente deberías conocer un sub-conjunto de estos comandos realmente bien, aquellos que usas regularmente. Luego, siempre puedes buscar por un comando específico para realizar una tarea a mano.

Esta parte se basa en las bases que adquiriste en las partes previas, y cubre comandos específicos y opciones que podrías encontrar útiles. Dado tu entendimiento de cómo funciona Git, tener estas pequeñas herramientas puede hacerte un verdadero pro para llevar a Git a cabo.

Capítulo 12 - Git Log

Usaste git log muchas veces a lo largo de los distintos capítulos, y probablemente lo has usado muchas veces antes de leer este libro.

La mayoría de los desarrolladores usan git log, pocos lo usan de forma efectiva. En este capítulo aprenderás ajustes útiles para sacar el mayor provecho a git log. Una vez que te sientas cómodo con los diferentes conmutadores de este comando, será un verdadero cambio en tu día a día trabajando con Git.

Pensando en ello, git log abarca la esencia de cada versión del sistema de control - es decir, para registrar cambios en las versiones. Registras versiones de esa forma puedes considerar el historial de tu proyecto - tal vez revertir o aplicar cambios específicos, preferir cambiar a un punto distinto en el tiempo y probar las cosas allí. Tal vez te gustaría saber quién contribuyó una cierta pieza de código o cuando lo hicieron.

Mientras que git sí preserva esta información usando objetos de confirmación, eso también apunta a sus confirmaciones antecesoras, y referencias a objetos de confirmación (tales como ramas o HEAD), este almacenamiento de versiones no es suficiente. Sin ser capaz de encontrar la confirmación relevante que te gustaría considerar, o reunir información relevante sobre ello, tener estos datos almacenados es bastante inútil.

Puedes imaginarte a tus objetos de confirmación como distintos libros que se apilan en un pila gigante, o en una biblioteca, llenando largos estantes. La información que podrías necesitar está en estos libros, pero si no tienes un índice - una forma para saber en qué libro yace la información que buscas, o dónde este libro se localiza dentro de la biblioteca - no serías capaz de hacer uso de él. git log es esta indexación de tu biblioteca - es una forma de encontrar las confirmaciones relevantes y la información sobre ellos.

Los argumentos útiles para git log que aprenderás en este capítulo dan formato en cómo se muestran las confirmaciones en el log, o filtran confirmaciones específicas.

git lol, un alias que he usado a lo largo de este libro, usa algunos de estos conmutadores, como lo demostraré. Siéntete libre de ajustar este alias (o crea otro desde cero) después de leer este capítulo.

Como en otros capítulos, el objetivo no es proveer una referencia completa, por lo tanto no proveeré todos los diferentes conmutadores de git lol. Me enfocaré en los conmutadores que creo que los encontrarás útiles.

Filtrando comandos

Considera la salida predeterminada de git log:

El log comienza desde el HEAD, y sigue la cadena de antecesores.

Las Confirmaciones (no) alcanzables desde...

Cuando escribes git log <revision>, git log incluirá todas las entradas accesibles desde <revision>. Con "accesible", me refiero accesible al seguir la cadena de antecesores. Así que ejecutando git log sin argumentos es lo mismo que ejecutar git log HEAD.

Puedes especificar múltiples revisiones para git log- si escribes git log branch_1 branch_2, le pides a git log que incluya cada confirmación que es alcanzable desde branch_1 o branch_2 (o ambos).

git log excluirá cualquier confirmación que sea alcanzable desde las revisiones precedidos por un ^.

Por ejemplo, el siguiente comando:

git log branch_1 ^branch_2

le pide a git log que incluya cada confirmación que es accesible desde branch_1, pero no aquellos que son accesibles desde branch_2.

Considera el historial cuando uso git log feature_branch_2 en este repo:

El historial incluye todas las confirmaciones accesibles por feature_branch_1. Ya que esta rama "se creó" desde main (eso es, "Commit 12", al que apunta main, es accesible desde la cadena de antecesores) - el log también incluye todas las confirmaciones accesibles desde main.

¿Qué sucedería si ejecutara este comando?

git log feature_branch_1 ^main

En efecto, git log muestra sólo "Commit 13" y "Commit 16", los cuales son accesibles desde feature_branch_1 pero no desde main.

git log --all

Para seguir las confirmaciones que son accesibles desde cualquier referencia nombrada o (cualquier ref en refs/) o desde el HEAD.

Por Autor

Si sabes que estás buscando una confirmación que tiene una persona específica como autor, puedes filtrar estas confirmaciones usando el nombre del usuario o su email, así:

git log --author="Name"

Puedes usar expresiones regulares para buscar los nombres de los autores que coinciden con un patrón específico, por ejemplo:

git log --author="John\|Jane"

filtrará las confirmaciones cuyo autor es John o Jane.

Por Fecha

Cuando sabes que el cambio que estás buscando ha sido confirmado dentro de una fracción de tiempo específico, puedes usar --before o --after para filtrar las confirmaciones desde esa fracción de tiempo.

Por ejemplo, para obtener todas las confirmaciones introducidos después del 12 de Abril de 2023 (inclusivo), usa:

git log --after="2023-04-12"

Por Rutas

Puedes pedir a git log que sólo muestre las confirmaciones donde los cambios han sido introducidos en rutas específicas. Fíjate que no significa que cualquier confirmación que apunte a un árbol que incluya los archivos en cuestión, sino más bien que si calculamos la diferencia entre la confirmación en cuestión y sus antecesores, veríamos que al menos uno de las rutas ha sido modificado.

Por ejemplo, puedes usar:

git log --all -- 1.py

para encontrar todas las confirmaciones que son accesibles desde cualquier puntero nombrado, o HEAD, e introducir un cambio a 1.py. Puedes especificar múltiples rutas:

git log --all -- 1.py 2.py

El comando previo hará que git log incluya confirmaciones accesibles que introdujeron un cambio a 1.py o 2.py (o ambos).

También puedes usar un patrón glob, por ejemplo:

git log -- *.py

incluirá las confirmaciones que son accesibles desde el HEAD que incluye un cambio a cualquier archivo en el directorio raíz cuyo nombre termina con un .py. Para buscar un archivo que termine con .py, puedes usar:

git log -- **/*.py

Por Mensaje de Confirmación

Si conoces el mensaje de confirmación (o partes de él) de la confirmación que estás buscando, puedes usar el conmutador --grep para "git log", por ejemplo:

git log --grep="Commit 12"

devuelve la confirmación con el mensaje "Commit 12".

Por Contenido de Diff

Este es super útil, y me ha salvado incontables veces. Al usar git log -S, puedes buscar confirmaciones que introducen o quitan una línea en particular del código fuente.

Esto es práctico, por ejemplo, cuando sabes que has creado algo en el repo, pero no sabes dónde está ahora. No puedes encontrarlo en ningún lugar de tu sistema de archivos (no está en el HEAD), y sabes que debe estar ahí - acechando en algún lugar en esta librería (montón de confirmaciones) que tienes.

Digamos que recuerdo dónde escribí una línea con el texto Git is awesome, pero no puedo encontrarlo ahora. Podría ejecutar:

git log --all -S"Git is awesome"

Fíjate que usé --all para evitar limitarme a confirmaciones alcanzables desde el HEAD.

También puedes buscar una expresión regular, usando -G:

git log --all -G"Git .* awesome"

Formateando el Log

Considera la salida predeterminada de git log nuevamente:

El log comienza desde el HEAD, y sigue la cadena de antecesores.

Cada entrada del log comienza con una línea con commit y luego el SHA-1 de la confirmación, tal vez seguida de punteros adicionales que apuntan a esta confirmación.
Luego es seguido por el autor, fecha, y mensaje de confirmación.

--oneline

La principal dificultad con la salida predeterminada de git log es que es difícil de entender un historial con más de unas pocas confirmaciones, ya que simplemente no los ves a todos.

En la salida de git log que se muestra abajo, solamente cuatro objetos de confirmación aparecieron en mi pantalla. Usando git log --oneline provee una vista más concisa, mostrando el SHA-1 de la confirmación, al lado de su mensaje, y referencia nombradas si son relevantes:

Si deseas omitir las referencias nombradas, puedes agregar el conmutador --no-decorate:

Para pedirle a git log explícitamente que muestre decoraciones, puedes usar git log --decorate.

--graph

git log --oneline muestra una representación compacta. Eso es genial cuando tenemos un historial linear, tal vez en una sola rama. Pero, ¿qué sucede cuando tenemos múltiples ramas, que podría diferir uno del otro?

Considera la salida del siguiente comando en mi repositorio:

git log --oneline feature_branch_1 feature_branch_2

git log muestra cualquier confirmación accesible por feature_branch_1, feature_branch_2, o ambos. Pero, ¿cómo se ve el historial? ¿feature_branch_2 difirió de feature_branch_1? ¿O difirió de main? Es imposible distinguirlo desde esta vista.

Aquí es donde --graph viene a mano, dibujando un gráfico ASCII representando la estructura de la rama del historial de confirmaciones. Si agregamos esta opción al comando previo:

En realidad puedes ver que feature_branch_1 se creó desde main (ya que "Commit 12", main, es el antecesor de "Commit 13"), y también que feature_branch_2 se creó desde main (ya que el antecesor de "Commit 14" también es "Commit 12").

El símbolo * nos dice "en" qué rama está una cierta confirmación, así sabes con certeza que "Commit 13" está en feature_branch_1, y no en feature_branch_2.

--pretty=format

El resultado de arriba, ¡ya es muy útil! Aunque, le falta un par de cosas. No sabemos el autor o el tiempo de la confirmación. Estos dos detalles fueron incluidos en la salida predeterminada de git log el cual fue muy largo. Tal vez, ¿los podemos agregar de una forma más compacta?

Al usar --pretty=format:, puedes mostrar la información de cada confirmación en varias formas usando marcadores de posición al estilo de printf.

En el siguiente comando, los marcadores de posición %s, %an y %cd son reemplazados por el sujeto de la confirmación (mensaje), nombre de autor, y la fecha de la confirmación, respectivamente.

git log --oneline --graph feature_branch_1 feature_branch_2 --pretty=format:"%s (%an) [%cd]"

La salida luce así:

Eso es útil, pero no bueno al mirarlo. Entonces podemos usar otros trucos de formateo, específicamente %C(color) que cambiará el color a color, hasta que alcance un %Creset que resetea el color. Para hacer que el nombre del autor sea amarillo, puedes usar:

git log --oneline --graph feature_branch_1 feature_branch_2 --pretty=format:"%s %C(yellow)(%an)%Creset [%cd]"

Para algunos colores, como rojo o verde, es innecesario incluir el paréntesis, así que rojo es suficiente.

¿Cómo se estructura git lol?

Cuando ejecuto git lol, en realidad ejecuta lo siguiente:

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

¿Puedes tomar esto poco a poco?

Ya conoces --graph, el cual hace que la salida incluya un gráfico ASCII.

--abbrev-commit usa un prefijo corto del SHA-1 completo de la confirmación (en mi configuración, los siete primero caracteres).

El resto es sólo el coloreamiento de varios detalles sobre la confirmación:

git lol --all

Me gusta esta salida porque lo encuentro claro. Me da la información que necesito, con colores suficientes así cada detalles se destaca sin lastimar mis ojos. Pero si prefieres otra información, otros colores, un diferente orden, o cualquier cosa - adelante y ajústalo a tu gusto.

Definiendo un alias

Como sabes, defino a git lol como un alias - eso es, cuando ejecuto git lol, ejecuta el comando largo que proveí anteriormente.

¿Cómo puedes crear un alias en Git?

La forma mas fácil es usar git alias, así:

git config --global alias.co checkout

Este comando pone co para que sea un alias para el comando checkout, así puedes usar git co main en vez de git checkout main.

Para definir git lol como un alias, puedes usar:

git config --global alias.lol 'log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit'

Capítulo 13 - Git Bisect

Ups.

Tengo un error.

Sí, sucede a veces, a todos nosotros. Algo en mi sistema está roto, y no puedo distinguir por qué. He estado depurando por un rato, pero la solución no está clara.

Puedo decir que dos semanas atrás, esto no sucedió. Afortunadamente para mí, he estado usando Git (obviamente lo sé...), así que puedo volver en el tiempo y probar una versión anterior de mi código. En efecto, en esta versión - todo funcionó bien.

Pero... he hecho muchos cambios en estas dos semanas. Ay, no solo yo - mi equipo completo ha contribuido con confirmaciones que agregan, eliminan, o modifican partes del código base. ¿Por dónde comienzo? ¿Debería ir por cada cambio introducido en esas dos semanas?

Ingresa - git bisect.

El objetivo de git bisect es ayudarte a encontrar la confirmación donde un error fue introducido, de una manera efectiva.

¿Cómo funciona git bisect?

git bisect primero te pide que marques una confirmación como "mala" (donde el error ocurre), y otra confirmación como "buena" (una sin el error). Luego, verifica una confirmación a medio camino entre estas dos confirmaciones, y luego te pide que identifiques la confirmación como "buena" o "mala". Este proceso se repite hasta que encuentres la primer confirmación "mala".

La clave aquí es usar la búsqueda binaria - mirando al punto a medio camino y decidir si es la nueva punta o el piso de la lista de confirmaciones, puedes encontrar la confirmación correcta de forma eficiente. Inclusive si tienes 10,000 confirmaciones que cazar, solamente toma un máximo de 13 pasos para encontrar la primer confirmación que introdujo el error.

Ejemplo de git bisect

Para este ejemplo, usaré el repositorio en https://github.com/Omerr/bisect-exercise.git. Para crearlo, adaptaré el repositorio de código abierto https://github.com/bast/git-bisect-exercise (acorde a su licencia).

En este repositorio, tenemos un archivo python sencillo que se usa para calcular el valor de pi (el cual es aproximadamente 3.14). Si ejecutas python3 get_pi.py en el main, sin embargo, obtendrás un resultado erróneo:

Esta rama consiste de más de 500 confirmaciones.

Encuentra la primer confirmación en esta rama usando:

git log --oneline | tail -n 1

Si ejecutas checkout para esta confirmación y ejecutas python3 get_pi.py nuevamente, el resultado es correcto:

Así que en algún lugar entre el HEAD y la confirmación f0ea950, un cambio fue introducido que resultó en esta salida errónea.

Para encontrarlo usando git bisect, comienza el proceso de bisect, y marca esta confirmación como "buena":

git bisect start
git bisect good

Por defecto, git bisect good tomaría el HEAD como la confirmación "buena". Para marcar a main como "mala", puedes usar git bisect bad main:

git bisect comprobó el número de confirmación 251, el "punto medio" de la rama main. ¿El estado de esta confirmación produce la saluda correcta o errónea?

Todavía obtenemos la salida errónea, lo cual significa que podemos descartar las confirmaciones 252 hasta el 500 (y confirmaciones adicionales después de ese), y acortar nuestra búsqueda desde la confirmación 2 hasta el 251. Marca a éste como "mala":

git bisect comprobó la confirmación "media" (número 126), y ejecutando el código nuevamente resulta en la respuesta, ¡correcta! Esto significa que esta confirmación es "buena", y que la primer confirmación "mala" está en algún lugar entre 127 y 251. Márcalo como "buena".

Genial, git bisect nos toma a la confirmación 188, ya que esta es la confirmación "media" entre 127 y 251. Al ejecutar el código nuevamente, puedes ver que el resultado es incorrecto, así que este es en realidad una confirmación "mala", lo que significa que la primer confirmación defectuosa se encuentre en algún lugar entre 127 y 188. Como puedes ver, git bisect achica el espacio de búsqueda a la mitad en cada iteración.

Vamos, ahora es tu turno - ¡continúa desde aquí! Prueba el resultado de python3 get_pi.py y usa git bisect good o git bisect bad para marcar la confirmación según sea el caso. ¿Cuál es la confirmación defectuosa?

Cuando estés listo, usa git bisect reset para detener el proceso bisect.

git bisect automático

En el ejemplo previo, podrías simplemente ejecutar pytho3 get_pi.py y verificar el resultado. En otras veces, el proceso de validar si una cierta confirmación es "buena" o "mala" puede ser tramposo, propenso a errores, o solo lleva mucho tiempo.

Es posible automatizar el proceso de git bisect al crear código que debería ser ejecutado en cada iteración, devolviendo 0 cuando la confirmación actual es "buena", y un valor entre 1-127 (inclusivo), excepto 125, si debería ser considerada "mala".

La sintaxis es:

git bisect run my_script arguments

Ya que este libro no trata sobre programación y no se asume que conoces un lenguaje de programación específico, no mostraré un ejemplo de la implementación my_script. El archivo README.md en el repositorio usado en este capítulo (https://github.com/Omerr/bisect-exercise.git) incluye un ejemplo para un script que puedes ejecutar con git bisect run para encontrar automáticamente la confirmación defectuosa para el ejemplo previo.

Capítulo 14 - Otros comandos útiles

Este capítulo resalta algunos comandos que ya han sido mencionados en los capítulos anteriores. Los estoy poniendo aquí juntos así puedes revisarlos como una referencia cuando sea necesario.

git cherry-pick

Introducido en el capítulo 8, este comando toma una confirmación dada, calcula el parche que esta confirmación introduce al calcular la diferencia entre la confirmación del antecesor y la confirmación misma, y luego git bisect "repite" esta diferencia. Es como "copiar-pegar" una confirmación, es decir, el diff de esta confirmación introducida.

En el capítulo 8 consideramos la diferencia introducida por el "Commit 5" (usando git diff main <SHA_OF_COMMIT_5>):

Puedes ver que en esta confirmación, John comenzó a trabajar en una canción llamada "Lucy in the Sky with Diamonds":

Como recordatorio, también puedes usar el comando git show para obtener la misma salida:

git show <SHA_OF_COMMIT_5>

Ahora, si haces cherry-pick a esta confirmación, introducirás este cambio específicamente, en la rama activa. Puedes cambiar a la rama main:

git checkout main (or git switch main)

Y crear otra rama:

git checkout -b my_branch (or git switch -c my_branch)

Luego, haz cherry-pick al "Commit 5":

git cherry-pick <SHA_OF_COMMIT_5>

Considera el log (salida de git lol):

Parece que copiaste-pegaste a "Commit 5". Recuerda que inclusive tiene el mismo mensaje de confirmación, e introduce los mismos cambios, e inclusive apunta al mismo objeto árbol como el "Commit 5" original en este caso - todavía es un objeto de confirmación distinto, ya que fue creado con una marca de tiempo distinto.

Mirando a los cambios, usando git show HEAD:

Son los mismos como los de "Commit 5".

git revert

git revert es esencialmente la reversa de git cherry-pick, introducido en el capítulo 10. Este comando toma la confirmación con el que le estás proveyendo y calcula el diff desde su confirmación antecesora, así como git cherry-pick, pero esta vez, calcula los cambios de reversa. Eso es, si en la confirmación especificada agregaste una línea, la reversa eliminaría la línea, y vice versa.

git add -p

Poniendo en el área de preparación los cambios es una parte integral de introducir cambios a Git. A veces, deseas poner en el área de preparación todos los cambios juntos (con git add .), o tal vez poner en stage todos los cambios de un archivo específico (usando git add <file_path>). Aunque hay veces donde sería conveniente poner en stage solamente ciertas partes de los archivos modificados.

En el capítulo 6, introdujimos git add -p. Este comando te permite poner en stage ciertas partes de los archivos, al separarlos en pequeños trozos (p significa parche). Por ejemplo, digamos que tienes este archivo, my_file.py:

Luego modificas este archivo - al cambiar el texto dentro de function_1, y también agregando una nueva función, function_5:

Si usaste git add my_file.py a este punto, pondrías en el área de preparación ambos de estos cambios juntos. En caso de que quieras separarlos en confirmaciones distintas, podrías usar git add -p, el cual separa estos dos cambios y te pregunta sobre cada uno como un pedazo independiente:

Al tipear ?, puedes ver qué significan cada opción distinta:

En este caso, digamos que solamente queremos poner en el área de preparación el cambio introduciendo function_5. No queremos poner en el área de preparación el cambio de function_1, así que seleccionamos n:

Luego, nos aparece una ventana para el segundo cambio - el que introduce function_5. Queremos poner en el área de preparación este pedazo, así podemos tipear y.

Resumen

Bueno, ¡esto fue divertido!

¿Puedes creer cuánto has aprendido?

En la Parte 1 aprendiste sobre blobs, árboles y confirmaciones.

Luego aprendiste sobre las ramas, viendo que no son mas que una referencia nombrada a una confirmación.

Aprendiste el proceso de registrar cambios en Git, y que involucra el directorio de trabajo, el área de preparación (índice), y el repositorio.

Luego - creaste un nuevo repositorio desde cero, al usar echo y comandos de bajo nivel tales como git hash-object. Creaste un blob, un árbol, y un objeto de confirmación apuntando a ese árbol.

En la Parte 2 aprendiste sobre hacer ramas e integrar cambios en Git.

Aprendiste lo que es un diff, y la diferencia entre un diff y un parche. También aprendiste cómo se construye la salida de git diff.

Luego, tuviste un vistazo extensivo sobre fusionar con Git, específicamente entendiendo el algoritmo de fusión de tres vías. Entendiste cuándo los conflictos de fusión ocurren, cuándo Git los puede resolver automáticamente, y cómo los resuelve de forma manual cuando sea necesario.

Viste que git rebase es poderoso - pero también es bastante sencillo una vez que entiendes lo que hace. Entendiste las diferencias entre fusionar y hacer rebase, y cuando deberías usar cada uno.

En la Parte 3 aprendiste cómo deshacer cambios en Git - especialmente cuando las cosas van mal. Aprendiste cómo usar un par de herramientas, como git reset, git commit --ammend, git revert, git reflog (y git log -g).

La herramienta más importante, aún más importante que las herramientas que listé, es limpiar la situación actual vs el que se desea. Créeme en esta, hará que cada situación parezca menos intimidante y la solución más claro.

En la Parte 4 adquiriste herramientas poderosas adicionales, como diferentes conmutadores de git log, git bisect, git cherry-pick, git revert y git add -p.

Wow, ¡deberías sentirte orgulloso!

Un mensaje de mí para tí

En efecto, eso fue divertido, pero todas las cosas deben pasar. Terminaste de leer este libro, pero no significa que tu jornada de aprendizaje termina aquí.

Lo que has adquirido, más que cualquier herramienta específica, es intuición y entendimiento de cómo opera Git, y cómo pensar sobre varias operaciones en Git. Sigue investigando, leyendo, y usando Git. Estoy seguro que serás capaz de enseñarme algo nuevo, y por todos los medios - hazlo por favor.

Si te gustó este libro, por favor compártelo con más personas.

Si quieres leer más de mis artículos de Git y manuales, aquí están:

1. The Git Rebase Handbook
2. The Git Merge Handbook
3. The Git Diff and Patch Handbook
4. Git Internals - Objects, Branches, and How to Create a Repo
5. Git Reset Command Explained

Reconocimientos

Mucha gente ayudó en hacer este libro lo mejor que se podía. Entre ellos, fui afortunado de tener muchos lectores beta que me dieron comentarios así podía mejorar el libro. Específicamente, me gustaría agradecer a Jason S. Shapiro, Anna Łapińska, C. Bruce Hilbert, y Jonathon McKitrick por sus revisiones exhaustivas.

Abbey Rennemeyer ha sido una editor maravillosa. Después que ha revisado mis publicaciones para freeCodeCamp por tres años, fue claro que le pidiera que fuera el editor de este libro también. Ella me ayudó en mejorar el libro de muchas formas, y estoy agradecido por su ayuda.

Quincy Larson fundó la maravillosa comunidad en freeCodeCamp, me motivó por medio de emails y discusiones de cara a cara. Le agradezco por generar esta increíble comunidad, y por su amistad.

Estefania Cassingena Navone diseñó la portada de este libro. Estoy agradecido por su trabajo profesional y su paciencia con mis pedidos y perfeccionismo.

El sitio web de Daphne Gray-Grant, "Publication Coach", me dio inspiración así también como consejos técnicos que me ayudó mucho con mi proceso de escritura.

Si deseas apoyar este libro

Si te gustaría apoyar este libro, puedes comprar la versión en papel, un versión E-Book (libro electrónico), o comprarme un café. ¡Gracias!

Contáctame

Este libro ha sido creado para ayudarte y gente como tú aprenda, entienda Git, y aplique sus conocimientos en la vida real.

Bien al principio, pedí comentarios y fui afortunado de recibirlo de gente estupenda (mencionado en los Reconocimientos) para asegurar que el libro alcanzara estos objetivos. Si te gustó algo de este libro, sentiste que algo estaba faltando o necesitaba mejorar - me encantaría que me lo dijeras. Por favor háblame en: gitting.things@gmail.com.

Gracias por aprender y permitirme ser parte de tu jornada.

- Omer Rosenbaum

Apéndices

Referencias Adicionales - Por Parte

(Nota - esta es una lista corta. Puedes encontrar una lista más larga de referencias en la versión E-Book o la impresa.)

Parte 1

• Lista de reproducción de Youtube sobre los Componentes Internos de Git - por Brief:
  https://www.youtube.com/playlist?list=PL9lx0DXCC4BNUby5H58y6s2TQVLadV8v7
• Conferencia de Tim Berglund - "Git From the Bits Up":
  https://www.youtube.com/watch?v=MYP56QJpDr4
• como prometí, la documentación: Git for the confused:
  https://www.gelato.unsw.edu.au/archives/git/0512/13748.html

Parte 2

Diffs y Parches

Algoritmos de Diffs de Git:

• https://es.wikipedia.org/wiki/Diff

El algoritmo de diff más predeterminado en Git es Myers:

• https://www.nathaniel.ai/myers-diff/
• https://blog.jcoglan.com/2017/02/12/the-myers-diff-algorithm-part-1/
• https://blog.robertelder.org/diff-algorithm/

Git Merge

• https://git-scm.com/book/es/v2/Herramientas-de-Git-Fusión-Avanzada
• https://blog.plasticscm.com/2010/11/live-to-merge-merge-to-live.html

Git Rebase

• https://jwiegley.github.io/git-from-the-bottom-up/1-Repository/7-branching-and-the-power-of-rebase.html
• https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Reorganizar-el-Trabajo-Realizado

Recursos relacionados a los Beatles

• https://www.the-paulmccartney-project.com/song/ive-got-a-feeling/
• https://www.cheatsheet.com/entertainment/did-john-lennon-or-paul-mccartney-write-the-classic-a-day-in-the-life.html/
• http://lifeofthebeatles.blogspot.com/2009/06/ive-got-feeling-lyrics.html

Part 3

• https://git-scm.com/book/es/v2/Herramientas-de-Git-Reiniciar-Desmitificado
• https://www.edureka.co/blog/common-git-mistakes/

Cuando colaboras con otros desarrolladores utilizando Git, es posible que te encuentres con el error: failed to push some refs to [remote repo].

Este error ocurre principalmente cuando intentas enviar tus cambios locales a GitHub, mientras que el repositorio local aún no ha sido actualizado con los cambios realizados en el repositorio remoto.

Entonces, Git está tratando de decirte que actualices el repositorio local con los cambios actuales en el remoto antes de enviar tus propios cambios. Esto es necesario para que no sobrescribas los cambios hechos por otros.

Discutiremos dos posibles formas de solucionar este error en las secciones que siguen.

¿Cómo solucionar el error: failed to push some refs to en Git?

Podemos solucionar el error: failed to push some refs to [remote repo] en Git usando los comandos git pull origin [branch] o git pull --rebase origin [branch]. En la mayoría de los casos, el último comando soluciona el error.

Veamos cómo puedes usar los comandos mencionados anteriormente.

¿Cómo solucionar el error: failed to push some refs to en Git usando git pull?

Enviar una solicitud de extracción (pull request) significa "buscar" nuevos cambios realizados en el repositorio remoto y fusionarlos con el repositorio local.

Una vez que se haya completado la fusión, puedes enviar tus propios cambios de código a GitHub.

En nuestro caso, estamos tratando de deshacernos del error: failed to push some refs to [remote repo] enviando una solicitud de extracción.

Así es como puedes hacerlo:

git pull origin main

Si estás trabajando con una rama diferente, entonces tendrías que reemplazar main en el ejemplo anterior con el nombre de tu rama.

Solo ten en cuenta que existen posibilidades de fallo al usar este comando para sincronizar tus repositorios remotos y locales y así deshacerte del error. Si la solicitud tiene éxito, entonces continúa y ejecuta el siguiente comando para enviar tus propios cambios:

git push -u origin main

Si el error persiste, obtendrás un error que dirá: fatal: refusing to merge unrelated histories. En este caso, utiliza la solución disponible en la siguiente sección.

¿Cómo arreglar el error:failed to push some refs to en Git usando git pull --rebase?

El comando git pull --rebase  es útil en situaciones donde tu rama local es un commit por detrás de la rama remota

Para arreglar el error, emplea los siguientes comandos:

git pull --rebase origin main

git push -u origin main 

Si el primer comando anterior se ejecuta con éxito, deberías recibir una respuesta que diga: Successfully rebased and updated refs/heads/main.

El segundo comando envía el estado actual de tu repositorio local a la rama remota.

Resumen

En este artículo, discutimos el error error: failed to push some refs to [remote repo].

Este error ocurre cuando intentas enviar tus cambios locales al repositorio remoto sin antes actualizar tu repositorio local con los cambios más recientes del repositorio remoto.

Exploramos dos comandos para abordar este error: los comandos git pull origin [branch] y git pull --rebase origin [branch].

Espero que esta información te ayude a resolver el error.

¡Feliz programación!

Nota del traductor: Este post contiene muchos videos que sirven para complementar la información del mismo, los videos están en inglés pero es posible verlos con los subtítulos autogenerados que proporciona YouTube.

Trabajar con Git y GitHub suele ser una parte esencial de sus tareas diarias de programación. En muchos casos, necesitarás tanto un repositorio Git local como un repositorio GitHub remoto para un proyecto.

• Con el repositorio local, trabajas en tu propia copia del proyecto. Usted realiza y prueba los cambios de forma independiente antes de enviarlos al repositorio remoto para que otros los revisen y combinen.
• El repositorio remoto se usa para almacenamiento externo y para compartir el proyecto con otros.

Este tutorial se divide en 2 escenarios:

• Local primero: primero crea un repositorio local y envía su código a ese repositorio. Más adelante, creará un repositorio remoto. Con los dos repositorios instalados, querrás mantenerlos sincronizados. Este escenario es común si ha iniciado un proyecto por su cuenta y luego desea compartirlo.
• Remoto primero: en este escenario, existe un repositorio remoto y desea trabajar con ese código. Utilice ese repositorio remoto para crear su repositorio local para poder realizar y probar cambios localmente. Con los dos repositorios instalados, querrás mantenerlos sincronizados. Este escenario es común si está trabajando en un equipo o en un proyecto de código abierto que tiene un repositorio de GitHub existente.

Esto es lo que trataremos en este tutorial:

1. ¿Qué significan Git, GitHub y Repositorio?
2. ¿Cómo instalar Git y GitHub?
3. Escenario 1: Primero local
4. ¿Cómo crear un repositorio local?
5. ¿Cómo confirmar archivos en el repositorio local?
6. ¿Cómo crear un repositorio remoto de GitHub?
7. ¿Cómo conectar Git y Github?
8. ¿Cómo sincronizar los repositorios local y remoto?
9. Escenario 2: Primero remoto
10. ¿Cómo clonar un repositorio?
11. Terminando

Comencemos con una breve introducción a los términos que estamos usando y luego pasemos a nuestros dos escenarios.

¿Qué significan Git, GitHub y repositorio?

Un repositorio, o "repo" para abreviar, almacena y rastrea las versiones de los archivos de su proyecto. A medida que realiza cambios en esos archivos, confirma (o copia) esos archivos en el repositorio para su custodia. El repositorio mantiene una lista de todos los cambios confirmados, denominada historial de confirmaciones o commit history en inglés.

Git es un sistema de control de versiones popular y ampliamente utilizado para crear y trabajar con repositorios. Se ejecuta localmente en su computadora. Puedes descargar, instalar y usar Git en cualquier plataforma sin ningún costo ni tarifa. Con Git, creas un repositorio local en la carpeta de trabajo de tu proyecto y Git almacena el historial de confirmación de los archivos en esa carpeta.

Si eres nuevo en Git, considera ver este vídeo como introducción:

GitHub es un sitio web que aloja repositorios remotos en Internet. Una cuenta básica de GitHub también es gratuita. Utilice GitHub para crear un repositorio remoto para su proyecto. Con un repositorio remoto, puede almacenar su código fuera del sitio, colaborar con otros, trabajar en proyectos de la empresa o de código abierto y mostrar su portafolio a posibles empleadores.

Si eres nuevo en GitHub, considera ver este vídeo como introducción:

Antes de saltar a nuestros escenarios, necesitamos instalar Git y crear una cuenta de GitHub.

¿Cómo instalar Git y GitHub?

Si desea trabajar con los ejemplos presentados en este tutorial, existen algunos pasos preparatorios. Pero no dudes en pasar a la siguiente sección si ya tienes estas herramientas instaladas o prefieres leer este artículo sin codificar.

Primero, instala Git en tu computadora si aún no lo tienes. Para obtener instrucciones paso a paso sobre cómo instalar Git, vea la segunda parte de este video:

A continuación, cree una cuenta de GitHub, si aún no tiene una. Este video proporciona instrucciones paso a paso sobre cómo crear una cuenta de GitHub:

Por último, cree una carpeta de trabajo en su computadora (yo nombré mis recetas en mi carpeta de documentos). Luego cree dos archivos de texto simples en esa carpeta: archivo1.txt y archivo2.txt. Aunque estemos usando archivos de texto, el proceso de sincronización cubierto en este artículo es el mismo con cualquier tipo de archivos de código.

Ahora estamos listos para analizar nuestros dos escenarios: primero el local y primero el remoto.

Escenario 1: Primero local

Supongamos que desea crear un sitio web de recetas (o tal vez una aplicación) para recopilar y administrar recetas. Crea un repositorio local para poder rastrear fácilmente sus cambios en los archivos del proyecto.

Más tarde decide que también desea un repositorio remoto para mantener una copia de sus archivos fuera del sitio y compartir el proyecto con otros. Una vez que tenga el repositorio remoto, querrá mantener su repositorio local sincronizado con ese repositorio remoto.

Este escenario se muestra en la Figura 1:

Según los números de la Figura 1:

1. Primero se crea el repositorio local, representado como un cuadro.
2. El repositorio remoto se crea con GitHub algún tiempo después.
3. Los dos repositorios se mantienen sincronizados.

Repasemos estos pasos en detalle.

¿Cómo crear un repositorio local?

Ya preparamos una carpeta de trabajo y creamos dos archivos que son el comienzo de nuestro proyecto.

Para crear un repositorio local para ese proyecto, abra su terminal o símbolo del sistema y navegue hasta esa carpeta de trabajo.

Luego inicializa un nuevo repositorio Git usando el siguiente comando:

git init

Este comando inicializa un nuevo repositorio Git en la carpeta actual. El proceso de inicialización crea una carpeta .git dentro de la carpeta del proyecto que almacena los archivos y datos del repositorio.

Esta carpeta .git puede estar oculta de forma predeterminada. En el Finder de Mac, use Command + Mayús +. (punto) para que aparezcan carpetas y archivos ocultos. En Windows, use la pestaña Ver del Explorador de archivos y marque Elementos Ocultos para mostrar carpetas y archivos ocultos.

¡Ahora tenemos un repositorio local! Agreguemos nuestros dos archivos de proyecto en ese repositorio.

¿Cómo confirmar archivos en el repositorio local?

Cada vez que creamos archivos nuevos, cambiamos archivos existentes o eliminamos archivos, enviamos esos cambios a nuestro repositorio local. Esto asegura que el repositorio rastree el estado actual de nuestro proyecto.

Enviar archivos a un repositorio local requiere dos pasos:

1. Stage (Área de preparación)
2. Commit (Confirmación)

Primero, agregue los archivos al área de preparación de Git:

git add .

Le decimos a Git qué archivos queremos incluir en esa confirmación agregándolos a un área de preparación. La puesta en escena nos permite elegir selectivamente qué cambios incluir en una confirmación.

Utilizando el . (punto) agrega todos los archivos en la carpeta de trabajo (y sus subcarpetas) al área de preparación. Si solo desea agregar archivos específicos, puede enumerarlos.

A continuación, confirmamos los archivos preparados en el repositorio local:

git commit -m "Confirmación inicial"

Este comando envía los archivos en el área de preparación de Git al repositorio local.

La opción -m es para un mensaje de confirmación. Siga la -m con el mensaje, entre comillas. Asegúrese de definir un mensaje claro que describa los cambios que está realizando.

Para obtener más información sobre cómo definir excelentes mensajes de confirmación, vea este video:

Después de estos pasos, el terminal aparece como se muestra a continuación:

El comando init muestra un mensaje de estado que nos indica que creó un repositorio Git vacío.

El comando add no proporciona ningún resultado.

El comando commit muestra la rama en la que estamos ( main en este ejemplo), los primeros caracteres de la identificación de la confirmación y el mensaje de confirmación. Luego enumera los archivos modificados. En este ejemplo, se cambiaron 2 archivos y ambos fueron inserciones (archivos nuevos).

El número después del modo de creación indica el tipo de archivo y los permisos. 100644 significa que se trata de archivos normales, no carpetas, con permisos de lectura y escritura del propietario.

Con nuestro repositorio local implementado, es hora de crear nuestro repositorio remoto.

¿Cómo crear un repositorio remoto en GitHub?

Ahora crearemos un repositorio remoto en GitHub. Vaya al sitio web de GitHub en www.github.com e inicie sesión. Si no tiene una cuenta de GitHub, consulte la sección "Cómo instalar Git y GitHub" anteriormente en este tutorial para conocer los pasos para crear una cuenta.

Mire este video para ver el proceso de creación de un repositorio de GitHub:

Después de iniciar sesión en GitHub, se le dirigirá a su panel personal. Su panel personal de GitHub proporciona información sobre sus repositorios y proyectos.

Si es la primera vez que creas un repositorio en GitHub, proporciona el botón Crear Repositorio para ayudarte a comenzar. Si ya ha estado usando GitHub, verá un botón Nuevo en su lugar.

En cualquier caso, al hacer clic en el botón se accede a la página Crear un nuevo repositorio, como se muestra en la Figura 3.

Comience ingresando el nombre del repositorio. El nombre de un repositorio debe ser breve, pero descriptivo de su proyecto. Debe ser único dentro de su cuenta de GitHub. GitHub lo comprueba por ti.

Las convenciones generales para los nombres de los repositorios sugieren el uso de minúsculas. Si hay varias palabras, utilice guiones entre las palabras, como libro- de-recetas.

Llamé a mi repositorio de recetas. Y la flecha verde al lado del nombre significa que es único dentro de esta cuenta de GitHub.

Opcionalmente, puede proporcionar una descripción. Aquí es donde puedes poner más información sobre el repositorio, si lo deseas.

A continuación, tienes la opción de crear un repositorio público o privado. Si crea un repositorio público, cualquiera en Internet puede verlo. Pero sólo los colaboradores que tú elijas pueden comprometerse con ello. Así que no tienes que preocuparte de que extraños cambien tus archivos. Si crea un repositorio privado, será privado excepto para los colaboradores elegidos.

Considere hacer públicos sus repositorios para compartir su código con otros, a menos que su código sea propietario.

Luego tiene la opción de crear un archivo Readme (Léame). Un archivo Readme les da a quienes miran un repositorio una idea de para qué sirve ese repositorio e instrucciones sobre cómo usarlo. Marque la casilla para agregar un archivo Readme.

Una plantilla .gitignore le ayuda a identificar qué archivos de su carpeta de trabajo no desea incluir en el seguimiento de versiones de Git. Para una aplicación, no desea incluir archivos de compilación intermedios, por ejemplo, ya que suelen ser grandes y pueden reconstruirse fácilmente a partir de archivos fuente. Para este proyecto simple, no necesitamos una plantilla .gitignore.

Lo siguiente es elegir una licencia. Una licencia permite a otros desarrolladores saber qué pueden hacer con el código de su repositorio. Por ejemplo, si podrían utilizar libremente el código para sus propios proyectos.

GitHub proporciona un sitio web para ayudarle a tomar una decisión. Haga clic en obtener más información en la opción Elegir una licencia para ir a la documentación de GitHub. En la página de documentación, encontrará un enlace de choosealicense.com para obtener ayuda para seleccionar qué licencia es adecuada para su proyecto.

Para mi repositorio de recetas, haré que la licencia sea simple y permisiva y elegiré una licencia MIT.

Cierre la pestaña del navegador de documentación, regrese a la pestaña GitHub y seleccione la licencia deseada de la lista.

Justo encima del botón Crear Repositorio, GitHub proporciona un resumen para que puedas verificar la acción que estás a punto de realizar. Luego haga clic en Crear Repositorio.

Crea el repositorio como se muestra en la Figura 4.

Como puede ver en la Figura 4, ¡GitHub realizó automáticamente nuestra primera confirmación! Esa confirmación es una instantánea de los dos archivos que le dijimos que agregara al repositorio: nuestro archivo de licencia y el archivo Léame. Estableció un mensaje de confirmación de "compromiso inicial". Y de forma predeterminada, GitHub muestra el contenido de nuestro archivo Léame.

En este punto, nuestro repositorio local contiene nuestros dos archivos de texto. Y nuestro repositorio remoto contiene nuestra licencia y archivos Léame. Queremos que los dos repositorios coincidan.

¿Cómo conectar Git y Github?

Antes de poder sincronizar los repositorios local y remoto, debe establecer una conexión entre ellos. Básicamente, necesita indicarle a su repositorio local dónde encontrar el repositorio remoto.

Identificamos un repositorio remoto por su URL. En la Figura 4 anterior, observe el botón verde Código. Haga clic en ese botón para ver detalles sobre el repositorio (Figura 5).

Asegúrese de que la pestaña HTTPS esté seleccionada y haga clic en el icono de copiar para copiar la URL de este repositorio de GitHub.

De vuelta en la ventana de comandos de su máquina local, agregue el repositorio remoto al repositorio local. Luego enumere los controles remotos para confirmar que se creó el control remoto.

git remote add recipes-gh https://github.com/DeborahK/recipes.git
git remote

El comando remote add agrega el repositorio remoto en la URL proporcionada. Y le permite asignar un alias para ese repositorio para que no tenga que escribir la URL cuando haga referencia al repositorio remoto.

Un alias común para el repositorio remoto es origin, pero algunos encuentran ese nombre un poco confuso, especialmente si el repositorio remoto no fue el origen del proyecto. En ese caso, a veces uso el nombre del repositorio local con -gh (para GitHub) como apodo del repositorio remoto, para poder recordarlo fácilmente. Pero siéntete libre de usar cualquier nombre.

El comando remote por sí solo muestra la lista de controles remotos que conoce su repositorio local. Así es como se ve:

Nuestro repositorio Git local ahora sabe dónde encontrar su repositorio remoto asociado. El siguiente paso es sincronizar los repositorios para que coincida su historial de confirmaciones.

¿Cómo sincronizar un Repositorio Local con un Repositorio Remoto?

Para sincronizar nuestros repositorios local y remoto, primero recuperamos el historial de cambios del repositorio remoto y lo fusionamos en nuestro repositorio local usando el comando pull. Luego enviamos nuestro historial de cambios local al repositorio remoto usando el comando push.

Si prefieres sincronizar repositorios usando VS Code, mira este video:

Para extraer del repositorio remoto y fusionarlo con nuestro repositorio local usando un comando de Git:

git pull recetas-gh main --allow-unrelated-histories

dir		// En Windows
o
ls		// En Mac

El comando pull requiere el alias del repositorio remoto (recetas-gh) y el nombre de la rama. Como no hemos creado ninguna rama adicional, especificamos la rama principal ( main ).

La bandera --allow-un related-histories es necesaria la primera vez que extraemos porque queremos fusionar dos repositorios que se crearon por separado y actualmente no comparten un historial relacionado.

Después de la primera vez, el comando git pull no requiere esa bandera:

git pull recetas-gh main

En cualquier caso, el comando pull busca la URL apropiada para el repositorio remoto usando el apodo proporcionado ( recetas-gh ).

Luego recupera el historial de confirmaciones y otros datos de la rama especificada ( main ) del repositorio remoto que no está en esa rama del repositorio local.

Fusiona esos datos en el repositorio local. Si hay algún conflicto, deberá resolverlo manualmente antes de que Git combine los cambios.

Por último, actualiza la carpeta de trabajo local con todos los archivos de la confirmación más reciente.

Usando el comando dir en Windows, o el comando ls en una Mac, vemos que nuestro repositorio local ahora tiene nuestros archivos originales más los archivos de licencia y Léame de nuestro repositorio remoto, como se muestra en la Figura 7.

Ahora nuestro repositorio local contiene todo el historial de confirmaciones del repositorio remoto.

A continuación, enviamos el historial de cambios desde nuestro repositorio local a nuestro repositorio remoto usando el comando push.

git push recetas-gh main

El comando push requiere el nombre del repositorio remoto ( recetas-gh ) y el nombre de la rama. Como no hemos creado ninguna rama adicional, especificamos la rama principal ( main ).

Este comando fusiona el historial de cambios local con el repositorio remoto. Si hay algún conflicto, deberá resolverlo manualmente antes de que Git combine los cambios. Consulte la Figura 8 para ver el resultado:

Para confirmar que nuestro repositorio remoto incluye todos nuestros archivos, vea el repositorio remoto en GitHub. En la Figura 9, vemos que los archivos de nuestro repositorio local ahora están en nuestro repositorio remoto y ¡nuestros repositorios están sincronizados!

En resumen, sincronizar sus repositorios local y remoto implica extraer cualquier cambio del repositorio remoto a su repositorio local, resolver conflictos y luego enviar sus cambios locales nuevamente al repositorio remoto.

Eso es todo para el primer escenario. Creamos un repositorio local a partir de nuestros archivos existentes. Luego creamos un repositorio remoto, configuramos una conexión a ese repositorio remoto y sincronizamos nuestros archivos. Repita los comandos pull y push para sincronizar los repositorios mientras trabaja en su proyecto.

Escenario 2: Primero remoto

Para nuestro segundo escenario, el repositorio remoto ya existe. Este será el caso si te unes a un equipo que tiene código existente en GitHub. O si quieres trabajar en un proyecto de código abierto. O si encontró algún código en GitHub que le gustaría usar como punto de partida para su proyecto.

Quiere crear su repositorio local a partir de un repositorio remoto existente. Hay tres formas básicas de obtener código de un repositorio remoto, como se muestra en la Figura 10.

En el lado izquierdo de la Figura 10, tenemos un escenario: si posee o tiene derechos de acceso para modificar el repositorio remoto, puede clonar el repositorio remoto para crear su repositorio local. Luego puede sincronizar directamente los cambios entre los dos repositorios.

El segundo escenario se muestra en el medio de la Figura 10: si no es propietario del repositorio remoto o no tiene derechos de acceso para modificarlo, primero use GitHub para bifurcar el repositorio. Esto crea una copia del repositorio remoto en su cuenta de GitHub. Luego clona tu copia para crear tu repositorio local.

Este será el caso si estás trabajando en un proyecto de código abierto o quieres usar el código en el repositorio de otra persona como punto de partida para tu proyecto.

El tercer escenario se muestra a la derecha de la Figura 10; también existe la opción de descargar un archivo zip del código en el repositorio. Esto no crea un repositorio local. Utilice esta opción si desea ver el código de un repositorio de GitHub, pero no planea realizar un seguimiento de los cambios.

Para configurar el ejemplo de este escenario, necesita un repositorio remoto que actualmente no tenga un repositorio local asociado. Puede utilizar el repositorio remoto de recetas que ya creó en el primer escenario. Si prefieres utilizar el repositorio de otra persona para este ejemplo, asegúrate de bifurcarlo primero.

Una vez que tenga un repositorio remoto, asegúrese de que no haya ningún repositorio local asociado a él. Si está utilizando el repositorio remoto de recetas, elimine la carpeta de recetas de su sistema local. Eso elimina su repositorio local.

Ahora está listo para crear un nuevo repositorio local desde su repositorio remoto en GitHub.

¿Cómo clonar un repositorio?

Para crear un repositorio local desde un repositorio remoto en GitHub, use el comando clone.

Si prefieres clonar un repositorio usando la aplicación GitHub Desktop, mira este video:

Para clonar usando un comando de Git, primero necesitamos la URL del repositorio remoto.

Navegue a GitHub, inicie sesión y verá su panel personal. Localice el repositorio que desea clonar. Haga clic en el botón verde Código para ver los detalles sobre el repositorio como se muestra anteriormente en la Figura 5. Haga clic en el botón copiar al lado de la URL para copiarlo.

A continuación, abra su terminal o símbolo del sistema en su computadora. Navegue hasta la carpeta donde desea crear la carpeta de trabajo del proyecto. Navegaré a mi carpeta de documentos.

Entonces estamos listos para clonar ese repositorio:

git clone https://github.com/DeborahK/recetas.git

El comando clone requiere la URL del repositorio remoto. Acabamos de copiar esa URL de GitHub, así que péguela como parte de este comando.

Cuando se ejecuta el comando, primero crea la carpeta de trabajo para el repositorio utilizando el nombre del repositorio remoto de la URL, que son recetas en este ejemplo. Luego copia el historial de confirmaciones del repositorio remoto en la URL proporcionada.

El proceso de clonación también vincula automáticamente el nuevo repositorio local con su repositorio remoto. Y asigna al repositorio remoto un alias de origen. Luego podemos hacer referencia al repositorio remoto usando ese alias en lugar de su URL.

Por último, el proceso de clonación copia todos los archivos de la confirmación más reciente a la carpeta de trabajo local. Luego puede agregar, editar o eliminar archivos en esa carpeta de trabajo mientras trabaja localmente en el proyecto.

Navegue hacia abajo hasta la carpeta de nuevas recetas. Luego use el comando remoto para ver el repositorio remoto vinculado. Y como se muestra en la Figura 11, efectivamente tiene el alias origen.

Observe el resultado de la operación de clonación en la Figura 11. Git enumera (o encuentra) 10 objetos. Sólo tenemos cuatro archivos en el repositorio remoto de recetas. Entonces, ¿por qué encuentra 10 objetos? Esto se debe a que el proceso de clonación copia todo el historial de confirmaciones, no solo los archivos.

Utilice el comando rev-list con las banderas --objects y --all para ver la lista de objetos.

git rev-list --objects --all

La Figura 12 muestra el resultado de ese comando:

Cada uno de los objetos anteriores se muestra como un identificador SHA o algoritmo hash seguro. El SHA se utiliza como identificación para identificar de forma única los objetos en nuestro repositorio.

Los primeros tres objetos de esta lista (objetos 1 a 3) son las tres confirmaciones realizadas en este repositorio. Al observar la lista de confirmaciones en GitHub (Figura 13), cada confirmación muestra los primeros caracteres de su SHA. Estos coinciden con los primeros tres objetos:

• La fusión se confirma cuando fusionamos los dos repositorios.
• El commit inicial que GitHub realizó en el repositorio remoto creando los archivos LICENCIA y README.md.
• El commit inicial que realizamos en el repositorio local confirmando file1.txt y file2.txt.

Los objetos del medio en la lista que se muestra en la Figura 12 (objetos 5-8) son los cuatro archivos comprometidos.

Los tres objetos restantes (objetos 4, 9, 10) son objetos de árbol. Un objeto de árbol representa el estado de una carpeta, incluidos los archivos y subcarpetas de esa carpeta. Mantiene la jerarquía de la carpeta.

Usando el comando dir en Windows o el comando ls en Mac, vemos que nuestra carpeta de trabajo ahora contiene todos los archivos de nuestro repositorio remoto.

Ahora que hemos clonado el repositorio, nuestros repositorios local y remoto coinciden. Para mantenerlos sincronizados, utilizamos pull y push como vimos en la sección "Cómo sincronizar repositorios locales y remotos" anteriormente en este artículo.

Tenga en cuenta que si está trabajando con un repositorio remoto que no es de su propiedad, es posible que no tenga acceso para enviar sus cambios directamente al repositorio. En su lugar, deberás emitir un Pull Request.

Un Pull Request, o PR, les dice a los propietarios u otros contribuyentes que usted ha enviado cambios y que está solicitando que esos cambios se revisen y extraigan, o se fusionen, en el repositorio remoto.

Vea este vídeo para obtener más información sobre los Pull Request:

Terminando

En el primer escenario, teníamos código existente y creamos un repositorio local a partir de ese código. Luego creamos un repositorio remoto para mantener una copia de los archivos fuera del sitio y compartir el proyecto con otros.

En el segundo escenario, teníamos un repositorio remoto existente creado en GitHub por nuestro equipo o por un colaborador de código abierto. Luego clonamos ese repositorio para crear nuestro repositorio local. De esa manera, podemos trabajar en nuestra propia copia del proyecto y realizar y probar cambios de forma independiente antes de enviar esos cambios al repositorio remoto para que otros los revisen y fusionen.

Ya sea que cree primero su repositorio local o primero su repositorio remoto de GitHub, una vez que tenga ambos repositorios en su lugar, puede mantenerlos sincronizados con los comandos pull y push de Git. O enviando solicitudes de extracción o relaciones públicas.

Para obtener más detalles sobre cómo aprender Git y GitHub, consulte este curso:

Obtener una comprensión sólida de los repositorios locales y remotos, y cómo mantenerlos sincronizados, es esencial cuando se trabaja en su propio código. Es aún más importante cuando se trabaja en un equipo o en un proyecto de código abierto.

Git es un sistema de control de versiones gratuito y de código abierto. Es el sistema de control de versiones más popular en uso hoy en día.

Git realiza un seguimiento de los cambios realizados en un proyecto a lo largo del tiempo. Esto permite a múltiples desarrolladores colaborar y trabajar en el mismo proyecto en paralelo, sin importar dónde se encuentren en el mundo.

Permite a los desarrolladores ver el historial del proyecto y ver quién realizó qué cambios y por qué se realizaron esos cambios en primer lugar. Además, con Git, puedes revertir a una versión anterior del código si es necesario.

Básicamente, Git garantiza a los desarrolladores que están todos en la misma página y sepan qué está sucediendo en el proyecto.

Cuando trabajas en un proyecto, uno de los desafíos que puedes enfrentar es tratar de sincronizar tu trabajo, específicamente, sincronizar las ramas locales y remotas.

En este artículo, aprenderás cómo restablecer y hacer coincidir exactamente una rama Git local con una rama remota.

Esto es lo que cubriremos:

• ¿Qué es una rama en Git?
• ¿Cuál es la diferencia entre las ramas locales, remotas y las ramas de seguimiento remoto?
• ¿Cómo restablecer una rama local de Git a la remota?
• Guardar el estado actual de tu rama local
• Hacer un git checkout
• Hacer fetch de origen
• Restablecer el repositorio local
• Limpiar cualquier cambio no rastreado
• Conclusión

¿Qué es una rama en Git? Ramas de Git en pocas palabras para principiantes

La ramificación es un aspecto fundamental del control de versiones y un concepto importante de aprender.

Gracias a la ramificación, los desarrolladores pueden colaborar de una manera más flexible. La ramificación hace que el proceso de desarrollo diario sea más fluido y eficiente.

La ramificación es una forma de gestionar diferentes versiones de tu código y actúa como un puntero a una instantánea de tus cambios.

Cuando creas por primera vez un repositorio Git para tu proyecto, en ese mismo momento se crea también la rama principal.

La rama principal es la rama primaria y predeterminada de tu proyecto. Representa la versión libre de errores, estable y utilizable de tu código que está lista para ser lanzada y compartida con el público. Es la base de código principal.

Pero, ¿qué sucede cuando quieres añadir una nueva característica a tu proyecto?

Antes de añadirla, necesitas probarla y asegurarte de que no introduce nuevos errores o interfiere con el código existente.

Debe haber una forma de trabajar en la nueva característica sin afectar la base de código.

Y aquí es donde la ramificación resulta útil.

Las ramas son espacios aislados para experimentar y probar código nuevo sin afectar al código en la rama principal.

Puedes crear una nueva rama y hacer los cambios que desees. Si estás satisfecho con los cambios, puedes añadirlos a la rama principal fusionándolos. Si no lo estás, puedes eliminar esa rama sin interferir con el código principal en el proyecto.

Las ramas también permiten a los desarrolladores trabajar en diferentes características al mismo tiempo sin interferir en el trabajo de los demás.

Para obtener más información sobre las ramas en Git, echa un vistazo a este vídeo que explica cómo funcionan, y marca este artículo que proporciona una hoja de trucos sobre cómo usarlas.

Ramas locales VS remotas VS ramas de seguimiento remoto en Git - ¿Cuál es la diferencia?

Una rama local es una rama que solo es accesible en tu máquina local y existe allí de manera aislada. Desde aquí, puedes agregar archivos y hacer confirmaciones de cualquier cambio que realices. Esos cambios se guardarán localmente y solo serán visibles para ti y estarán disponibles en tu máquina física local.

Los otros desarrolladores no podrán ver tu trabajo ni los cambios que hayas hecho.

Puedes crear una rama local llamada my_branch usando el siguiente comando:

git branch my_branch

Y para luego listar todas tus ramas locales, solo necesitas usar el comando git branch.

Para colaborar con otros desarrolladores en el mismo proyecto y para que ellos puedan ver cualquier cambio que realices, necesitas enviar los cambios desde tu rama local a un repositorio remoto. Esto nos lleva a las ramas remotas.

Una rama remota se refiere a una rama que existe en un repositorio remoto. Un repositorio remoto, también conocido como remoto, típicamente será un repositorio alojado en algún lugar en Internet, en una ubicación remota como en los servidores de GitHub.

El nombre predeterminado de un repositorio remoto es origin.

Ahora, una rama de seguimiento remoto se refiere a una referencia local del estado de la rama remota. Por defecto, las ramas no tienen conexión entre sí. Dicho esto, puedes indicarle a una rama local que siga a una remota.

Cómo restablecer una rama local de Git a la remota

Es posible que hayas estado trabajando en tu rama local, realizando diversos cambios y modificaciones en un proyecto, y hayas concluido que esos cambios ya no son necesarios.

Quieres eliminarlos y restablecer la rama a la rama remota.

Además, otro desarrollador puede haber realizado cambios y los haya enviado a la rama remota, por lo que necesitas obtener esos últimos cambios del repositorio remoto para estar al día.

Los pasos que necesitas seguir para lograr esto son los siguientes:

• Guardar el estado actual de tu rama local (opcional).
• Obtener la última versión del código desde el remoto.
• Restablecer la rama local.
• Limpiar archivos (opcional).

Guardar el Estado Actual de tu Rama Local

Antes de comenzar, es posible que desees guardar el estado de tu rama actual en otra rama.

Cuando restableces una rama local de Git a la remota, perderás los cambios que hayas realizado localmente.

Este paso es opcional, y puedes elegir hacerlo en caso de que algo salga mal o desees volver a ese trabajo nuevamente en el futuro.

Para guardar el trabajo utiliza los siguientes comandos:

git commit -a -m "Estoy guardando mi trabajo"
git branch backup_trabajo

Tu trabajo se guardó como backup_trabajo.

Hacer un git checkout

Por lo general, habrá una rama de seguimiento remoto local con el mismo nombre que la remota a la que deseas restablecer, como main.

Para este proceso usamos:

git checkout main

Si estás utilizando un nombre diferente para esta rama, reemplaza main con el nombre que estés utilizando.

Obtener origen

Para obtener el repositorio remoto y el estado y la versión más recientes del código en el repositorio remoto, introduce el siguiente comando:

git fetch origin

origin es un alias creado por Git y especifica la URL remota del repositorio remoto. Por lo general, Git asume automáticamente que el nombre del repositorio remoto es origin.

Si tienes un nombre remoto diferente, reemplaza origin con el nombre que estés usando.

Restablecer el repositorio local

Ahora, restablece la rama local main al repositorio remoto utilizando el siguiente comando:

git reset --hard origin/main

Limpiar cualquier cambio no rastreado

Este paso es opcional. Después de usar los comandos anteriores, es posible que te encuentres con algunos archivos no rastreados. Utiliza el siguiente comando para limpiar cualquier cambio no rastreado:

git clean -xdf

Vamos a desglosar la bandera -xdf y explicar qué hace cada parte:

1. La bandera -x elimina archivos ignorados.
2. La bandera -d elimina carpetas no rastreadas.
3. La bandera -f elimina archivos no rastreados.

Conclusión

Y ahí lo tienes: ahora has restablecido tu rama local a la remota. Esperemos que hayas encontrado útil este artículo.

Para aprender más sobre Git, echa un vistazo a los siguientes recursos gratuitos:

• Git y GitHub para Principiantes - Curso Intensivo
• Tutorial de Git para Profesionales - Herramientas y Conceptos para Dominar el Control de Versiones con Git
• Tutorial Avanzado de Git - Rebase Interactivo, Cherry-Picking, Reflog, Submódulos y más

¡Gracias por leer y feliz codificación!

Digamos que estás trabajando en una característica importante de una rama en Git – como sería renovar la sección hero de tu página de marketing. Querrás comenzar a hacer experimentos en tu rama Revamp/Marketing-page-hero-section sin arruinar la rama master o main.

Después de repente te llama tu compañero de trabajo para arreglar algunos errores en la rama login-page. Es un problema serio. Así que, intentas cambiar a la rama login-page usando git switch login-page o git checkout login-page.

Si estás cambiando ramas con cambios "staged" y "unstaged", te podrías encontrar con cualquiera de los siguientes escenarios:

Primero, mientras cambias a la rama login-page, los cambios "staged" y "unstaged" de la rama Revamp/Marketing-page-hero-section vendrán contigo a la rama login-page.

La rama Revamp/Marketing-page-hero-section contiene algunos cambios "staged" y "unstaged" en el index.html.

Si cambiamos a la rama login-page, los cambios "staged" y "unstaged" en la rama Revamp/Marketing-page-hero-section vienen al login-page también.

Esto embarra a la rama login-page.

Luego, a veces Git no te permite cambiar ramas sin confirmar esos cambios. Esto es porque podrías perder los cambios que hiciste en tu rama actual o podrían entrar en conflicto con el destino (login-page). Cualquiera sea la razón, no podemos cambiar la rama sin confirmar o almacenar los cambios.

Al mismo tiempo, no puedes confirmar la rama feature medio hecho.

Para ello, puedes usar Git stashing. Stash significa almacenar (cambios) de manera segura en un lugar oculto (la pila stash).

Almacenar los cambios o archivos sin seguimiento del directorio de trabajo actual y almacenarlos en la pila de almacenamiento, revierte el directorio de trabajo actual a la última confirmación.

Esto es bueno saberlo, ¿no? Comencemos a trabajar con los comandos stash.

Tabla de contenidos

• Cómo ocultar tus cambios 🤐
• Cómo ocultar archivos sin rastrear❗
• Cómo listar los stashs 📃
• Entendiendo el formato de stash
• Cómo mostrar el último stash 📺
• Cómo mostrar un stash individual 📺
• Cómo aplicar el stash 🖊️
• Cómo eliminar un stash ☠️
• Cómo crear una rama de un stash

Cómo ocultar tus cambios 🤐

Puedes usar cualquiera de los comandos de abajo para ocultar cambios staged y unstaged en la pila de stash. Este anula las cosas al último commit y no elimina los cambios, los cuales están almacenados en la pila stash.

git stash

o

git stash save

Cómo ocultar archivos sin rastrear❗

¿Quieres ocultar tus archivos sin rastrear en la pila de stash? Solo usa la bandera --include-untracked al final del comando.

git stash --include-untracked

o usa -u al final del comando:

git stash -u

Cómo listar los stashes 📃

Usa el comando de abajo para listar todos los stashs almacenados en la pila de stash:

git stash list

Lista los stashs de esta forma,

• Los últimos stashs (stash@{0}) estarán en la parte superior de la pila.
• Los stashs anteriores (stash@{1}) estarán en la parte inferior de la pila.

Entendiendo el formato de stash

El comando stash lista los stashs en el siguiente formato:

Si no te queda bien claro lo que está diciendo 😅, no hay problema. Exploremos algunos de los términos de la lista de stash:

• Stash@{0} – esto es sólo una referencia de stash. Se refiere al stash particular. Por defecto, Stash@{0} siempre es el último stash.

Nota: stashs con números más elevados como stash@{3} son stashs más antiguos. Los últimos stashs siempre tienen el número más bajo.

• WIP On fake – fake es sólo un nombre de una rama como cualquier otra rama y WIP significa Work In Progress (Trabajo En Progreso). "WIP on fake" significa que stash@{0} fue creado en la rama "fake".
• fc99b30 add head line – fc99b30 es una hash de Commit y add head line es un mensaje de confirmación. Al tiempo de la creación del stash, fc99b30 add head line es la última confirmación.

Tal vez tengas múltiples stashs en tu pila de stash y no eres capaz de distinguir cuál referencia de stash sostiene tales cambios.

Así que, antes de que apliques stashs en la rama de trabajo actual, puedes confirmar y mostrar los cambios registrados en el stash con el comando de abajo:

git stash show

Por defecto, git stash show muestra los cambios registrados en el último stash (stash@{0}) en el formato --stat.

El formato --stat solamente muestra cuántas líneas has agregado y eliminado en cada uno de los archivos modificados.

readme.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Si quieres mostrar los cambios registrados en el último stash en el patch view, usa la bandera -p al final del comando, así:

git stash show -p

Si también quieres mostrar archivos sin rastrear, usa la bandera -u.

git stash show -u

o puedes usar la bandera --include-untracked así:

git stash show --include-untracked

Puedes mostrar archivos sin rastrear con el formato patch:

git stash show -p -u

Puedes también mostrar solamente archivos sin rastrear con el formato patch así:

git stash show -p --only-untracked

Vaya ya has aprendido más de 10 comandos de stash 🎉🎉

Miremos algunos más así puedes aprovechar lo máximo de stash.

Cómo mostrar un stash individual 📺

Puedes mostrar los cambios registrados de un stash individual usando referencia de stash.

git stash show stash@{1}

Para el formato patch, adivinaste bien 👏🏻👏🏻 – usa la bandera -p .

git stash show stash@{1} -p

¿Quieres mostrar un stash con archivos sin rastrear? Usa este comando:

git stash show stash@{1} -u

o este:

git stash show stash@{1} --include-untracked

Donde sea que puedas hacer esto para mostrar archivos sin rastrear solamente:

git stash show stash@{1} --only-untracked

Cómo aplicar el stash 🖊️

Para aplicar los cambios registrados de tu último stash en la rama de trabajo actual, así también como quitar ese stash de la pila de stash, ejecuta este comando:

git stash pop

Nota: Podemos aplicar stashs en cualquier rama. No es específico a la rama donde el stash fue creado.

También puedes aplicar el último stash sin quitar el stash de la pila de stash así:

git stash apply

Puedes aplicar un stash anterior usando la referencia de stash:

git stash apply stash@{3}

Cómo eliminar un stash ☠️

¿Quieres limpiar todos los stashs de la pila de stash? Usa este comando:

git stash clear

¿Quieres eliminar un stash en particular? ¡Sí! Estás en lo cierto – usa la referencia de stash:

git stash drop stash@{2}

Cómo crear una rama de stash

Sí, puedes crear una nueva rama de tu último stash. Sólo usa este comando:

git stash branch <branch_name>

Por ejemplo,

git stash branch demo

Si quieres crear una rama de un stash anterior, también es posible usando la referencia de stash:

git stash branch <branch_name> stash@{revision}

Por ejemplo,

git stash branch purple stash@{3}

Concluyendo

¡Qué largo viaje! – hubo un montón por cubrir. Si no puedes recordar cada comando, está bien. Cuanto más uses estos comandos, más fácilmente los recordarás. Te puedes referir a mi hoja de trucos de comandos de stash de git para una referencia rápida.

Espero que hoy hayas captado nuevas cosas sobre el stash de git. Es tiempo de relajarse y tomar un café o un té 🍵. ¡Hazme saber si tienes preguntas!

Hay cuatro comandos diferentes de Git que puedes usar para enumerar todas las ramas remotas de repositorio. Le mostraré ejemplos de código de cada uno de estos.

Todos los ejemplos están disponibles en el repositorio abierto de freeCodeCamp.

Comando #1: git branch -r

Este comando te mostrará ramas remotas. La bandera -r es la abreviación de --remotes.

freecodecamp➜~/web/freeCodeCamp(main)» git branch -r

Output: 
  origin/HEAD -> origin/main
  origin/i18n-sync-client
  origin/main
  origin/prod-current
  origin/prod-staging
  origin/renovate/react-i18next-11.x
  origin/renovate/typescript-eslint-monorepo

Este es el comando que uso personalmente. Entonces, si lo deseas, puedes dejar de leer aquí y usar git branch -r siempre que quieras enumerar las remas remotas en Git.

Pero para completar, he incluido otros tres comandos que puedes usar y que devuelven listas diferentes.

Comando #2: git ls-remote --heads

Este comando regresa la misma información, pero también incluye el hash de las ramas remotas.

freecodecamp➜~/web/freeCodeCamp(main)» git ls-remote --heads

Output: 
From git@github.com:freeCodeCamp/freeCodeCamp
12d742a4f0dfdcfae25d1b71aa738b4e91bfcb61	refs/heads/i18n-sync-client
f05262b823f5a578787e5387357383f09df9c5c1	refs/heads/main
6d89576b6c588e3e3daa90bdaf226a6f5cc3d9c5	refs/heads/prod-current
6d89576b6c588e3e3daa90bdaf226a6f5cc3d9c5	refs/heads/prod-staging
750af5a018008c9a7eac683b064adc016b990659	refs/heads/renovate/react-i18next-11.x
08e06f10363ab1d33156b83b2b01cad005c3a2cf	refs/heads/renovate/typescript-eslint-monorepo

Comando #3: git ls-remote

Este comando muestra no solo los nombres de los repositorios remotos, sino también su información de referencia, incluido el hash de confirmación de Git.

freecodecamp➜~/web/freeCodeCamp(main)» git ls-remote

Output:

! [origin/HEAD] chore(deps): update dependency @types/validator to v13.7.3
 ! [origin/i18n-sync-client] fix(client): prevent lower jaw breaking on code evaluation (#46154)
  ! [origin/main] chore(deps): update dependency @types/validator to v13.7.3
   ! [origin/prod-current] fix(curriculum): don't block fragment links (#46246)
    ! [origin/prod-staging] fix(curriculum): don't block fragment links (#46246)
     ! [origin/renovate/react-i18next-11.x] fix(deps): update dependency react-i18next to v11.17.0
      ! [origin/renovate/typescript-eslint-monorepo] chore(deps): update typescript-eslint monorepo to v5.27.0
-------

Hay muchos resultados con formato especial, así que solo incluiré una captura de pantalla para darte una idea:

Comando #4: git show-branch -r

La razón principal por la que usarías este comando es porque muestra casi todo, por lo que puedes presionar ctrl+f para encontrar un hash en particular.

No recuerdo haber usado esto antes.

freecodecamp➜~/web/freeCodeCamp(main)» git show-branch -r

Output:

From git@github.com:freeCodeCamp/freeCodeCamp
f05262b823f5a578787e5387357383f09df9c5c1	HEAD
12d742a4f0dfdcfae25d1b71aa738b4e91bfcb61	refs/heads/i18n-sync-client
f05262b823f5a578787e5387357383f09df9c5c1	refs/heads/main
6d89576b6c588e3e3daa90bdaf226a6f5cc3d9c5	refs/heads/prod-current
6d89576b6c588e3e3daa90bdaf226a6f5cc3d9c5	refs/heads/prod-staging
750af5a018008c9a7eac683b064adc016b990659	refs/heads/renovate/react-i18next-11.x
08e06f10363ab1d33156b83b2b01cad005c3a2cf	refs/heads/renovate/typescript-eslint-monorepo
36380c5a67938de35d7011e33855d45bb545300b	refs/pull/10/head
d12e25f250b91afc01a43af0067d7026c39473fa	refs/pull/100/head
56ff814f24385e5f76dc29bc4276c84e38ca9c5f	refs/pull/10006/head
f84bb9a94ea33e0994e2d40c779416f3caa3aa04	refs/pull/10007/head
7193b9c725ed97cd8cc99aba72ceffa40a79c8f8	refs/pull/10008/head

[30,000 more lines]

9656d9030eb472341eebf5e0fb46a3538740701b	refs/pull/9991/head
0545010ab9e1dac4aedca071669b6a86b35cabdc	refs/pull/9995/head
b5365d3106e188fa6782388221b1184dfb2ffc88	refs/pull/9995/merge
0545010ab9e1dac4aedca071669b6a86b35cabdc	refs/pull/9996/head
b5365d3106e188fa6782388221b1184dfb2ffc88	refs/pull/9996/merge
7e35af7b67c22b502cdfdf4663fafc788e75eeec	refs/pull/9997/head
d8f3a9cb2e6d41a95f610ac72efae30ca9952d6f	refs/remotes/origin/pr-39112-with-my-additional-commits-for-tests
d3aaa5a11e09f5996cfd5eb2f8b55f63785b4947	refs/remotes/upstream/master
56d78a11198a0d244bd131a8b9386b247212c5a1	refs/remotes/upstream/production-current
b73c7eac62d30fdc5e533f617dcd1b5e95306984	refs/remotes/upstream/staging

Para el repositorio FreeCodeCamp, este comando devolvió más de 30.000 líneas de ramas. Por tanto, no recomendaría usar este comando a no ser que sea absolutamente necesario verlo todo. 😅

Eso es todo. Espero que tengas un día fantástico y feliz codificación.

Git es un sistema de control de versiones que ayuda a equipos e individuos a rastrear y registrar los cambios realizados en un archivo o en un proyecto completo.

Cuando trabajas con Git, a menudo confirmas tus cambios y luego los envías a un repositorio remoto.

Supongamos que has realizado muchas confirmaciones y luego te das cuenta de que tu versión actual de cambios es errónea. O descubres una situación que requiere que reviertas a una confirmación anterior, como un error extraño.

Cambiar manualmente cada línea de código en tu archivo a su estado original o a un estado de confirmación específico y hacer una nueva confirmación puede llevar a un historial de confirmaciones desordenado. Revertir el archivo es una forma mucho más limpia de manejarlo.

Hay muchos enfoques posibles, pero en este artículo aprenderás el mejor enfoque, el método git checkout.

Si tienes prisa, aquí está el comando:

$ git checkout SHA-HASH -- archivo/ruta-del-archivo

Pero supongamos que no tienes prisa. Primero aprendamos cómo localizar todas las confirmaciones previas y sus códigos hash SHA. Luego veremos cómo revertir un archivo a una confirmación anterior.

Cómo encontrar el SHA/ID de confirmación

Hay muchas formas de obtener el SHA y los detalles de cada confirmación. El mejor método es usar el siguiente comando en tu terminal:

$ git log

Este comando mostrará una lista de todas las confirmaciones que has realizado en tu proyecto para todos los archivos y sus códigos hash:

Pero un comando más simple de usar es el siguiente, donde añades la opción oneline:

$ git log -- oneline

Nota: La opción oneline muestra la salida como una confirmación por línea.

198d425 (HEAD -> main) initial
c368a1c new removal
bcbef35 updated readme 2
da9cc5f (origin/main) updated Readme
a5150af first commit

Usando solo este comando devolvería todas las confirmaciones realizadas en ese proyecto. Si deseas revertir un archivo en particular a una confirmación anterior, primero debes ver todas las confirmaciones realizadas a ese archivo.

Para hacer esto, agrega el nombre del archivo al comando:

$ git log -- oneline README.md

En una situación donde el archivo se encuentra en otra carpeta, puedes navegar mediante tu terminal a esa carpeta o usar la ruta del archivo en el comando como se ve a continuación:

$ git log -- oneline src/App.js

Esto devolverá solo las confirmaciones para el archivo especificado y el código hash SHA de la confirmación seguido por el mensaje de confirmación. Utilizarás el hash SHA para revertir tu archivo:

198d425 (HEAD -> main) initial
c368a1c new removal
bcbef35 updated readme 2
da9cc5f (origin/main) updated Readme
a5150af first commit

Cómo revertir un archivo a una confirmación previa

Ahora que sabes cómo obtener el código SHA, puedes usar el comando git checkout para revertir tu archivo a cualquier confirmación que deseas, pasando también el nombre del archivo o la ruta del archivo:

$ git checkout da9cc5f -- README.md

Ó

$ git checkout 55a1dff -- src/App.js

Solo asegúrate de querer revertir ese archivo antes de hacerlo, porque vas a descartar tus cambios locales y actuales del archivo. Git reemplazará el archivo con la versión confirmada especificada. Usa esto solo si estás seguro y no quieres esos cambios locales no guardados.

Resumiendo

En este artículo, has aprendido cómo revertir un archivo a una confirmación previa con el comando git checkout.

Es importante saber que cuando reviertes, necesitarás confirmar los cambios nuevamente (los cambios revertidos). Puedes hacer esto con el comando confirmar estándar:

$ Git commit -m 'mensaje de confirmación'

Luego puedes enviar esa confirmación al repositorio remoto que desees.

Puedes aprender más sobre Git y GitHub en este curso completo de 5+ horas, video o estos artículos.

¡Diviértete programando!

Las ramas Git (del inglés branches) te permiten agregar nuevas características sin modificar la versión "viva" (de producción) de tu proyecto. Y si trabajas en un equipo, distintos desarrolladores podrían tener ramas independientes o únicas en las que trabajar.

Al largo plazo tendrás que empujar (subir) esas ramas independientes a un servidor remoto como, por ejemplo; GitHub, GitLab, entre otros.

En este artículo te voy a mostrar cómo puedes empujar una rama Git de tu entorno local a un servidor remoto. No importa si todavía no has empujado ninguna rama, tampoco si ya has empujado solo la rama principal de tu repositorio y quieres empujar otras. Te voy a enseñar todo desde cero.

Como empujar la rama principal al remoto

Si quieres empujar la rama main (principal) al servidor remoto por primera vez, necesitarás asegurarte de que hayas ejecutado antes los siguientes comandos:

• git init para inicializar el repositorio local.
• git add . para agregar todos los archivos al repositorio local
• git commit -m ‘mensaje descriptivo del commit’ para guardar los cambios realizados a los archivos que contiene el repositorio

Para empujar el repositorio "main", será necesario primero agregar el servidor remoto a Git ejecutando git remote add <url>.

Para confirmar que se ha agregado el servidor remoto, ejecuta git remote -v:

Finalmente, para empujar el repo ejecuta git push -u origin <branch-name> ("main" es el nombre de la rama que yo estoy empujando). La rama principal podría ser "master" o "main" para ti, ya que antes "master" era el nombre por defecto, pero ahora es "main".  Pero puedes ejecutar  git branch -M main en caso de que se llame "master" para cambiarle el nombre a "main" si así lo prefieres.

Si has configurado Git para usar el asistente de credenciales, se te pedirá tu nombre de usuario GitHub y el PAT (del inglés, Personal Access Token):

Así es como empujas la rama principal (main) por primera

Como empujar una rama nueva al repositorio remoto

Si tienes otra rama con la que has trabajado que quieres empujar al repositorio remoto, también usaras el comando git push, pero de manera ligeramente distinta.

Como recordatorio, para crear una nueva rama debes ejecutar git branch nombre-rama. Y para cambiarte a esa rama, para poder trabajar en ella, tienes que ejecutar git switch branch-name o git checkout branch-name

Para empujar la rama al servidor remoto, ejecuta git push -u origin <branch name>. En mi caso, el nombre de esa rama es bug-fixes. Asi que ya he ejecutado git push -u  origin bug-fixes:

Para confirmar que la rama ha sido empujada correctamente, ve a GitHub y haz clic en el menú colapsable que muestra la rama actual y las disponibles. Deberías ver la nueva rama ahí:

Conclusión

Este artículo te ha mostrado como empujar una rama a un repositorio remoto. Además de eso, también vimos cómo puedes hacerlo por primera vez.

Si quieres aprender más acerca de git, revisa los otros artículos de freeCodeCamp en español que cubren los temas de Git y GitHub.

Cuando trabaja con Git, es posible que desee eliminar ramas remotas enviadas a plataformas como GitHub por varios motivos.

En este artículo, te mostraré cómo eliminar una rama remota en Git. Pero primero, veamos cómo eliminar una rama local.

Usaré Git bash en este artículo porque hace que trabajar con Git sea más fácil que con cualquier otro terminal. Pero está bien si usas otro terminal. Los comandos siguen siendo los mismos.

Cómo eliminar una rama local en Git

Ejecute git branch o git branch -a para ver las ramas que ha creado para su proyecto.

Si ejecuta git branch -a en particular, hará que enliste las ramas remotas sean por separado. Esta es una característica que he visto sólo en Git bash.

En esta situación, test-branch2 es una rama local que todavía tengo que mandar a GitHub.

Para eliminar una rama local, ejecute git branch -d nombre-rama.

Si escribe el comando correctamente, recibirá una respuesta de que la rama ha sido eliminada.

Cómo eliminar una rama remota en Git

Si intenta eliminar una rama remota con el mismo comando que se usa para eliminar una rama local, recibirá un mensaje de que la rama ha sido eliminada. Pero si ejecuta git branch -a, la rama seguirá apareciendo en la lista.

Y si revisas GitHub, la rama seguirá ahí:

Para eliminar completamente una rama remota, debe usar el comando git push origin con la bandera -d y luego especificar el nombre de la rama remota.

Entonces, la sintaxis que representa el comando para eliminar una rama remota se ve así: git push origin -d nombre-rama.

Por ejemplo, para eliminar la rama test-branch1 ejecute git push origin -d test-branch1.

Para verificar que la rama remota se haya eliminado, ejecute git branch -a nuevamente.

Puede ver que la rama remota, test-branch1, ya no aparece en la lista.

Si revisas nuevamente GitHub, no estará allí:

Para terminar...

Tenga en cuenta que, para eliminar completamente una rama de Git de su proyecto, debe usar el comando git push origin.

Eso es porque ya has mandado la rama a GitHub. Entonces, ejecutar el comando git branch -d solo eliminará la rama localmente.

Si tienes problemas para trabajar con Git, te sugiero que cambies tu terminal a Git bash. Esto se debe a que tiene resaltado de sintaxis para todo, lo que facilita el trabajo con Git.

Gracias por leer.

Al realizar cambios en un repositorio de Git, la mejor práctica es hacer push de los cambios a una rama diferente. Esto permite comparar los cambios antes de hacer un pull request y finalmente fusionar las ramas.

Esto es esencialmente crucial cuando se trabaja con otros desarrolladores.

La rama main de tu repositorio es considerada como la rama principal, es la única rama presente por defecto. Ahora repasemos rápidamente cómo crear ramas en Git.

Cómo crear ramas en Git

En esencia, hay dos métodos para crear ramas en Git.

Puede usar un sólo comando para crear la rama y moverse a ella. O bien, puede crear la rama primero con un comando y luego moverse a ella con otro comando cuando desee trabajar en esa rama.

Aquí está una versión rápida del código:

// crear una rama y moverse a esa rama
$ git checkout -b <nombre-rama>

// crear sólo una rama
$ git branch <nombre-rama>

Cómo crear una rama en Git y moverse a esa nueva rama

Podemos crear una nueva rama y moverse a ella usando el comando git checkout con la opción -b y <nombre-rama>. Se ve así:

$ git checkout -b <branch-name>

Supongamos que queremos crear una nueva rama de Git llamada "paginación" a partir de la rama main. Para lograr esto, usaremos el comando git checkout con la opción -b seguido del nombre de la rama "paginación".

Como puede ver, creamos una nueva rama y el comando checkout hizo que nuestra rama cambiara automáticamente de "main" a "paginación".

Veamos ahora cómo crear una rama en Git sin movernos a ella.

Cómo crear una rama en Git sin movernos a la nueva rama

Este es el método estándar para crear una rama usando el comando git branch y especificando el nombre de la rama en Git que desea crear.

$ git branch <nombre-rama>

Por ejemplo, como hicimos anteriormente, podemos crear una rama "paginación" para reemplazar con "paginación". Así es como se vería:

Como puede ver, la rama no cambió, pero se creó una nueva rama. Para ver una lista de todas las ramas disponibles, puede usar este comando:

$ git branch

Finalmente, supongamos que más tarde deseamos cambiar a nuestra nueva rama en Git o a cualquier otra rama que hayamos creado anteriormente. En este caso, podemos hacer uso del comando git checkout.

$ git checkout <branch-name>

Conclusión

En este artículo, aprendimos a usar comandos de Git en nuestra terminal para crear una rama localmente.

Si queremos agregar esta rama de forma remota, todo lo que tenemos que hacer es enviarla a nuestro proveedor de Git como GitHub usando el siguiente comando:

$ git push -u origin <nombre-rama>

Aprende a clonar una rama específica con Git con este artículo.  

¡Feliz codificación!

Puedes acceder a más de 200 de mis artículos visitando mi sitio web. También puedes usar el campo de búsqueda para ver si he escrito un artículo específico.

Git es un sistema de control de versiones distribuido que ayuda a los desarrolladores a colaborar en proyectos de cualquier escala.

Linus Torvalds, el desarrollador del kernel de Linux, creó Git en 2005 para ayudar a controlar el desarrollo de este.

¿Qué es un sistema de control de versiones distribuido?

Un sistema de control de versiones distribuido es un sistema que ayuda a realizar un seguimiento de los cambios hechos en los archivos de tu proyecto.

Este historial de cambios vive en tu máquina local y te permite volver a una versión anterior de tu proyecto con facilidad en caso de que algo salga mal.

Git facilita la colaboración. Cada miembro del equipo puede mantener una copia de seguridad completa de los repositorios en los que está trabajando en su máquina local. Luego, gracias a un servidor externo como BitBucket, GitHub o GitLab, puede almacenar el repositorio de forma segura en un solo lugar.

De esta forma, diferentes miembros del equipo pueden copiarlo localmente y todos tienen una clara visión general de todos los cambios realizados por todo el equipo.

Git tiene muchos comandos diferentes que puedes usar. Y descubrí que estos cincuenta son los que uso con más frecuencia (y, por lo tanto, son los más útiles para recordar).

Así que los anoté y pensé que sería bueno compartirlos con la comunidad. Espero que los encuentres útiles – Disfrútalos.

Cómo verificar tu configuración de Git:

El siguiente comando devuelve una lista de información sobre tu configuración de Git, incluido el nombre de usuario y el correo electrónico:

git config -l

Cómo configurar tu nombre de usuario de Git:

Con el siguiente comando puedes configurar tu nombre de usuario:

git config --global user.name "Fabio"

Cómo configurar tu usuario de correo electrónico de Git:

Este comando te permite configurar la dirección de correo electrónico del usuario que utilizarás en tus confirmaciones.

git config --global user.email "inscripciones@fabiopacifici.com"

Cómo almacenar en caché tus credenciales de inicio de sesión en Git:

Puedes almacenar las credenciales de inicio de sesión en el caché para que no tengas que escribirlas cada vez. Solo usa este comando:

git config --global credential.helper cache

Cómo inicializar un repositorio Git:

Todo comienza desde aquí. El primer paso es inicializar un nuevo repositorio de Git localmente en la raíz de tu proyecto. Puedes hacerlo con el siguiente comando:

git init

Cómo agregar un archivo al área de preparación en Git:

El siguiente comando agregará un archivo al área de preparación. Simplemente, reemplaza el nombre_de_archivo_aquí con el nombre del archivo que deseas agregar al área de preparación.

git add nombre_de_archivo_aquí

Cómo agregar todos los archivos en el área de preparación en Git

Si deseas agregar todos los archivos de tu proyecto al área de preparación, puedes usar un comodín . y cada archivo se agregará para ti.

git add .

Cómo agregar ciertos archivos al área de preparación en Git

Con el asterisco en el siguiente comando, puedes agregar todos los archivos que comienzan con fil en el área de preparación.

git add fil*

Cómo verificar el estado de un repositorio en Git:

Este comando mostrará el estado del repositorio actual, incluidos los archivos preparados, no preparados y sin seguimiento.

git status

Cómo confirmar cambios en el editor en Git:

Este comando abrirá un editor de texto en la terminal donde podrás escribir un mensaje de confirmación completo.

Un mensaje de confirmación se compone de un breve resumen de los cambios, una línea vacía y una descripción completa de los cambios posteriores.

git commit

Cómo confirmar cambios con un mensaje en Git:

Puedes agregar un mensaje de confirmación sin abrir el editor. Este comando solo te permite especificar un breve resumen para tu mensaje de confirmación.

git commit -m "tu mensaje de confirmación aquí"

Cómo confirmar cambios (y omitir el área de preparación) en Git:

Puedes agregar y confirmar archivos rastreados con un solo comando utilizando las opciones -a y -m.

git commit -a -m"tu mensaje de confirmación aquí"

Cómo ver tu historial de confirmaciones en Git:

Este comando muestra el historial de confirmación del repositorio actual:

git log

Cómo ver tu historial de confirmaciones, incluidos los cambios en Git:

Este comando muestra el historial de confirmaciones, incluidos todos los archivos y sus cambios:

git log -p

Cómo ver una confirmación específica en Git:

Este comando muestra una confirmación específica.

Reemplaza commit-id con el id de la confirmación que se encuentra en el registro de confirmación después de la palabra commit.

git show commit-id

Cómo ver las estadísticas de registro en Git:

Este comando hará que el registro de Git muestre algunas estadísticas sobre los cambios en cada confirmación, incluidas las líneas cambiadas y los nombres de los archivos.

git log --stat

Cómo ver los cambios realizados antes de confirmarlos usando "diff" en Git:

Puedes pasar un archivo como parámetro para ver solo los cambios en un archivo específico.
git diff muestra solo los cambios sin preparar de forma predeterminada.

Podemos llamar a diff con el indicador --staged para ver cualquier cambio por etapas.

git diff
git diff mi_archivo.py
git diff --staged

Cómo ver los cambios usando "git add -p":

Este comando abre un aviso y te pregunta si deseas realizar cambios o no, e incluye otras opciones.

git add -p

Cómo eliminar archivos rastreados del árbol de trabajo actual en Git:

Este comando espera un mensaje de confirmación para explicar por qué se eliminó el archivo.

git rm nombre_del_archivo

Cómo cambiar el nombre de los archivos en Git:

Este comando prepara los cambios, luego espera un mensaje de confirmación.

git mv archivo_viejo archivo_nuevo

Cómo ignorar archivos en Git:

Crea un archivo .gitignore y confírmalo.

Cómo revertir cambios no preparados en Git:

git checkout nombre_del_archivo

Cómo revertir los cambios por etapas en Git:

Puedes usar el indicador  -p para especificar los cambios que deseas restablecer.

git reset HEAD nombre_del_archivo
git reset HEAD -p

Cómo modificar la confirmación más reciente en Git:

git commit --amend te permite modificar y agregar cambios a la confirmación más reciente.

git commit --amend

!Nota!: Arreglar una confirmación local con ammend es excelente y puedes enviarlo a un repositorio compartido después de que lo hayas arreglado. Pero debes evitar modificar las confirmaciones que ya se han hecho públicas.

Cómo revertir la última confirmación en Git:

git revert creará una nueva confirmación que es lo opuesto a todo en la confirmación dada. Podemos revertir la última confirmación usando el alias principal como este:

git revert HEAD

Cómo revertir una confirmación antigua en Git:

Puedes revertir una confirmación anterior usando su id de confirmación. Esto abre el editor para que pueda agregar un mensaje de confirmación.

git revert confirmación_id_aquí

Cómo crear una nueva rama en Git:

Por defecto, tienes una rama, la rama principal. Con este comando, puedes crear una nueva rama. Git no lo cambiará automáticamente; deberás hacerlo manualmente con el siguiente comando.

git branch nombre_de_la_rama

Cómo cambiar a una rama recién creada en Git:

Cuando quieras usar una rama diferente o recién creada, puedes usar este comando:

git checkout nombre_de_la_rama

Cómo listar ramas en Git:

Puedes ver todas las ramas creadas usando el comando git branch. Mostrará una lista de todas las ramas y marcará la rama actual con un asterisco y la resaltará en verde.

git branch

Cómo crear una rama en Git y cambiar a ella inmediatamente:

Con un solo comando, puedes crear y cambiar a una nueva rama de inmediato.

git checkout -b nombre_de_la_rama

Cómo eliminar una rama en Git:

Cuando hayas terminado de trabajar con una rama y la hayas fusionado, puedes eliminarla usando el siguiente comando:

git branch -d nombre_de_la_rama

Cómo fusionar dos ramas en Git:

Para fusionar el historial de la rama en la que te encuentras actualmente con el nombre_de_otra_rama, debes usar el siguiente comando:

git merge nombre_de_otra_rama

Cómo mostrar el registro de confirmación como un gráfico en Git:

Podemos usar --graph para que el registro de confirmación se muestre como un gráfico. Además, --oneline limitará los mensajes de confirmación a una sola línea.

git log --graph --oneline

Cómo mostrar el registro de confirmación como un gráfico de todas las ramas en Git:

Hace lo mismo que el comando anterior, pero para todas las ramas.

git log --graph --oneline --all

Cómo cancelar una fusión conflictiva en Git:

Si deseas descartar una fusión y comenzar de nuevo, puedes ejecutar el siguiente comando:

git merge --abort

Cómo agregar un repositorio remoto en Git

Este comando agrega un repositorio remoto a tu repositorio local (simplemente reemplaza https://repositorio_aquí con la URL de su repositorio remoto).

git add remote https://repositorio_aquí

Cómo ver las URL remotas en Git:

Puedes ver todos los repositorios remotos de tu repositorio local con este comando:

git remote -v

Cómo obtener más información sobre un repositorio remoto en Git:

Simplemente reemplaza origin con el nombre del repositorio remoto obtenido al ejecutar el comando git remote -v.

git remote show origin

Cómo enviar cambios a un repositorio remoto en Git:

Cuando todo tu trabajo esté listo para guardarse en un repositorio remoto, puedes enviar todos los cambios con el siguiente comando:

git push

Cómo extraer cambios de un repositorio remoto en Git:

Si otros miembros del equipo están trabajando en tu repositorio, puedes recuperar los últimos cambios realizados en el repositorio remoto con el siguiente comando:

git pull

Cómo verificar las ramas remotas que Git está rastreando:

Este comando muestra el nombre de todas las ramas remotas que Git está rastreando para el repositorio actual:

git branch -r

Cómo obtener cambios de repositorios remotos en Git:

Este comando descargará los cambios desde un repositorio remoto, pero no realizará una fusión en tu rama local (ya que git pull lo hace en su lugar).

git fetch

Cómo verificar el registro de confirmaciones actual de un repositorio remoto en Git

Confirmación tras confirmación, Git crea un registro. Puedes encontrar el registro del repositorio remoto usando este comando:

git log origin/main

Cómo fusionar un repositorio remoto con tu repositorio local en Git:

Si el repositorio remoto tiene cambios que deseas fusionar con tu repositorio local, este comando lo hará por ti:

git merge origin/main

Cómo obtener el contenido de ramas remotas en Git sin fusionarlas automáticamente:

Esto te permite actualizar la rama remota sin fusionar ningún contenido en las ramas locales. Puedes llamar a git merge o git checkout para realizar la fusión.

git remote update

Cómo enviar una nueva rama a un repositorio remoto en Git:

Si deseas enviar una rama a un repositorio remoto, puedes usar el siguiente comando. Solo recuerda agregar -u para crear la rama upstream:

git push -u origin nombre_de_la_rama

Cómo eliminar una rama remota en Git:

Si ya no necesitas una sucursal remota, puedes eliminarla usando el siguiente comando:

git push --delete origin nombre_de_la_rama_aquí

Cómo usar Git rebase:

Puedes transferir el trabajo completado de una rama a otra usando git rebase.

git rebase nombre_de_la_rama_aquí

Git Rebase puede complicarse mucho si no lo haces correctamente. Antes de usar este comando, te sugiero que vuelvas a leer la documentación oficial aquí.

Cómo ejecutar rebase de forma interactiva en Git:

Puedes ejecutar git rebase de forma interactiva usando el indicador -i. Abrirá el editor y presentará un conjunto de comandos que puedes usar.

git rebase -i master
# p, pick = usar confirmación.
# r, reword = usar confirmación pero editar el mensaje de confirmación.
# e, edit = usar confirmación pero detenerse para modificar.
# s, squash = usar confirmación pero fusionarla con la confirmación anterior.
# f, fixup = como "squash", pero descartando el mensaje de confirmación.
# x, exec = ejecutar comando (el resto de la linea) usando shell.
# d, drop = eliminar confirmación.

Cómo forzar una solicitud push en Git:

Este comando forzará una solicitud de inserción (push). Por lo general, esto está bien para las ramas de solicitud de extracción (pull request),  porque nadie más debería haberlas clonado. Pero esto no es algo que desees hacer con repositorios públicos.

git push -f

Conclusión

Estos comandos pueden mejorar drásticamente tu productividad en Git. No tienes que recordarlos todos, por eso he escrito esta hoja de trucos. Marca esta página para futuras referencias o imprímela si lo deseas.

¡Gracias por leer! Por cierto, soy Fabio, desarrollador web full-stack, docente, y profesional certificado en automatización de IT con Python.

Git es una herramienta de control de versiones que le permite mantener y ver diferentes versiones de su aplicación. Cuando una nueva actualización rompe su aplicación, Git le permite revertir esos cambios a la versión anterior.

Además del control de versiones, Git le permite trabajar en múltiples entornos al mismo tiempo. Múltiples entornos en este contexto significa ramas.

¿Por qué necesitas ramas?

Cuando trabajes con git, tendrás un entorno maestro (también llamado principal) (rama). Esta rama en particular contiene el código fuente que se implementa cuando su aplicación está lista para la producción.

Cuando desees actualizar su aplicación, también puedes agregar más cambios (commits) a esta rama. Para cambios menores, esto puede no ser un gran problema, pero para cambios grandes, hacer esto no es lo ideal. Y es por eso que existen otras ramas.

Para crear y usar una nueva rama, usa el siguiente comando en tu terminal en el directorio del proyecto:

# crear una nueva rama
git branch rama-nombre
# cambiar el ambiente a la nueva rama
git checkout rama-nombre

En esta nueva rama, puede crear los nuevos cambios. Luego, cuando hayas terminado, puedes combinarlos con la rama maestra.

Otro beneficio de las ramas es que permiten que varios desarrolladores trabajen en el mismo proyecto simultáneamente. Si tienes varios desarrolladores trabajando en la misma rama maestra, puede ser desastroso. Tiene demasiados cambios entre el código de cada desarrollador, y esto generalmente termina en conflictos de combinación.

Con Git, puede saltar a otra rama (otro entorno) y realizar cambios allí, mientras se trabaja en otras ramas.

¿Qué significa rama remota de Git Checkout?

Cuando comienzas un proyecto con Git, obtiene dos entornos: la rama maestra local (que existe en su computadora) y la rama maestra remota (que existe en una plataforma compatible con Git como GitHub).

Puedes enviar cambios desde la rama principal local a la rama principal remota y también extraer cambios de la rama remota.

Cuando creas una rama localmente, solo existe localmente hasta que se envía a GitHub, donde se convierte en la rama remota. Esto se muestra en el siguiente ejemplo:

# crear una nueva rama
git branch nueva-rama
# cambiar el ambiente a la nueva rama
git checkout nueva-rama
# crear un cambio
touch nuevo-archivo.js
# cometer el cambio
git add .
git commit -m "añadir nuevo archivo"
# empujar a una nueva rama
git push --set-upstream origin nueva-rama

Del ejemplo anterior, origin nueva-rama se convierte en la rama remota. Como habrás notado, creamos una nueva rama y confirmamos un cambio en ella antes de pasar a la nueva rama remota.

Pero, ¿qué pasaría si la rama remota ya existiera y quisiéramos llevar la rama y todos sus cambios a nuestro entorno local?

Ahí es donde hacemos una "Rama Remota de Git Checkout".

Cómo hacer Git Checkout en una rama remota

Digamos que hay una rama remota creada por otro desarrollador y desea extraer esa rama. Así es como lo haces:

1. Recuperar todas las ramas remotas

git fetch origin

Esto recupera todas las ramas remotas del repositorio. origin es el nombre remoto al que se dirige. Entonces, si tenía un nombre remoto upstream, puedes llamar a git fetch upstream.

2. Enumera las ramas disponibles para checkout

Para ver las ramas disponibles para checkout, ejecute lo siguiente:

git branch -a

El resultado de este comando es la lista de ramas disponibles para checkout. Para las ramas remotas, las encontrará con el prefijo remotes/origin.

3. Obtener cambios de una rama remota

Tenga en cuenta que no puedes hacer cambios directamente en una rama remota. Por lo tanto, necesitas una copia de esa rama. Digamos que deseas copiar fix-failing-tests de la rama remota, así es como lo harías:

git checkout -b fix-failing-tests origin/fix-failing-tests

Lo que esto hace es:

• crea una nueva rama llamada fix-failing-tests
• checkout esa rama
• extrae los cambios desde el origin/fix-failing-tests a esa rama

Y ahora tienes una copia de esa rama remota. Además, puedes enviar confirmaciones a esa rama remota. Por ejemplo, puedes empujar un nuevo compromiso así:

touch nuevo-archivo.js
git add .
git commit -m "añadir nuevo archivo"
git push

Esto empujará los cambios comprometidos a origin/fix-failing-tests. Si te diste cuenta, no tuvimos que especificar dónde estábamos enviando los cambios (como git push origin fix-failing-tests). Eso es porque git configura automáticamente la rama local para rastrear la rama remota.

Conclusión

La ramificación de Git facilita mucho la colaboración durante el desarrollo de aplicaciones.

Con las ramas, diferentes desarrolladores pueden trabajar fácilmente en diferentes partes de la aplicación simultáneamente.

Con la rama remota de Checkout, la colaboración se vuelve incluso más fluida, ya que los desarrolladores también pueden copiar ramas remotas localmente en sus sistemas, realizar cambios y enviarlos a las ramas remotas.

El comando básico para cargar o subir una rama local a un repositorio remoto es git push.

Este comando tiene una variedad de opciones y parámetros que puedes pasarle, y en este artículo aprenderás los que usarás más a menudo.

Cómo subir una rama local de Git al origen (origin)

Si ejecutas el comando simple git push, por defecto, Git elegirá dos parámetros más por ti: el repositorio remoto y la rama a la que subir.

La forma general del comando es esta:

$ git push <remote> <branch>

Por defecto, Git elige origin como remoto y tu rama actual como la rama a la que subir.

Si tu rama actual es main, el comando git push suministrará los dos parámetros por defecto — ejecutándolo así git push origin main.

En el ejemplo de abajo, el remoto  origin es un repositorio de GitHub, y la rama actual es main:

(main)$ git remote -v 
origin  git@github.com:johnmosesman/burner-repo.git (fetch)
origin  git@github.com:johnmosesman/burner-repo.git (push)

(main)$ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 16 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 274 bytes | 274.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:johnmosesman/burner-repo.git
   b7f661f..ab77dd6  main -> main

De la salida se puede ver que la rama local  main fue subida a la rama remota  main:

To github.com:johnmosesman/burner-repo.git
   b7f661f..ab77dd6  main -> main

Cómo forzar la subida a una rama en Git

Normalmente, subirás una rama y añadirás a su historial de confirmaciones.

Sin embargo, hay ocasiones en las que es necesario sobrescribir a la fuerza el historial de una rama.

Hay un par de razones por las que puedes querer hacer esto.

La primera razón es para corregir un error - aunque probablemente sea mejor hacer una nueva confirmación que revierta los cambios (git revert).

El segundo y más común escenario es después de una acción como un rebase, que cambia el historial de confirmaciones:

Internamente, Git [hace un rebase] creando nuevas confirmaciones y aplicándolas a la base especificada. Es muy importante entender que, aunque la rama parece la misma, se compone de nuevas confirmaciones por completo.

Un rebase crea confirmaciones completamente nuevas.

Esto significa que si intentas cargar una rama que ha sido rebasada localmente - pero no en el remoto - el repositorio remoto reconocerá que el historial de confirmaciones ha cambiado, y te impedirá subir los cambios hasta que arregles las diferencias:

(my-feature)$ git push
To github.com:johnmosesman/burner-repo.git
 ! [rejected]        my-feature -> my-feature (non-fast-forward)
error: failed to push some refs to 'git@github.com:johnmosesman/burner-repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Puedes hacer un git pull para fusionar las diferencias, pero si realmente quieres sobrescribir el repositorio remoto puedes añadir la marca --force :

(my-feature)$ git push --force origin my-feature
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 184 bytes | 184.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To github.com:johnmosesman/burner-repo.git
 + edb64e2...52f54da my-feature -> my-feature (forced update)

(Nota: puedes usar la versión abreviada -f en vez de  --force.)

Una subida forzada es una acción destructiva - úsala solo cuando tengas la certeza de que es lo que quieres hacer.

Forzar la subida con contrato (--force-with-lease)

A veces puedes querer forzar la subida - pero solo si nadie más ha contribuido a la rama.

Si alguien más contribuye a tu rama y empuja sus cambios a la remota - y tú fuerzas, tu subida sobre ella - sobrescribirás sus cambios.

Para evitar este escenario, puedes utilizar la opción --force-with-lease.

De nuevo de la documentación oficial en inglés:

--force-with-lease solo, sin especificar los detalles, protegerá todas las referencias remotas que vayan a ser actualizadas requiriendo que su valor actual sea el mismo que la rama de seguimiento remoto que tenemos para ellas.

Básicamente, le estás diciendo a Git que fuerce la actualización de esta rama solo si tiene el mismo aspecto que la última vez que la viste.

Si está colaborando con otros en tu rama, sería bueno evitar usar --force o al menos usar --force-with-lease para evitar perder los cambios que otros colaboradores han hecho.

Cómo subir cambios a una rama con diferente nombre en Git

Normalmente, subirás tu rama local a una rama remota con el mismo nombre - pero no siempre.

Para subir a una rama con un nombre diferente, necesitas especificar la rama de la que quieres subir los cambios (nombre de la rama local) y el nombre de la rama a la que quieres subir (nombre de la rama remota) separadas con dos puntos (:).

Por ejemplo, si quieres subir de una rama llamada some-branch a my-feature:

(some-branch)$ git push origin some-branch:my-feature
Total 0 (delta 0), reused 0 (delta 0)
To github.com:johnmosesman/burner-repo.git
 + 728f0df...8bf04ea some-branch -> my-feature

Cómo subir todas las ramas locales al remoto

No necesitarás subir todas las ramas de tu local muy a menudo, pero si lo haces puedes hacerlo añadiendo la marca --all:

(main)$ git branch
* main
  my-feature

(main)$ git push --all
...
To github.com:johnmosesman/burner-repo.git
   b7f661f..6e36148  main -> main
 * [new branch]      my-feature -> my-feature

Conclusión

El comando git push es uno de los que más a menudo vas a utilizar, y hay un montón de opciones que se pueden utilizar con él. Te animo a leer la documentación oficial, para encontrar más opciones y atajos útiles.

Si te ha gustado este tutorial, también hablo de temas como este en Twitter, y escribo sobre ellos en mi página web.