Git desde cero: qué es, por qué existe y cómo hacer tu primer commit

El primer día que toqué Git fue en un bootcamp. El profesor escribió git add . && git commit -m "first commit" && git push en la pizarra y dijo “haced esto cada vez que terminéis algo”. Lo hice durante tres meses sin entender qué significaba ninguna de esas palabras. Hasta que un día borré sin querer la carpeta del proyecto final.

No tenía copia. No había git push. Había hecho git init y nada más.

Ese día entendí el problema que Git resuelve. Pero tardé dos años más en entender el modelo mental que hay debajo. Este post es lo que me habría gustado leer aquella primera semana.

Los seis dolores de cabeza que tienes (y Git te quita)

Antes de contarte qué es Git, necesitas saber qué problemas resuelve. Si nunca has trabajado con control de versiones, probablemente has sufrido varios de estos sin ponerles nombre:

1. Rompes algo que funcionaba y no puedes volver atrás. Modificas tres archivos para arreglar un bug, el bug se arregla pero ahora el login no funciona. No sabes qué tocaste. No hay Ctrl+Z global para todo un proyecto.

2. No sabes qué cambió desde ayer. El código funcionaba el viernes. El lunes no. Alguien tocó algo, pero los commits de tu equipo dicen “fix” y “update” y no hay manera de saber qué pasó.

3. Tú y tu compañero editasteis el mismo archivo a la vez. Los dos veis cambios que no encajan. Uno sobrescribe al otro. El que guarda segundo pierde su trabajo. Si alguna vez has tenido login-final.js, login-final-v2.js y login-final-ESTE.js en tu carpeta, sabes de qué hablo.

4. Se te rompe el portátil. O se te cae el café encima. O Windows Update decide que hoy es el día. Sin una copia externa del proyecto, has perdido todo. Meses de trabajo. No exagero: conozco a dos personas a las que les ha pasado.

5. Quieres probar una idea loca sin romper lo que funciona. Esa refactorización ambiciosa, ese cambio de librería, ese “y si reescribo el módulo de autenticación desde cero”. Pero tienes miedo de tocar algo y no poder volver atrás. Así que no lo haces.

6. Llega un bug a producción y necesitas saber quién cambió qué. El jefe pregunta. El cliente está enfadado. Y tú mirando un git log que solo dice “fix” y “update” porque nadie escribió mensajes de commit con sentido.

Si has vivido al menos tres de estos seis escenarios, bienvenido al club. Todos pasamos por ahí.

Las cuatro cosas que Git hace (y ninguna es magia)

Los seis problemas de arriba se agrupan en cuatro capacidades que Git te da. Apréndetelas porque cada vez que tengas un dolor con el código, vas a meterlo en una de estas cuatro cajas:

Recuperación. Viajar atrás en el tiempo. Borraste un archivo hace tres días y no te diste cuenta. Con Git recuperarlo es un comando. El portátil se fue a la basura y tenías el proyecto sincronizado con un remoto: tu trabajo sigue allí. Rompiste el login tocando otra cosa y no sabes qué cambió: Git te dice exactamente qué líneas se modificaron y cuándo.

Paralelismo. Trabajar sin pisarte. Tú haces tu feature en tu rama. Tu compañero hace la suya en la suya. Ninguno toca el código del otro hasta que ambos decidís juntarlo. Cuando lo juntáis, Git os avisa si hay conflicto y os da herramientas para resolverlo.

Auditoría. Saber quién cambió cada línea y por qué. Cada cambio que guardas en Git lleva tu nombre, tu email, la fecha exacta y un mensaje que explica qué hiciste. Dentro de seis meses, cuando alguien pregunte “¿por qué el botón de exportar tiene un setTimeout de 500ms?”, git blame te señala la línea exacta y el commit que la introdujo; con ese identificador, git show te da el mensaje que lo justifica.

Exploración. Probar ideas sin miedo. Creas una rama nueva, haces lo que quieras, rompes todo si te apetece, y si no te gusta el resultado la borras y vuelves a main como si nada hubiera pasado. Tu código principal nunca se toca hasta que tú decides que la idea es buena.

Cada vez que sientas un dolor con el código, pregúntate: ¿es un problema de recuperación, de paralelismo, de auditoría o de exploración? Si ya sabes en qué caja cae, sabes qué herramienta de Git vas a necesitar.

Control de versiones: la categoría de herramienta de la que nadie te habló en el bootcamp

Git no es el único programa que hace estas cuatro cosas. Git pertenece a una categoría de herramientas que se llama sistemas de control de versiones, o VCS por sus siglas en inglés. Si quieres el concepto en profundidad (qué es el control de versiones y por qué existe como categoría), lo desarrollo en qué es el control de versiones. Aquí me basta con que te quedes con la idea.

Un editor de código es una categoría. VS Code, Neovim, Zed y WebStorm son productos distintos dentro de esa categoría. Pues el control de versiones funciona igual: es la categoría, y Git es el producto que casi todo el mundo usa hoy. También existieron otros, como CVS o Subversion, pero eso es historia que no necesitas para arrancar.

Lo que sí necesitas entender es la diferencia entre los dos grandes tipos de control de versiones: el centralizado y el distribuido. Porque esa diferencia explica por qué Git se comporta como se comporta.

Centralizado vs distribuido: por qué Git funciona hasta sin WiFi

En un sistema centralizado, hay un único servidor que guarda el historial completo del proyecto. Todos los developers se conectan a ese servidor para ver qué ha pasado, para guardar sus cambios y para recuperar versiones anteriores. El servidor es la fuente única de verdad. Si el servidor se cae, el equipo entero se queda sin acceso al historial. Si el servidor pierde los datos, el proyecto pierde su memoria.

En un sistema distribuido, como Git, cada developer tiene una copia completa del historial en su propio ordenador. El historial no vive en un servidor: vive en tu portátil, en el mío y en una copia compartida que usamos para sincronizarnos. Esa copia compartida se llama remoto y no es más que otra copia del proyecto viviendo en otro ordenador, normalmente en GitHub o GitLab.

Las consecuencias de esta diferencia son enormes:

• Sin conexión no estás bloqueado. Como el historial está en tu máquina, puedes hacer commits, ver el log, viajar atrás en el tiempo y crear ramas sin WiFi. El remoto solo lo necesitas cuando quieras sincronizar tu trabajo con el del resto del equipo.

• No hay punto único de fallo. Si el servidor de GitHub se cae (pasa), tu trabajo no se pierde. Cuando vuelva, sincronizas. Si el portátil de un developer se rompe, los demás tienen el historial completo y pueden reconstruir lo que faltaba.

• Cada copia es un backup. Si hay tres developers en el equipo y cada uno ha hecho git clone, hay al menos cuatro copias completas del historial del proyecto: los tres portátiles más el remoto. Un incendio en la oficina no borra el proyecto.

Esto no es teoría. Es parte de por qué existe Git. En 2005, el kernel de Linux se desarrollaba con una herramienta llamada BitKeeper, propiedad de una empresa privada. Cuando esa empresa retiró la licencia gratuita, Linus Torvalds se quedó sin manera de coordinar a una comunidad enorme de developers repartidos por todo el mundo. Así que construyó Git en cuestión de días: distribuido desde el minuto cero, libre, y pensado para equipos donde nadie depende de un único servidor ni de una única empresa.

Hasta aquí el modelo mental. Y el modelo mental es justo lo que te deja dirigir Git con criterio en vez de pelearte con él a ciegas. Si prefieres aprenderlo haciendo, con simulaciones interactivas en vez de leyendo y corrigiendo tus propios errores paso a paso, eso es justo lo que construimos en el curso Git: de cero a profesional. Este artículo cubre el primer bloque; el curso te lleva hasta ramas, merges y trabajo en equipo sin que te dé miedo tocar nada.

Vale, me has convencido. ¿Cómo lo instalo?

Tres caminos, mismo final. Elige el tuyo:

macOS. Si tienes Homebrew instalado, abre el terminal y escribe:

brew install git

Si no tienes Homebrew, instalar Git desde el instalador oficial de git-scm.com también funciona. O si prefieres, macOS incluye una versión de Git que se activa la primera vez que ejecutas git en el terminal: el sistema te ofrecerá instalar las Command Line Tools.

Windows. Descarga el instalador desde git-scm.com. Durante la instalación, acepta las opciones por defecto. El instalador incluye Git Bash, un terminal que te da acceso a los comandos de Git en Windows.

Linux. Desde el gestor de paquetes de tu distribución:

# Debian/Ubuntu
sudo apt install git

# Fedora
sudo dnf install git

# Arch
sudo pacman -S git

Independientemente de tu sistema, verifica que todo funciona con un solo comando:

git --version

Si ves algo como git version 2.45.0 o similar, Git ya vive en tu ordenador. Ese número es tu primer hito: ya no hay vuelta atrás.

Si en lugar de eso ves command not found, algo falló en la instalación. Repite el paso anterior. Es raro que falle si seguiste las instrucciones. Si falla, el mensaje de error te dirá exactamente qué buscar en Google: no te asustes, es normal.

Dile a Git quién eres

Git está instalado, pero no sabe quién eres. Y necesita saberlo porque cada cambio que guardes a partir de ahora llevará tu nombre y tu email. Es la forma que tiene Git de responder a la pregunta “¿quién hizo esto y cuándo?” dentro de seis meses.

Son dos líneas. Literalmente dos:

git config --global user.name "Alex Ramos"
git config --global user.email "alex@taskflow.dev"

Sustituye el nombre y el email por los tuyos. Las comillas son importantes: pon tu nombre y tu email dentro de ellas.

El comando tiene cuatro piezas. Entenderlas te ahorra confusión cuando dentro de unos días necesites cambiar algo:

• git config ajusta cómo se comporta Git en tu ordenador; actúa sobre la configuración, no sobre un repositorio concreto.
• --global es el alcance. Significa “esto aplícalo a todos los proyectos de este ordenador, no solo a la carpeta en la que estoy ahora”.
• user.name y user.email son las propiedades concretas que estás configurando. Fíjate en el punto: user.name, no username.
• "Alex Ramos" y "alex@taskflow.dev" son los valores que asignas a esas propiedades.

Siempre es la misma forma: git config --global <propiedad> "<valor>". Cambias la propiedad, cambias lo que estás ajustando.

¿Por qué necesita Git tu nombre? Buena pregunta. La respuesta corta es: porque cada commit (cada foto del proyecto que guardes) va firmado. La respuesta larga la vas a entender cuando lleves una semana trabajando con Git y mires hacia atrás y veas tu nombre en cada cambio. Ese historial es tu currículum silencioso.

Tu primer repositorio: init, add, commit

Tienes Git instalado. Git sabe quién eres. Es el momento de crear tu primer repositorio y guardar tu primer cambio.

Crea una carpeta nueva y entra en ella:

mkdir mi-primer-repo
cd mi-primer-repo

Lo primero es decirle a Git que esta carpeta va a ser un repositorio:

git init

Verás algo como Initialized empty Git repository in /Users/tu-usuario/mi-primer-repo/.git/. Eso significa que Git ha creado una carpeta oculta llamada .git dentro de tu proyecto. Ahí dentro vive todo: el historial, la configuración del repositorio, los punteros. No tienes que tocar esa carpeta nunca. Git lo hace por ti.

Puede que justo encima veas también un aviso que empieza por hint: sobre el nombre de la rama por defecto (master). Es solo informativo, no es un error: son las ramas, que las tocamos en otro post. Ignóralo por ahora.

Ahora crea un archivo. El que quieras. Un index.html, un README.md, un hola.py. Por ejemplo:

echo "# Mi primer proyecto con Git" > README.md

Si ejecutas git status, Git te dice la verdad: tienes un archivo nuevo que Git no está siguiendo. Lo llama untracked:

git status
# Untracked files:
#   README.md

Tu terminal mostrará alguna línea más (algo como On branch master, No commits yet y una pista de cómo usar git add). No te preocupes por ellas: lo que importa aquí es que README.md aparece bajo untracked.

Para decirle a Git “este archivo quiero que lo recuerdes”, usas git add:

git add README.md

Lo que acaba de pasar es importante. git add no guarda el archivo. Lo mueve a una zona intermedia que se llama staging area (o index). Es como decir “este archivo va a entrar en la próxima foto”. Puedes añadir varios archivos con git add y ninguno se guarda todavía. Solo los estás seleccionando.

Si vuelves a ejecutar git status, verás que README.md ha pasado de “untracked” a “changes to be committed”.

El último paso es guardar la foto:

git commit -m "Primer commit: añado README"

git commit toma todo lo que está en la staging area y lo convierte en un commit: una foto completa de cómo está el proyecto en este instante. El flag -m te permite escribir el mensaje del commit directamente en la misma línea. El mensaje es para tu yo del futuro: dentro de tres semanas, cuando no recuerdes qué hiciste, ese mensaje te lo va a contar.

Y ya está: acabas de crear tu primer repositorio Git y tu primer commit. Tres comandos: init, add, commit. Si te quedas con ganas de entender qué es exactamente un commit por dentro (por qué es una foto y no un parche, y qué guarda de verdad), lo desmenuzo en qué es un commit en Git.

Antes de seguir, haz tú el commit. No leyéndolo: haciéndolo. Aquí tienes una simulación con Marina, una developer que acaba de salir del bootcamp igual que tú, para que pases por init, add y commit sin tocar tu terminal todavía:

Cargando ejercicio...

¿Ya has hecho tu primer commit ahí arriba? Entonces esto empieza a cobrar sentido. Si quieres que te avise cuando publique la siguiente guía de esta serie, déjame tu correo y te escribo cuando esté lista:

Un concepto nuevo cada semana

Suscribirme

Las tres zonas: working directory, staging area y repository

Hay un concepto que si lo entiendes ahora te ahorra cien confusiones después. Git no ve tu carpeta como una cosa plana. La ve como tres zonas distintas:

• Working directory. Es tu carpeta normal, la que ves en el explorador de archivos. Aquí creas, editas y borras archivos. Git observa esta zona y te dice qué ha cambiado, pero no guarda nada hasta que tú se lo pides.

• Staging area. Es la zona de preparación. Cuando haces git add <archivo>, mueves ese archivo del working directory a la staging area. Es como ponerlo en una bandeja de “esto va en la próxima foto”. Puedes añadir y quitar archivos de esta bandeja tantas veces como quieras antes de hacer la foto.

• Repository. Es donde viven los commits. Cuando haces git commit, todo lo que estaba en la staging area se convierte en una foto completa que Git guarda para siempre en el repository. Cada foto tiene un identificador único y una flecha que apunta a la foto anterior.

El flujo es siempre el mismo: editas en el working directory, seleccionas con git add lo que quieres guardar en la staging area, y guardas la foto con git commit en el repository.

Este modelo de tres zonas es el que te permite decidir qué entra en cada commit. No tienes que guardar todo lo que has tocado. Puedes tocar cinco archivos y decidir que solo dos van en este commit porque los otros tres son parte de otra cosa. Eso se llama staging selectivo, y es una de las cosas que de verdad separa a un usuario avanzado.

Checklist de primeros pasos

• Git está instalado y git --version devuelve un número de versión
• Has configurado git config --global user.name con tu nombre
• Has configurado git config --global user.email con tu email
• Has creado un repositorio con git init en una carpeta de prueba
• Has hecho tu primer git add y git commit con un mensaje que tu yo del futuro pueda entender
• Entiendes la diferencia entre working directory, staging area y repository

Y ahora, ¿qué?

Si has llegado hasta aquí y has hecho tu primer commit, ya no eres alguien que “ha oído hablar de Git”. Eres alguien que lo ha usado. Tienes Git instalado, sabe quién eres, y has guardado tu primera foto del proyecto. Ese es el 20% que te da el 80% del día a día.

Fíjate en el checklist de arriba: son cosas que haces tú solo, en tu carpeta, sin nadie más. El salto de verdad llega cuando dejas de trabajar solo. ¿Qué pasa cuando sois dos tocando el mismo proyecto? ¿Cómo mandas tu trabajo a GitHub sin pisar el de tu compañero? ¿Qué haces cuando dos cambios chocan? Ahí es donde entran las ramas, el push/pull y los merges, y todo eso se apoya en las tres zonas que acabas de entender.

Ese segundo salto, de trabajar solo a moverte con soltura en un repo de equipo, es justo lo que recorremos, simulación a simulación y sin sudores fríos, en Git: de cero a profesional. Corto, visual, y pensado para que salgas sabiendo dirigir Git en lugar de memorizar comandos. Si este artículo te ha hecho clic, el curso es el siguiente paso natural.

Preguntas Frecuentes

¿Git y GitHub son lo mismo?

No. Git es la herramienta de control de versiones que vive en tu ordenador. GitHub es una plataforma web donde puedes almacenar una copia de tu repositorio para compartirla con otros o para tener un backup externo. Puedes usar Git sin GitHub perfectamente. De hecho, Git funcionaba años antes de que GitHub existiera. La confusión viene de que GitHub es tan popular que mucha gente aprende las dos cosas a la vez y las mezcla. Piensa en Git como el coche y en GitHub como el garaje donde lo aparcas. El coche funciona sin garaje. Si esta confusión te ha mordido alguna vez, la aclaro entera en Git vs GitHub: qué los diferencia.

¿Cada cuánto debería hacer commit?

Cada vez que termines una unidad lógica de trabajo. No cada hora. No cada línea. Cuando hayas hecho un cambio que tiene sentido por sí mismo: “añado validación del formulario de login”, “corrijo el color del header”, “extraigo la función de formateo de fechas a un helper”. Un commit debe ser una sola cosa. Si el mensaje del commit necesita la palabra “y”, probablemente deberían ser dos commits.

¿Qué diferencia hay entre git add . y git add <archivo>?

git add . añade todo lo que ha cambiado en la carpeta actual y sus subcarpetas a la staging area. Es rápido pero impreciso: estás metiendo en la foto todo lo que has tocado, incluidos archivos que igual no querías guardar todavía. git add <archivo> te deja elegir archivo por archivo qué entra en el próximo commit. El primero lo usas cuando sabes exactamente qué has tocado y quieres que todo vaya junto. El segundo lo usas cuando has tocado cosas de funcionalidades distintas y quieres separarlas en commits diferentes. Con la práctica, el segundo se convierte en tu opción por defecto.

¿Puedo deshacer un commit?

Sí. Git tiene varias herramientas para deshacer cosas, desde git restore para archivos sueltos hasta git reset para commits enteros. Pero ese es tema para otro post. Por ahora quédate con esto: casi nada de lo que haces en Git es realmente irreversible. Siempre hay un camino de vuelta, incluso cuando crees que has roto todo.

¿Necesito internet para usar Git?

No. Todo lo que hemos hecho en este post (init, add, commit, ver el historial, deshacer cambios) funciona sin conexión. Solo necesitas internet cuando quieras sincronizar tu trabajo con un remoto (GitHub, GitLab) mediante git push o git pull. Hasta entonces, Git vive completamente en tu ordenador y el historial completo del proyecto está ahí dentro de la carpeta .git.