Llegas a tu primer proyecto en equipo y alguien dice «haz un pull antes de tocar nada» o «eso súbelo en una rama aparte». Si nunca has usado Git, esas frases suenan a otro idioma. Y sin embargo, es la herramienta que más vas a usar en toda tu carrera como programador, mucho más que cualquier lenguaje concreto.
Git y GitHub no se suelen enseñar bien en ninguna asignatura, y la mayoría de la gente los aprende a golpes, rompiendo cosas. Al terminar esta guía vas a saber instalar Git, guardar y subir tu código sin miedo a perderlo, trabajar en ramas sin liarla, y entender qué significa exactamente cada palabra que te suelten en tu primer equipo.
La ruta que vamos a seguir
- Qué es el control de versiones y por qué lo necesitas aunque trabajes solo
- Git vs GitHub: la confusión que tiene casi todo el mundo
- ¿Por qué prácticamente todas las empresas usan Git?
- Instalar Git y configurarlo por primera vez
- El ciclo que vas a usar el 90% del tiempo
- Ramas: cómo trabajar en algo sin romper lo que ya funciona
- Colaborar en equipo sin liarla
- Errores típicos de principiante
- Qué aprender después
Qué es el control de versiones y por qué lo necesitas aunque trabajes solo
El control de versiones es, en esencia, un historial de todos los cambios que ha tenido tu código, con la posibilidad de volver atrás en cualquier momento. Sin él, la forma de «versionar» un proyecto suele acabar así: proyecto_final.zip, proyecto_final_v2.zip, proyecto_final_v2_DEFINITIVO.zip. Git resuelve exactamente ese problema, y lo resuelve incluso si trabajas completamente solo.
Cada vez que guardas un cambio con Git (a eso se le llama hacer un «commit»), queda un punto al que siempre puedes volver. Si rompes algo y no sabes por qué, puedes comparar tu código actual con el de hace tres días y ver exactamente qué línea lo causó. Eso, para cualquier proyecto de más de una tarde de trabajo, es impagable.
Git vs GitHub: la confusión que tiene casi todo el mundo
Git y GitHub no son lo mismo, aunque casi todo el mundo los usa como sinónimos al principio. Git es el programa que corre en tu ordenador y lleva el historial de cambios. GitHub es una web que aloja copias de esos repositorios en la nube, para que puedas compartirlos, hacer copia de seguridad de ellos y colaborar con otras personas. Podrías usar Git sin GitHub (guardando el historial solo en tu ordenador), pero en la práctica casi nadie lo hace. Dato curioso: podrías usar Git durante toda tu vida sin crear jamás una cuenta en GitHub, son cosas independientes.
| Git | GitHub | |
|---|---|---|
| Qué es | Un programa (software) | Una plataforma web |
| Dónde vive | En tu ordenador | En la nube |
| Para qué sirve | Guardar el historial de cambios | Compartir, respaldar y colaborar |
| Alternativas | Mercurial, SVN | GitLab, Bitbucket |
¿Por qué prácticamente todas las empresas usan Git?
Git no nació como una herramienta para guardar copias de un archivo. Nació para coordinar a cientos de personas trabajando sobre el mismo proyecto sin pisarse el trabajo unas a otras, que es exactamente lo que necesita cualquier empresa de software, por pequeña que sea.
Por eso, en cuanto entras en tu primer proyecto en equipo (una práctica de universidad, unas prácticas en empresa, o tu primer trabajo), Git deja de ser opcional. No lo usan porque sea complicado o «profesional»: lo usan porque sin él, coordinar a más de una persona sobre el mismo código se vuelve caos en cuestión de días.
Instalar Git y configurarlo por primera vez
En Windows se instala descargando el instalador desde la web oficial de Git; en Mac, si tienes Homebrew, basta con brew install git; en Linux normalmente ya viene instalado o se instala con el gestor de paquetes de tu distribución. Una vez instalado, lo primero es decirle quién eres, porque esa información se guarda en cada commit que hagas. Ese correo quedará asociado a todos tus commits, así que si luego quieres que aparezcan bajo tu perfil de GitHub, conviene usar el mismo correo que tengas registrado allí:
git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"
El ciclo que vas a usar el 90% del tiempo
Todo Git se reduce, en el día a día, a un ciclo de tres pasos: guardar cambios en el área de preparación, confirmarlos con un mensaje, y subirlos a GitHub. Si dominas esto, ya sabes usar Git para el 90% de las situaciones reales: modificas un archivo, lo preparas con add, lo confirmas con commit, y lo subes con push. Ese es literalmente todo el ciclo.
git status # qué ha cambiado
git add archivo.py # preparar un cambio concreto
git commit -m "mensaje" # confirmarlo con una descripción
git push # subirlo a GitHubEl mensaje del commit importa más de lo que parece: «cambios» no le dice nada a nadie (ni a tu yo del futuro), mientras que «corrige el cálculo de la media en el informe» sí. Y conviene hacer commits pequeños y frecuentes en vez de uno gigante al final del día: es mucho más fácil depurar un cambio pequeño que uno de cincuenta archivos.
Ramas: cómo trabajar en algo sin romper lo que ya funciona
Una rama (branch) es una copia paralela de tu proyecto donde puedes experimentar sin tocar la versión que ya funciona, normalmente llamada main: es como hacer una fotocopia del proyecto para trabajar sobre ella sin tocar el original. Es la razón por la que puedes probar una funcionalidad nueva a medias, romper cosas temporalmente y seguir teniendo una versión estable disponible en todo momento.
git branch nueva-funcionalidad # crear una rama
git checkout nueva-funcionalidad # cambiarte a ella
git checkout main # volver a la rama principalCuando esa funcionalidad ya funciona bien, se junta («merge») con main. Trabajar siempre directamente sobre main es la forma más rápida de que un fallo a medias termine bloqueando a todo el equipo.
Colaborar en equipo sin liarla
Cuando trabajas con más gente, el flujo típico es: creas tu rama, haces tus cambios, subes esa rama a GitHub y abres un «pull request» pidiendo que se incorpore tu trabajo a main. El resto del equipo puede revisar el código, comentar y pedir cambios antes de aceptarlo. Es exactamente el mismo mecanismo que usan los proyectos de código abierto más grandes del mundo para aceptar contribuciones de miles de personas sin que nadie pueda romper el proyecto directamente.
Antes de empezar a trabajar cada día conviene hacer git pull, que descarga los cambios que el resto del equipo haya subido mientras tú no estabas. Olvidarse de este paso es la causa número uno de los conflictos de fusión («merge conflicts») en cualquier equipo que empieza. Conviene tener claro desde el principio que el objetivo de Git no es evitar los conflictos por completo, sino permitir resolverlos sin perder el trabajo de nadie.
Errores típicos de principiante
El más común es subir por accidente archivos que no deberían estar en el repositorio: claves de API, contraseñas, o carpetas enormes de dependencias como node_modules. La solución es un archivo .gitignore en la raíz del proyecto, donde listas todo lo que Git debe ignorar antes de que llegue a subirse.
El segundo error más común es usar git push --force sin saber lo que hace: sobrescribe el historial remoto con el tuyo, y si alguien más había subido cambios mientras tanto, los borra sin avisar. Como principiante, evita ese comando salvo que sepas exactamente por qué lo necesitas. Los otros dos errores clásicos: hacer un único commit gigante con el mensaje «he terminado todo» en vez de varios pequeños («añadido login», «corregido formulario», «actualizados estilos»), y trabajar siempre directamente sobre main en vez de crear una rama para cada cosa nueva.
Qué aprender después
Con lo visto aquí ya puedes usar Git y GitHub en cualquier proyecto real. El siguiente paso natural es practicar con un proyecto propio (puedes retomar el que empezaste al empezar en programación desde cero), subirlo a GitHub desde el primer día, y acostumbrarte a hacer commits pequeños aunque trabajes solo. Cuando ya domines el ciclo básico, herramientas visuales como GitHub Desktop o la integración de Git que ya trae Visual Studio Code te ahorrarán bastante tiempo de terminal.
La guía oficial de GitHub para principiantes es un buen sitio para profundizar una vez tengas soltura con lo básico, igual que revisar qué lenguaje de programación te conviene aprender si aún no lo tienes claro.
Preguntas frecuentes
¿Git y GitHub son lo mismo?
No. Git es el programa que lleva el historial de cambios en tu ordenador; GitHub es la plataforma web donde alojas esos repositorios para compartirlos y colaborar.
¿Necesito internet para usar Git?
No. Git funciona perfectamente sin conexión: puedes hacer commits, crear ramas y consultar el historial en local. Solo necesitas internet para sincronizar con GitHub (push y pull).
¿Qué es exactamente un commit?
Es una «foto» guardada del estado de tu código en un momento concreto, con un mensaje que describe qué cambió. Es el punto al que siempre puedes volver.
¿Qué pasa si me equivoco al usar Git?
Casi todo tiene solución: como cada commit queda guardado, casi siempre puedes volver a un punto anterior. El único comando realmente peligroso para un principiante es git push --force.
¿GitHub es gratis?
Sí, para repositorios tanto públicos como privados con un uso normal de estudiante. Los planes de pago añaden funciones pensadas para empresas.
Deja una respuesta