¿Qué es Git?

docs.scrimba.com

Casi con certeza ya has hecho control de versiones a mano. Una carpeta con informe.docx, informe_final.docx, informe_final_v2.docx e informe_final_DEFINITIVO.docx es control de versiones, pero de la peor clase posible. No puedes saber qué cambió entre dos de esos archivos, no puedes combinar ediciones que hicieron dos personas al mismo tiempo, y definitivamente no puedes recuperar ese buen párrafo que borraste tres copias atrás.

Git resuelve ese problema de raíz. Es una herramienta que registra instantáneas de tu proyecto a lo largo del tiempo, de modo que toda tu historia vive en un solo lugar en vez de estar repartida en un montón de copias. La herramienta en sí es un pequeño programa que corre en tu propia computadora: escribes comandos que empiezan con git en una terminal, y ella te responde en texto.

Qué hace Git por ti

En esencia, Git mantiene una línea de tiempo de tu proyecto. Cada vez que llegas a un punto que vale la pena guardar, registras un commit: una instantánea de todos los archivos, más un mensaje corto que describe qué cambió y por qué. Más adelante puedes revisar esa línea de tiempo y ver exactamente cómo el proyecto llegó a donde está. Aquí tienes una línea de tiempo real, impresa por git log, el comando que lista los commits de un proyecto (la opción --oneline acorta cada uno a una sola línea):

$ git log --oneline
a1b2c3d Agregar medidor de fortaleza de contraseña
9f8e7d6 Corregir validación del formulario de registro
5c4b3a2 Configurar estructura del proyecto

Eso son tres puntos guardados en la historia de un proyecto, el más reciente arriba, cada uno con un ID corto y el mensaje que escribió su autor. (En cada ejemplo como este, la línea que empieza con $ es un comando escrito en una terminal, sin incluir el $ mismo, y las líneas debajo son la respuesta de Git.) Vas a aprender cada comando que produce y lee este historial en los próximos capítulos. Por ahora, la idea que debes retener es que Git registra tu trabajo como una serie de instantáneas a las que siempre puedes volver.

Una vez que tu proyecto tiene un historial así, se vuelven posibles muchas cosas. Puedes ver qué cambió y quién lo cambió. Puedes probar una idea riesgosa por separado y descartarla limpiamente si no funciona. Puedes entregarle el proyecto completo, con toda su historia, a otra persona. Y cuando dos personas editan el mismo código, Git puede combinar su trabajo y marcar los puntos donde están en conflicto para que una persona los resuelva. Esas cuatro capacidades —historial, experimentos seguros, compartir y combinar trabajo— son la razón por la que Git funciona en casi todo proyecto de código profesional.

En la práctica, un equipo se apoya constantemente en esa línea de tiempo. Cada cambio, sea grande o pequeño, empieza en su propia rama, una línea de historia separada donde puedes trabajar sin afectar el código principal. Cuando el cambio está listo, alguien lo revisa, y luego se integra de vuelta a la rama principal. Revisar, ramificar y fusionar son el ritmo diario de trabajar con Git, y todo esto se apoya en la línea de tiempo de instantáneas que vimos antes. El resto de este manual recorre cada parte de ese ritmo en el orden en que la vas a encontrar.

Hay un detalle que importa para todo lo que viene después: cada commit guarda el estado completo de tus archivos rastreados, una instantánea completa de ese momento. Mucha gente imagina que Git guarda solo las diferencias entre versiones, pero en realidad cada commit contiene el proyecto entero. Git logra que esto sea económico guardando cada contenido único de archivo una sola vez, así que un commit que reutiliza un archivo sin cambios solo apunta a la copia que ya está guardada, y una instantánea de mil archivos donde solo uno cambió no duplica los otros 999. Cada commit también registra el ID del commit anterior, su padre, que es cómo Git enlaza las instantáneas para formar un historial que puede recorrer hacia atrás. Ese enlace con el padre es la columna vertebral de casi todo lo demás: las ramas, las fusiones y la navegación del historial se construyen siguiendo esos punteros. Vas a ver el modelo completo de objetos en los capítulos de Historial y Ramas.

JunoQué hace Git por ti Git registra tu proyecto como una serie de instantáneas llamadas commits, cada una con un mensaje que dice qué cambió. Una vez que ese historial existe, puedes revisarlo, experimentar de forma segura, compartirlo y combinar trabajo con otras personas. El montón de copias tipo informe_final_v2_DEFINITIVO es justo el problema que Git nació para resolver, y te prometo que se siente genial la primera vez que borras una de esas.

JunoQué hace Git por ti Un commit es una instantánea más un mensaje, y el historial es una línea de tiempo de esos commits. Día a día, te ramificas desde esa línea de tiempo para hacer un cambio, lo mandas a revisión y lo fusionas de vuelta. Guarda en tu cabeza el modelo mental de una línea de tiempo de instantáneas que va creciendo; cada comando que aprendas o agrega a esa línea o lee de ella.

JunoQué hace Git por ti Cada commit guarda el estado completo del proyecto y apunta a su padre, que es cómo Git recorre el historial. Los contenidos de archivo idénticos se guardan una sola vez y se comparten entre commits, así que las instantáneas se mantienen económicas. Quédate con la idea del puntero al padre, porque las ramas y las fusiones son la misma idea con otro disfraz.

Git y GitHub son cosas distintas

Este punto confunde a casi todo el mundo al principio, así que vamos directo al grano. Git es la herramienta de control de versiones. Corre en tu propia computadora, registra tus commits, y no necesita conexión a internet ni ninguna cuenta para funcionar. GitHub es un sitio web que almacena repositorios Git en línea y agrega cosas alrededor de ellos: un lugar para compartir tu código, revisar los cambios de otros, reportar problemas y colaborar.

La forma más clara de sentir la diferencia: puedes usar Git todos los días, haciendo commits y ramas en tu laptop, sin crear nunca una cuenta de GitHub. GitHub solo entra en escena cuando quieres poner tu repositorio en algún lugar compartido para que otras personas, u otras máquinas, puedan acceder a él. Git es el motor; GitHub es un lugar donde puedes alojar lo que produce. Existen otros, como GitLab y Bitbucket, y todos alojan por debajo los mismos repositorios Git.

La razón por la que las dos cosas se mezclan es que la mayoría de la gente conoce Git y GitHub al mismo tiempo, clonando un proyecto desde GitHub el primer día. Mucha gente termina pensando que git push significa "enviar a GitHub", cuando en realidad significa "enviar al remoto que configuraste", y ese remoto resulta ser GitHub la mayoría de las veces. Mantener las dos cosas separadas en tu cabeza te sirve la primera vez que uses Git con otro proveedor, o sin ninguno.

JunoGit y GitHub son cosas distintas Git es la herramienta en tu computadora que registra tus commits. GitHub es un sitio web que almacena proyectos Git en línea para que la gente pueda compartirlos y revisarlos. Puedes usar Git sin tener ninguna cuenta de GitHub. Si te llevas una sola cosa de esta página, que sea esta, porque confundirlas causa muchísima confusión al principio.

JunoGit y GitHub son cosas distintas Git es el motor de control de versiones en tu máquina; GitHub es uno de los lugares populares para alojar lo que produce, junto con GitLab y Bitbucket. git push envía al remoto que hayas configurado, que suele ser GitHub por costumbre. Mantén esa separación clara y no te vas a desorientar cuando un proyecto viva en otro lugar.

JunoGit y GitHub son cosas distintas Git sabe de commits, ramas y refs; GitHub agrega pull requests, issues y el botón de merge sobre una copia alojada. Nada de lo que agrega GitHub es un comando de Git, por eso abres un pull request en un sitio web y nunca con git. Mantén las dos cosas separadas en tu cabeza y la mayoría de lo que parece magia de GitHub vuelve a ser simples refs.

De dónde viene Git

La historia de Git explica bastante sobre por qué funciona como funciona. Fue escrito en 2005 por Linus Torvalds, la misma persona que inició Linux. El kernel de Linux lo construyen miles de voluntarios repartidos por todo el mundo, y durante varios años habían coordinado todo ese trabajo usando una herramienta comercial llamada BitKeeper, que la empresa detrás de ella dejaba usar gratis a proyectos de código abierto.

En 2005 ese acuerdo gratuito se rompió, y la comunidad del kernel de repente se quedó sin herramienta para gestionar su enorme y acelerada base de código. Nada de lo disponible en ese momento podía estar a la altura. Así que Torvalds se apartó del trabajo en el kernel durante un par de semanas y escribió su propia herramienta de control de versiones, con unos pocos objetivos firmes, moldeados justamente por ese problema.

Quería que fuera distribuida, de modo que cada colaborador tuviera el historial completo del proyecto en su propia máquina y pudiera trabajar sin depender de un servidor central. Quería que fuera rápida, lo suficiente para manejar un proyecto del tamaño del kernel sin hacer esperar a la gente. Y quería garantizar la integridad, de modo que nadie pudiera alterar el historial en silencio y que ningún error de disco pudiera corromper un proyecto sin que se notara.

Esos objetivos son la razón por la que Git se comporta hoy como se comporta. Cuando haces clone de un proyecto, obtienes todo su historial para trabajar con él, que es el objetivo de ser distribuido en acción: puedes hacer commits, ramificar y explorar el historial en un avión sin wifi. Y cada commit lleva una huella calculada a partir de su contenido exacto, así que si un solo byte cambia, la huella deja de coincidir y Git lo detecta. Las decisiones de diseño que Torvalds tomó a las carreras en 2005 son las que hoy sostienen todo lo que haces cuando usas Git.

La garantía de integridad impulsa todo el diseño. Cada commit se identifica mediante un hash, una huella de longitud fija calculada a partir del contenido completo del commit, incluyendo el ID de su padre. Como el ID del padre alimenta el hash del hijo, los hashes forman una cadena: si cambias algo en un commit antiguo, su hash cambia, lo que a su vez cambia el hash de todos los commits posteriores. Eso es lo que hace que el historial de Git sea a prueba de manipulaciones. También significa que el ID de un commit es una huella de su contenido exacto, y por eso ves esas cadenas hexadecimales como a1b2c3d en vez de un número de commit ordenado como el 42.

JunoDe dónde viene Git Linus Torvalds escribió Git en 2005 para el kernel de Linux, después de que la herramienta que el proyecto venía usando dejara de ser gratuita. La construyó para que fuera distribuida, rápida y a salvo de corrupción. Por eso clone te da todo el historial para trabajar sin conexión, y por eso cada commit obtiene una huella. Un contexto útil para una herramienta que vas a usar durante años.

JunoDe dónde viene Git Git surgió del kernel de Linux en 2005, pensado para miles de colaboradores sin un servidor central, por eso todo su modelo es distribuido. Cada clone lleva el historial completo, así que ramificas y haces commits localmente, y sincronizas cuando decides hacerlo. Cuando algún comportamiento por defecto de Git te parezca raro, la explicación suele ser "fue diseñado para el kernel".

JunoDe dónde viene Git Git nació de un esfuerzo de dos semanas de Torvalds en 2005, cuando el kernel perdió el acceso a BitKeeper, con tres objetivos: distribuido, rápido, con integridad verificada. El hash de cada commit se calcula a partir de su contenido más el hash de su padre, así que los ID forman una cadena a prueba de manipulaciones. Cuando te preguntes por qué Git hizo tal o cual elección, "fue construido para el kernel de Linux" suele ser la respuesta.

Hacia dónde va este manual a continuación

Con el modelo mental ya en su lugar, el resto del recorrido trata de ponerse a trabajar. Tu primer repositorio empieza desde cero: abrir una terminal, instalar Git si tu máquina no lo tiene, y convertir una carpeta en un repositorio al que puedas hacer commits. A partir de ahí vas a aprender el ciclo diario de guardar cambios, luego ramas, fusiones y el flujo de colaboración en GitHub. Si alguna vez un término te pierde, el Glosario tiene una definición breve para cada término de vocabulario de Git en estos documentos.