¿Qué es Git?

docs.scrimba.com

Es casi seguro que has hecho control de versiones manualmente. Una carpeta con reporte.docx, reporte_final.docx, reporte_final_v2.docx y reporte_final_ACTUAL.docx es control de versiones, del peor tipo posible. No puedes saber qué cambió entre dos de esos archivos, no puedes fusionar ediciones que dos personas hicieron al mismo tiempo, y definitivamente no puedes recuperar el párrafo bueno que eliminaste hace tres copias.

Git resuelve ese problema correctamente. Es una herramienta que registra snapshots de tu proyecto a lo largo del tiempo, para que todo tu historial viva en un solo lugar en lugar de un montón de copias. La herramienta en sí es un pequeño programa que vive en tu propia computadora: escribes comandos que comienzan con git en una terminal, y te responde en texto.

Qué Git hace 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: un snapshot de cada archivo, más un mensaje corto describiendo qué cambió y por qué. Más tarde puedes mirar atrás en esa línea de tiempo y ver exactamente cómo el proyecto llegó a donde está. Aquí hay una línea de tiempo real, impresa por git log, el comando que lista los commits de un proyecto (la bandera --oneline acorta cada uno a una sola línea):

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

Esos son tres puntos guardados en el historial de un proyecto, el más nuevo al principio, cada uno con un ID corto y el mensaje que escribió su autor. (En cada ejemplo como este, la línea que comienza con $ es un comando escrito en una terminal, sin el $ en sí, y las líneas debajo son la respuesta de Git.) Aprenderás cada comando que produce y lee este historial en los próximos capítulos. Por ahora, la idea a la que aferrarse es que Git está registrando tu trabajo como una serie de snapshots a los que siempre puedes volver.

Una vez que tu proyecto tiene un historial como este, muchas cosas se hacen posibles. Puedes ver qué cambió y quién lo cambió. Puedes intentar una idea arriesgada en paralelo y descartarla limpiamente si no funciona. Puedes entregar todo el proyecto, con su historial completo, a otra persona. Y cuando dos personas editan el mismo código, Git puede combinar su trabajo e indicar los lugares donde no están de acuerdo para que un humano pueda resolverlos. Esas cuatro capacidades: historial, experimentos seguros, compartición y combinación de trabajo, son la razón completa por la que Git funciona bajo casi cada base de código profesional.

En la práctica, un equipo se apoya en esa línea de tiempo constantemente. Cada cambio de cualquier tamaño comienza en su propia rama, una línea separada de historial donde puedes trabajar sin perturbar el código principal. Cuando el cambio está listo, alguien lo revisa, y luego se fusiona de nuevo en la rama principal. Revisar, ramificar y fusionar son el ritmo diario de trabajar en Git, y todos descansan en la línea de tiempo de snapshots anterior. El resto de este manual recorre cada pieza de ese ritmo en el orden en que la encuentras.

Un detalle importa para todo lo que viene después: cada commit almacena el estado completo de tus archivos rastreados, un snapshot completo de ese momento. La gente a menudo se imagina que Git solo guarda las diferencias entre versiones, pero bajo el capó, cada commit contiene el proyecto completo. Git mantiene eso barato almacenando cada contenido de archivo único una sola vez, así que un commit que reutiliza un archivo sin cambios solo apunta a la copia ya guardada, y un snapshot de mil archivos donde uno cambió no duplica los otros 999. Cada commit también registra el ID del commit que vino antes de él, su padre, que es cómo Git vincula snapshots en un historial que puede recorrer hacia atrás. Ese vínculo padre es la columna vertebral de casi todo lo demás: ramas, fusiones y navegación de historial se construyen todos sobre seguir esos punteros. Verás el modelo de objeto completo en los capítulos de Historial y Ramas.

JunoQué Git hace por ti Git registra tu proyecto como una serie de snapshots llamados commits, cada uno con un mensaje que dice qué cambió. Una vez que ese historial existe, puedes mirarlo de nuevo, experimentar de forma segura, compartirlo y combinar trabajo con otras personas. El montón de copias final_v2_ACTUAL es el problema para el que Git fue construido para terminar, y te prometo que se siente genial la primera vez que eliminas uno.

JunoQué Git hace por ti Un commit es un snapshot más un mensaje, y el historial es una línea de tiempo de ellos. Día a día te ramificas desde esa línea de tiempo para hacer un cambio, obtener que sea revisado y fusionarlo de nuevo. Mantén el modelo mental de una línea de tiempo creciente de snapshots en tu cabeza; cada comando que aprendas es ya sea agregándolo o leyendo desde él.

JunoQué Git hace por ti Cada commit almacena el estado del proyecto completo y apunta a su padre, que es cómo Git recorre el historial. Los contenidos de archivo idénticos se almacenan una sola vez y se comparten entre commits, así que los snapshots siguen siendo baratos. Mantente con la idea del puntero padre, porque las ramas y fusiones son la misma idea con sombreros diferentes.

Git y GitHub son cosas diferentes

Esto confunde a casi todos al principio, así que aquí está en términos claros. Git es la herramienta de control de versiones. Funciona en tu propia computadora, registra tus commits, y no necesita conexión a internet ni cuenta para funcionar. GitHub es un sitio web que almacena repositorios de Git en línea y agrega cosas alrededor de ellos: un lugar para compartir tu código, revisar los cambios entre ustedes, reportar problemas y colaborar.

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

La razón por la que los dos se difuminan es que la mayoría de las personas conocen Git y GitHub al mismo momento, clonando un proyecto de GitHub en su primer día. Muchas personas llegan a pensar que git push significa "enviar a GitHub", cuando realmente significa "enviar a cualquier remoto que hayas configurado", y ese remoto resulta ser GitHub la mayoría de las veces. Mantener los dos separados en tu cabeza vale la pena la primera vez que uses Git con un host diferente, o sin host en absoluto.

JunoGit y GitHub son cosas diferentes Git es la herramienta en tu computadora que registra tus commits. GitHub es un sitio web que almacena proyectos de Git en línea para que las personas puedan compartirlos y revisarlos. Puedes usar Git sin ninguna cuenta de GitHub. Si recuerdas una cosa de esta página, que sea esta, porque mezclarlas causa mucha confusión temprana.

JunoGit y GitHub son cosas diferentes Git es el motor de control de versiones en tu máquina; GitHub es un lugar popular para alojar lo que produce, junto con GitLab y Bitbucket. git push envía a cualquier remoto que establezcas, que usualmente es GitHub por hábito. Mantén la separación y no serás sorprendido cuando un proyecto viva en otro lugar.

JunoGit y GitHub son cosas diferentes Git conoce commits, ramas y refs; GitHub agrega pull requests, problemas y el botón de fusión sobre una copia alojada. Nada de lo que GitHub agrega es un comando de Git, que es por qué abres un pull request en un sitio web y nunca con git. Mantén los dos separados en tu cabeza y la mayoría de lo que parece magia de GitHub se convierte nuevamente en refs simples.

De dónde vino Git

El historial de Git explica mucho sobre por qué funciona como lo hace. Fue escrito en 2005 por Linus Torvalds, la misma persona que inició Linux. El kernel de Linux es construido por miles de voluntarios dispersos por todo el mundo, y durante algunos años coordinaron todo ese trabajo usando una herramienta comercial llamada BitKeeper, que la empresa detrás de ella permitía que los proyectos de código abierto usaran de forma gratuita.

En 2005 ese arreglo gratuito se vino abajo, y la comunidad del kernel de repente no tenía herramienta para manejar su enorme y rápido código base. Nada más disponible en ese momento podía mantener el ritmo. Entonces Torvalds se apartó del trabajo del kernel por un par de semanas y escribió su propia herramienta de control de versiones, con algunos objetivos firmes formados por exactamente ese problema.

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

Esos objetivos son por qué Git se comporta como lo hace hoy. Cuando clonas un proyecto, obtienes su historial completo para trabajar, que es el objetivo distribuido en acción: puedes hacer commit, ramificar y navegar el historial en un avión sin wifi. Y cada commit está marcado con una huella digital calculada a partir de su contenido exacto, así que si alguna vez un solo byte cambia, la huella digital deja de coincidir y Git lo nota. Las decisiones de diseño que Torvalds hizo apresuradamente en 2005 son en las que confías cada vez que usas Git ahora.

La garantía de integridad impulsa todo el diseño. Cada commit se identifica por un hash, una huella digital de longitud fija calculada a partir del contenido completo del commit, incluyendo el ID de su padre. Como el ID del padre se introduce en el hash del hijo, los hashes forman una cadena: cambia cualquier cosa en un commit antiguo y su hash cambia, lo que cambia el hash de cada commit después de él. 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 digital de su contenido exacto, que es por qué ves esas cadenas hexadecimales como a1b2c3d en lugar de un número de commit ordenado 42.

JunoDe dónde vino Git Linus Torvalds escribió Git en 2005 para el kernel de Linux, después de que la herramienta que el proyecto estaba usando dejara de ser gratuita. La construyó para ser distribuida, rápida y segura contra corrupción. Esa es la razón por la que clonar te da el historial completo para trabajar sin conexión, y por qué cada commit obtiene una huella digital. Contexto práctico para una herramienta que usarás durante años.

JunoDe dónde vino Git Git salió del kernel de Linux en 2005, construido para miles de colaboradores sin servidor central, que es por qué todo su modelo es distribuido. Cada clon lleva el historial completo, así que ramificas y haces commit localmente y sincronizas cuando elijas. Cuando un default de Git se siente extraño, "fue diseñado para el kernel" usualmente lo explica.

JunoDe dónde vino Git Git salió de un sprint de dos semanas por Torvalds en 2005 cuando el kernel perdió acceso a BitKeeper, con tres objetivos: distribuido, rápido, verificado por integridad. El hash de cada commit se calcula a partir de su contenido más el hash del padre, así que los IDs forman una cadena a prueba de manipulaciones. Cuando te preguntes por qué Git hizo alguna elección, "fue construido para el kernel de Linux" usualmente es la respuesta.

A dónde va este manual a continuación

Con el modelo mental en su lugar, el resto de la pista se trata de hacer el trabajo. Tu primer repositorio comienza desde cero: abriendo una terminal, instalando Git si tu máquina no lo tiene, y convirtiendo una carpeta en un repositorio al que puedes hacer commit. Desde allí aprenderás el bucle cotidiano de guardar cambios, luego ramas, fusiones y el flujo de colaboración en GitHub. Si un término alguna vez te confunde, el Glosario tiene una definición corta para cada pieza del vocabulario de Git en estos documentos.