Qué es Git: guía desde cero del control de versiones

Si estás empezando en el desarrollo de software, Git es probablemente la primera herramienta que deberías aprender después del lenguaje de programación. Y también es de las que más confusión genera al principio.

En este artículo vas a ver qué es Git, en qué se diferencia de GitHub —que no son lo mismo—, cómo funciona su flujo de trabajo y los comandos que necesitas para empezar hoy.

Qué es Git

Git es un sistema de control de versiones distribuido y de código abierto. Su función principal es permitir a los desarrolladores gestionar proyectos de forma colaborativa y controlar las distintas versiones del código fuente a lo largo del tiempo.

Fue creado por Linus Torvalds en 2005 para el desarrollo del kernel de Linux, y desde entonces se convirtió en el estándar mundial para el control de versiones.

Dicho en simple: Git guarda fotografías de tu proyecto en el tiempo. Cada vez que terminas algo, tomas una foto. Si mañana rompes el código, puedes volver a cualquier foto anterior y ver exactamente qué cambió, cuándo y quién lo hizo.

Eso significa dos cosas que cambian la forma de trabajar:

• Puedes experimentar sin miedo. Si sale mal, vuelves atrás.
• Dejas de tener carpetas llamadas proyecto_final, proyecto_final_v2 y proyecto_final_este_si.

Es recomendable utilizar Git desde la línea de comandos, más aún si eres desarrollador de software, ya sea a través de la Terminal en Linux o macOS, o mediante Git Bash en Windows. No solo da una experiencia más completa: te obliga a entender qué hace cada comando en vez de apretar botones.

Git no es GitHub

Esta es la confusión más frecuente de quien empieza, así que vale la pena aclararla antes de seguir.

Git es el programa que se instala en tu computadora y lleva el control de versiones. Funciona sin internet.

GitHub es un sitio web donde puedes guardar una copia de tus repositorios de Git para respaldarlos y compartirlos. Es un servicio, y no es el único: existen también GitLab y Bitbucket.

La analogía que más ayuda: Git es el procesador de texto y GitHub es la nube donde guardas los documentos. Puedes usar Git toda tu vida sin GitHub. Lo que no puedes es usar GitHub sin Git.

Cómo funciona Git: los tres estados

Aquí está la idea que, una vez que la entiendes, hace que todos los comandos tengan sentido. Un archivo en Git pasa por tres lugares:

1. El directorio de trabajo. Es tu carpeta de siempre, donde editas los archivos.

2. El área de preparación (staging). Una antesala donde eliges qué cambios van a entrar en la próxima foto. Este paso intermedio es lo que confunde al principio, pero es justamente lo que te permite guardar solo una parte de lo que tocaste.

3. El repositorio local. Donde quedan guardadas las fotos, que en Git se llaman commits.

Y hay un cuarto lugar opcional: el repositorio remoto, la copia que vive en GitHub o similar.

El flujo diario es siempre el mismo: editas archivos, eliges cuáles guardar, guardas con un mensaje, y subes.

Comandos esenciales para empezar

Configuración inicial

Se hace una sola vez por computadora. Git firma cada commit con estos datos:

git config --global user.name "Tu Nombre"
git config --global user.email "tu@correo.com"

Empezar un proyecto

Para crear un repositorio nuevo en una carpeta:

git init

O para bajar uno que ya existe:

git clone https://github.com/usuario/proyecto.git

El ciclo de trabajo diario

Estos cuatro son el 90 % de lo que vas a usar:

git status
git add .
git commit -m "Agrega el formulario de contacto"
git push

• git status te dice qué cambió. Cuando tengas dudas, es siempre el primer comando.
• git add . prepara todos los cambios. Si quieres solo uno: git add ruta/al/archivo.
• git commit -m guarda la foto con un mensaje que la describe.
• git push sube tus commits al repositorio remoto.

Y para traer lo que otros subieron:

git pull

Ver qué pasó

git log --oneline

Te muestra el historial en una línea por commit. Es la forma más rápida de ubicarte en un proyecto que no tocas hace meses.

Sobre los mensajes de commit

Un detalle pequeño que separa a quien usa Git de quien lo padece: el mensaje del commit se escribe para tu yo del futuro.

git commit -m "cambios" no le sirve a nadie. Dentro de seis meses, buscando dónde se rompió algo, vas a tener veinte commits que dicen «cambios» y ninguna pista.

Escribe qué hace el cambio, en presente y en una línea: «Corrige el cálculo del total con descuento», «Agrega validación al formulario de registro». Toma tres segundos más y ahorra horas.

Las ramas: para qué sirven de verdad

Una rama (branch) es una línea de trabajo paralela. Te permite desarrollar una funcionalidad nueva sin tocar el código que hoy está funcionando.

git switch -c nueva-funcionalidad

Ese comando crea la rama y te cambia a ella. En proyectos más antiguos vas a ver la forma clásica, que hace lo mismo:

git checkout -b nueva-funcionalidad

Trabajas ahí, haces tus commits, y cuando está listo lo unes a la rama principal:

git switch main
git merge nueva-funcionalidad

Por qué importa: sin ramas, todo el equipo edita la misma línea de código y cualquier trabajo a medio terminar bloquea a los demás. Con ramas, cada uno avanza por su lado y se integra cuando corresponde.

Las cuatro ventajas más importantes de usar Git

1. Control y seguimiento preciso de los cambios. Sabes exactamente qué se modificó en el código fuente, cuándo y por parte de quién. Esto permite detectar errores con mucha más facilidad y retroceder a versiones anteriores para corregir problemas.

2. Cada quien trabaja sin pisar al otro. Git permite compartir el código con todo el equipo, y cada miembro cuenta con una copia local completa del repositorio. Así, cada desarrollador avanza en sus tareas de forma local sin afectar el trabajo de los demás.

3. Herramientas para resolver conflictos. Cuando dos personas modifican lo mismo, Git te muestra exactamente dónde chocan los cambios y te permite decidir con cuál quedarte. Eso asegura una integración fiable de los aportes individuales y mantiene la coherencia del código.

4. Se integra con las plataformas en línea. Funciona de forma nativa con GitHub, GitLab y Bitbucket, lo que simplifica la colaboración, el seguimiento de los proyectos compartidos y la interacción con otros desarrolladores.

Errores comunes al empezar

• Subir contraseñas o claves al repositorio. Es el error más caro de todos. Una vez que algo entra al historial, queda ahí aunque después lo borres. Usa un archivo .gitignore desde el primer día.
• Subir la carpeta de dependencias. node_modules o vendor no van al repositorio: se reconstruyen con un comando.
• Hacer un solo commit gigante al final del día. El valor de Git está en poder volver a un punto concreto, y eso se pierde si todo el día es un solo punto.
• No hacer git pull antes de empezar. Si trabajas en equipo y arrancas sobre una versión vieja, el conflicto está garantizado.
• Creer que hacer commit ya lo respalda. El commit es local. Hasta que no haces push, si se te rompe la computadora perdiste todo igual.

Para cerrar

Git tiene fama de difícil, pero lo que realmente cuesta al principio es entender el modelo: los tres estados, y que lo local y lo remoto son cosas distintas. Con eso claro, los comandos se aprenden solos usándolos.

Y si trabajas solo, no lo descartes pensando que es una herramienta de equipos. El primer beneficio no es colaborar: es poder volver atrás cuando algo se rompe, y tener el proyecto respaldado fuera de tu computadora.

En Norvic Software trabajamos con Git en todos los proyectos, y el código fuente queda a nombre del cliente al terminar. Puedes ver cómo desarrollamos software a medida o todo lo que hacemos. Y si estás empezando en esto, te puede servir qué es un desarrollador web.

Saludos y éxitos.