Git es el sistema de control de versiones más usado del mundo. El Stack Overflow Developer Survey más reciente confirma que más del 93% de los desarrolladores profesionales lo usa en su trabajo diario.
No es una opción entre varias: es el estándar de facto en cualquier equipo de desarrollo de software, desde startups con tres personas hasta proyectos open source con miles de contribuidores.
Sin Git, el desarrollo en equipo sería caótico: no habría forma de saber qué cambió, quién lo cambió ni cuándo. No habría forma de trabajar en paralelo en distintas funcionalidades sin pisar el trabajo de los compañeros. No habría forma de revertir un bug que rompió producción a las 2 de la mañana.
Esta guía explica qué es Git, cómo funciona su modelo de datos, los comandos que todo programador debe dominar y por qué es imprescindible entenderlo antes de escribir la primera línea de código en un entorno profesional.
Qué es Git
Git es un sistema de control de versiones distribuido (DVCS) de código abierto creado por Linus Torvalds en 2005. Torvalds lo desarrolló para gestionar el desarrollo del kernel de Linux, que en ese momento tenía miles de contribuidores y necesitaba un sistema que funcionara de forma eficiente sin depender de un servidor central.
Un sistema de control de versiones registra todos los cambios realizados en los archivos de un proyecto a lo largo del tiempo. Con ese historial, es posible volver a cualquier versión anterior, comparar cambios entre versiones, saber quién modificó qué y cuándo, y fusionar el trabajo de múltiples personas que han estado trabajando en paralelo.
La característica que diferencia a Git de los sistemas de control de versiones anteriores (como SVN o CVS) es que es distribuido. Cada desarrollador tiene una copia completa del repositorio, incluyendo todo el historial, en su ordenador.
No se depende de un servidor central para trabajar: los commits, las ramas y las consultas al historial funcionan localmente. El servidor (GitHub, GitLab, Bitbucket) es simplemente el punto de sincronización entre los miembros del equipo, no el lugar donde vive el proyecto.
Cómo funciona Git: las tres etapas
El concepto más importante para entender Git es el modelo de tres etapas por el que pasan los cambios antes de convertirse en parte permanente del historial.
| Etapa | Qué es | Comando de transición |
|---|---|---|
| Working Directory | Los archivos del proyecto en tu ordenador. Aquí es donde editas el código. | git add → mueve al Staging Area |
| Staging Area | El área de preparación. Aquí seleccionas qué cambios incluirás en el próximo commit. | git commit → confirma en el Repository |
| Repository | El historial permanente de commits. Cada commit es una instantánea del proyecto. | git push → sube al repositorio remoto |
El Staging Area es el concepto que más confunde a quien empieza con Git. ¿Por qué hay una etapa intermedia entre editar y confirmar? Porque permite seleccionar exactamente qué cambios incluir en un commit aunque hayas editado varios archivos.
Puedes haber modificado cinco archivos pero querer hacer dos commits separados: uno con los cambios de la funcionalidad A y otro con los de la funcionalidad B. El Staging Area hace eso posible.
Qué es un commit
Un commit es la unidad básica del historial en Git. Es una instantánea completa del estado de todos los archivos del proyecto en un momento determinado.
Cada commit tiene:
- Hash SHA-1: identificador único de 40 caracteres que identifica inequívocamente ese commit en el historial.
- Autor y fecha: quién hizo el commit y cuándo.
- Mensaje: descripción del cambio. Es la documentación del historial del proyecto.
- Referencia al commit anterior: cada commit apunta al commit que le precede, formando la cadena del historial.
# Ver el historial de commits
git log
# Salida típica:
# commit a3f5c8e9d2b14f7a6c0e1d3b5f8a2c4e6d8f0b2a
# Author: Luis García
# Date: Mon Jun 2 10:25:00 2025 +0200
#
# Añade validación de formulario de contacto
# Vista compacta del historial
git log --oneline La calidad de los mensajes de commit importa. Un historial con mensajes claros («Corrige bug en cálculo de IVA en facturas internacionales») es documentación del proyecto. Un historial con mensajes vagos («fix», «changes», «wip») no aporta información útil cuando hay que entender por qué se tomó una decisión hace seis meses.
Ramas en Git: desarrollo en paralelo
Las ramas son la funcionalidad que hace de Git una herramienta para trabajar en equipo de forma eficiente. Una rama es una línea de desarrollo independiente: puedes trabajar en una funcionalidad nueva sin afectar al código principal, y fusionarla de vuelta cuando esté lista.
# Ver las ramas disponibles
git branch
# Crear una rama nueva
git branch feature/login
# Crear una rama y cambiar a ella directamente
git checkout -b feature/login
# o con la sintaxis moderna:
git switch -c feature/login
# Cambiar a otra rama
git checkout main
git switch main
# Fusionar una rama en la rama actual
git merge feature/login
# Eliminar una rama ya fusionada
git branch -d feature/loginEl flujo de trabajo más extendido en equipos profesionales es GitHub Flow o GitFlow. En GitHub Flow, la rama main siempre contiene código desplegable en producción. Cada nueva funcionalidad se desarrolla en una rama separada, se revisa con un pull request y se fusiona a main cuando está aprobada. Ese flujo garantiza que el código en producción es siempre estable.
Comandos esenciales de Git
| Comando | Qué hace |
|---|---|
git init |
Inicializa un repositorio Git en el directorio actual |
git clone URL |
Descarga una copia completa de un repositorio remoto |
git status |
Muestra el estado de los archivos (modificados, en staging, sin seguimiento) |
git add archivo |
Añade un archivo al Staging Area |
git add . |
Añade todos los archivos modificados al Staging Area |
git commit -m "mensaje" |
Confirma los cambios del Staging Area en el repositorio local |
git push origin main |
Sube los commits locales al repositorio remoto |
git pull |
Descarga y fusiona los cambios del repositorio remoto |
git fetch |
Descarga cambios del remoto sin fusionar automáticamente |
git branch -b nombre |
Crea una rama nueva y cambia a ella |
git merge rama |
Fusiona la rama indicada en la rama actual |
git log --oneline |
Muestra el historial de commits en formato compacto |
git diff |
Muestra los cambios entre el Working Directory y el Staging Area |
git stash |
Guarda temporalmente los cambios no commiteados para limpiar el Working Directory |
La diferencia entre Git y GitHub
Es la confusión más frecuente cuando alguien empieza con control de versiones. Son dos cosas distintas aunque están íntimamente relacionadas.
Sistema de control de versiones que se instala en tu ordenador. Gestiona el historial del código localmente. Funciona sin conexión a internet. Es el motor del control de versiones. Creado por Linus Torvalds en 2005. Código abierto.
Plataforma web de Microsoft que aloja repositorios Git en la nube. Añade colaboración: pull requests, issues, GitHub Actions (CI/CD), revisión de código y control de acceso. No es el único: GitLab y Bitbucket son alternativas populares.
Se puede usar Git sin GitHub: trabajar localmente con un repositorio Git sin subirlo a ningún servidor. No se puede usar GitHub sin Git: GitHub es simplemente un servidor remoto donde se aloja un repositorio Git.
El flujo de trabajo típico con Git en un equipo
Entender los conceptos individuales es importante, pero lo que realmente marca la diferencia es entender cómo se combinan en un flujo de trabajo de equipo real.
# 1. Clonar el repositorio del proyecto
git clone https://github.com/empresa/proyecto.git
# 2. Crear una rama para la nueva funcionalidad
git switch -c feature/nueva-funcionalidad
# 3. Hacer cambios en el código...
# 4. Ver qué ha cambiado
git status
git diff
# 5. Añadir al Staging Area
git add .
# 6. Confirmar el commit con mensaje descriptivo
git commit -m "Añade formulario de contacto con validación"
# 7. Subir la rama al repositorio remoto
git push origin feature/nueva-funcionalidad
# 8. Abrir un Pull Request en GitHub para que el equipo revise
# (esto se hace en la interfaz web de GitHub)
# 9. Tras la revisión y aprobación, merge a main
git switch main
git merge feature/nueva-funcionalidad
# 10. Actualizar la copia local con los cambios del equipo
git pull origin mainEl .gitignore: qué archivos no debe rastrear Git
No todos los archivos de un proyecto deben estar en el repositorio Git. El archivo .gitignore le dice a Git qué archivos y directorios debe ignorar.
Los candidatos habituales al .gitignore son: las dependencias instaladas (node_modules/, venv/), los archivos de entorno con credenciales (.env), los archivos de configuración del IDE (.vscode/, .idea/), los archivos compilados (dist/, build/) y los archivos temporales del sistema operativo (.DS_Store en macOS).
# .gitignore típico para un proyecto Node.js
node_modules/
.env
.env.*
dist/
build/
.DS_Store
*.log
coverage/GitHub mantiene una colección de plantillas de .gitignore para los lenguajes y frameworks más comunes en github.com/github/gitignore.
Por qué Git es imprescindible para cualquier programador
Git no es una herramienta avanzada para perfiles senior. Es la herramienta básica de trabajo de cualquier desarrollador desde el primer día. Las razones concretas por las que ningún equipo profesional trabaja sin Git son directas.
Historial completo del proyecto. Saber exactamente qué cambió, quién lo cambió y por qué. Cuando un bug aparece en producción, el historial de commits permite identificar en qué commit se introdujo y revertirlo sin perder el trabajo posterior.
Trabajo en equipo sin conflictos. Múltiples desarrolladores pueden trabajar en el mismo proyecto simultáneamente en ramas distintas, sin pisar el trabajo de los demás. Las herramientas de merge y rebase de Git resuelven la mayoría de los conflictos automáticamente.
Experimentación sin riesgo. Crear una rama para probar algo nuevo significa que el código principal no se toca. Si el experimento no funciona, se elimina la rama. Si funciona, se fusiona.
Base de CI/CD y DevOps. Los pipelines de integración continua (GitHub Actions, Jenkins, GitLab CI) se disparan por eventos de Git: un push a main, la apertura de un pull request o la creación de un tag. Sin Git no hay pipeline. Y sin pipeline no hay despliegue automatizado.
Lo que el mercado espera de cualquier desarrollador que busca su primer empleo es que use Git con fluidez. Es parte del perfil del que habla el artículo sobre qué buscan las empresas en un desarrollador, y una de las habilidades mencionadas como imprescindibles para convertirse en programador profesional en las 13 verdades de convertirse en programador.
Esther llegó al Bootcamp DevOps de KeepCoding sin base técnica previa. Git fue una de las primeras herramientas que aprendió en el programa, junto con Docker y Linux. No lo vio como una herramienta más: lo entendió como el lenguaje que habla cualquier equipo de desarrollo profesional.
Hoy trabaja como DevOps Engineer en un proyecto bancario de gran escala donde gestiona pipelines de CI/CD basados en Git, Docker y Kubernetes. Lo que más valoró fue aprender con proyectos reales desde el primer módulo, no con ejercicios desconectados del mercado.
Cómo aprender Git de forma efectiva
Git se aprende usándolo, no leyendo sobre él. La forma más rápida es inicializar un repositorio en cualquier proyecto personal, aunque sea pequeño, y empezar a hacer commits reales desde el primer día de aprendizaje.
Para quien quiere aprender Git en el contexto de un proyecto web completo con HTML, CSS, JavaScript y herramientas profesionales, el Full Stack Web Bootcamp de KeepCoding lo cubre desde los fundamentos hasta el flujo de trabajo en equipo con GitHub y CI/CD.
Conclusión
Git es la herramienta de control de versiones más usada del mundo y el estándar en cualquier equipo de desarrollo profesional. Entender su modelo de tres etapas (Working Directory, Staging Area, Repository), dominar los comandos esenciales y saber trabajar con ramas y pull requests son habilidades que cualquier programador necesita desde el primer día en un entorno real. Full Stack Web Bootcamp de KeepCoding.
La diferencia entre Git (la herramienta) y GitHub (la plataforma) es fundamental para entender cómo encaja cada una en el flujo de trabajo. Git gestiona el historial local; GitHub lo aloja en la nube y añade la capa de colaboración. Los dos juntos son la base sobre la que se construyen los pipelines de CI/CD y los flujos de trabajo DevOps modernos.
Git no es una habilidad avanzada: es la habilidad básica de cualquier desarrollador. Aprenderla bien desde el principio evita meses de trabajo con malos hábitos que después cuestan tiempo corregir.
La referencia técnica más completa sobre Git, con documentación de todos los comandos y guías de flujos de trabajo avanzados, está en git-scm.com/doc, la documentación oficial mantenida por el equipo de Git.
