¿Qué es Git? Introducción al control de versiones
Le explicamos paso a paso la lógica del control de versiones y los conceptos de commit, branch y merge, con comandos de ejemplo para quien empieza.
Aurora YazılımEquipo editorial
6 min de lectura
Git es un sistema de control de versiones distribuido, gratuito y de código abierto, que registra cada cambio en los archivos. La respuesta corta a qué es Git es esta: guarda paso a paso el historial del proyecto y permite deshacer un cambio erróneo, que varias personas trabajen sobre el mismo código sin pisarse y probar ideas distintas en ramas separadas.
¿Qué es un sistema de control de versiones?
¿Le suena guardar un documento copiándolo como “final”, “final-de-verdad” o “final-este-sí”? Un sistema de control de versiones es la versión ordenada y fiable de ese desorden. Registra cada cambio junto con quién lo hizo, cuándo y por qué.
En el software, este registro es vital. Si una función que ayer funcionaba hoy se ha roto, puede ver los cambios intermedios línea a línea y, si hace falta, volver al estado anterior. A medida que crece el equipo, trabajar sin este orden resulta casi imposible.
Git nació en 2005 para el desarrollo del núcleo de Linux y hoy es la herramienta de control de versiones más utilizada del mundo. La documentación oficial y los enlaces de descarga están en git-scm.com.
¿Para qué sirve Git?
El valor de Git es mucho más que hacer copias de seguridad. Bien usado, reorganiza desde la base la forma de trabajar del equipo.
La diferencia es grande incluso para un desarrollador que trabaja solo. Para probar una idea nueva no hace falta copiar el proyecto; abre una rama, prueba y, si no le gusta, la borra. La versión principal se mantiene siempre limpia y funcional, y el coste de experimentar se reduce casi a cero.
- Guarda el historial: cada punto de guardado es una fotografía del proyecto en ese momento.
- Facilita volver atrás: puede deshacer un cambio erróneo con un solo comando.
- Permite el trabajo en paralelo: cada persona trabaja en su propia rama y luego las fusiona.
- Hace visible la responsabilidad: se sabe quién cambió cada línea y por qué.
- Es distribuido: en el ordenador de cada desarrollador hay una copia completa del proyecto y se puede trabajar sin internet.
- Se conecta con el proceso de publicación: las pruebas y los pasos de puesta en producción pueden automatizarse vinculándolos a ramas concretas.
Conceptos básicos: repositorio, commit, branch
La forma más corta de entender Git es asentar cuatro conceptos. Los comandos se construyen sobre ellos.
Repositorio (repository)
El repositorio es la carpeta que contiene los archivos del proyecto y todo el historial de cambios. Una carpeta oculta .git guarda ese historial. El repositorio de su ordenador se llama local; el de un servidor como GitHub o GitLab, remoto.
¿Qué es un commit?
Un commit es el registro, con una descripción, de los cambios hechos en un momento determinado. Cada commit tiene un identificador único. Un buen commit es pequeño y tiene un solo propósito; su mensaje responde a la pregunta “qué cambió y por qué”.
Área de preparación (staging)
En Git los cambios no se guardan directamente; primero se añaden al área de preparación. Así, de diez archivos que ha modificado a la vez, puede incluir en un único commit solo los tres que están relacionados.
Branch y merge
Una branch (rama) es una línea de trabajo independiente que se separa del código principal. Desarrolla una nueva funcionalidad en una rama aparte y, cuando está lista, la une a la rama principal con merge. Así, un trabajo a medias no rompe la versión que funciona.
Comandos básicos de Git
Una vez instalado Git, la mayor parte del trabajo diario se hace con un puñado de comandos. Para los pasos de instalación, consulte nuestra guía de instalación de Git. Los comandos siguientes funcionan igual en Windows, macOS y Linux.
git --version
git config --global user.name "Su nombre y apellidos"
git config --global user.email "eposta@ornek.com"
mkdir proje && cd proje
git initgit status
git add index.html
git add .
git commit -m "Añadido el título de la página de inicio"
git log --onelinegit switch -c iletisim-formu
# ... haga los cambios y confírmelos con commit ...
git switch main
git merge iletisim-formu
git branch -d iletisim-formugit clone https://github.com/kullanici/proje.git
git pull
git push origin mainUn flujo de trabajo típico con Git
Incluso en un equipo pequeño, el siguiente flujo evita en gran medida la confusión.
- Descargue el código actual: antes de empezar, actualice la rama principal con git pull.
- Cree una rama nueva: una rama distinta para cada funcionalidad o corrección.
- Haga commits pequeños: guarde cada paso lógico con un mensaje descriptivo.
- Envíe la rama al repositorio remoto: comparta su trabajo con git push.
- Pida una revisión: abra un pull request en GitHub o un merge request en GitLab.
- Fusione tras la aprobación: que a la rama principal solo llegue código revisado.
Diferencia entre Git y GitHub
Es la cuestión que más se confunde. Git es una herramienta; funciona en su ordenador y guarda el historial. Servicios como GitHub, GitLab o Bitbucket son plataformas que alojan repositorios Git en internet y añaden revisión, seguimiento de tareas y automatización.
Puede usar Git por su cuenta, sin vincularlo a ninguna plataforma. Pero para el trabajo en equipo y las copias de seguridad, usar un repositorio remoto se ha convertido en la práctica habitual.
| Función | Git | GitHub / GitLab |
|---|---|---|
| Tipo | Herramienta de línea de comandos | Plataforma web |
| Dónde se ejecuta | Ordenador local | Servidor remoto |
| Función principal | Registrar el historial | Compartir y gestionar el repositorio |
| Internet | No es necesario | Es necesario |
| Funciones adicionales | Ramas, fusión, historial | Revisión, tareas, automatización |
.gitignore y un buen mensaje de commit
Todo repositorio debe tener un archivo .gitignore que indique qué no se sigue. En esa lista entran las carpetas de dependencias, los resultados de compilación, los archivos de registro y las variables de entorno. Así el repositorio se mantiene pequeño, los archivos regenerables no inflan el historial y la información secreta no se comparte por error.
El mensaje de commit es una nota que leerá dentro de seis meses. Es costumbre escribir en la primera línea, de unos 50 caracteres, un resumen breve en imperativo: algo como “Corrige el error de redondeo en el total del carrito”. Si hace falta, tras una línea en blanco explique el motivo y el efecto.
Los buenos mensajes no son solo cuestión de orden. Cuando quiera encontrar con qué cambio llegó un error, los comandos git log y git blame le indican directamente el camino; los mensajes descriptivos reducen esa búsqueda a minutos. Acordar un formato de mensaje común en el equipo acelera también la revisión de código.
node_modules/
dist/
.env
*.log
.DS_StoreErrores frecuentes de quienes empiezan
La mayoría de estos errores desaparecen solos con unas semanas de práctica. Lo importante es adquirir desde el primer día el hábito de hacer commits pequeños y descritos.
- Hacer commit de información secreta: las contraseñas y claves de API no deben entrar en el repositorio; añada a .gitignore archivos como .env.
- Commits gigantes: meter el trabajo de una semana en un solo commit dificulta volver atrás.
- Mensajes sin sentido: en lugar de “arreglo” o “asdf”, escriba qué ha cambiado.
- Trabajar directamente en la rama principal: un trabajo a medias puede romper la versión en producción.
- Temer los conflictos: un merge conflict es normal; Git muestra con claridad qué líneas entran en conflicto.
- Añadir carpetas como node_modules: no ponga en el repositorio archivos que se pueden regenerar.
¿Por dónde empezar a aprender Git?
La forma más eficaz es gestionar de principio a fin un proyecto pequeño con Git. Una página HTML sencilla o un pequeño script como los que describimos en nuestro artículo qué es JavaScript bastan para asentar los conceptos.
En el paso siguiente puede montar un proyecto de Node.js y probar juntos los archivos de paquetes, el .gitignore y las ramas. Para la duda de si el código de la interfaz y el del servidor van en el mismo repositorio o en repositorios separados, le orienta nuestro artículo sobre la diferencia entre frontend y backend.
En los proyectos profesionales, Git es la columna vertebral invisible pero imprescindible del trabajo. En Aurora Yazılım, todos los proyectos de diseño web, web corporativa y plataforma e-commerce se llevan con control de versiones; así cada cambio queda trazable y reversible.
Preguntas frecuentes
01¿Hace falta ser programador para aprender Git?
No. Git no sirve solo para código, sino para cualquier archivo basado en texto. También escritores, diseñadores y equipos de documentación usan Git para seguir el historial de cambios.
02¿Es de pago Git?
Git es gratuito y de código abierto. Los servicios de alojamiento como GitHub y GitLab tienen planes gratuitos; para las funciones avanzadas de equipo ofrecen planes de pago.
03¿Cómo deshago un commit?
Para deshacer un commit ya compartido, lo más seguro es usar git revert; no borra el historial, sino que añade un commit inverso. En los cambios locales que aún no ha enviado puede usar git restore o git reset, pero no ejecute reset --hard sin estar seguro de lo que hace.
04¿Por qué se produce un merge conflict?
Cuando en dos ramas se han modificado de forma distinta las mismas líneas del mismo archivo, Git no puede decidir cuál es la correcta. El conflicto se resuelve al editar las secciones marcadas en el archivo y volver a hacer commit.
Git es la memoria de los proyectos de software: guarda cada cambio y facilita deshacer errores y trabajar en equipo. Si quiere que su proyecto se desarrolle con esta disciplina, puede conocer las soluciones de software de Aurora Yazılım, echar un vistazo a nuestro servicio de gestión de velocidad y rendimiento para un sitio rápido y sostenible, o ponerse en contacto con nosotros directamente.
