Módulo 1: Qué problema resuelve Git y el control de versiones

Unidad: GIT-01
Nivel: inicial · Capa: tronco (Arranque) · Duración orientativa: 45 minutos
Estado editorial: listo

Ficha docente

  • Público: alumnado de DAW, DAM, ASIR y grados de informática, con primeros proyectos.
  • Itinerario: curso troncal; precede a instalación, configuración y al modelo de working tree, staging area y repositorio.
  • Prerrequisitos: manejo básico de archivos, carpetas y terminal.
  • Objetivo de aprendizaje observable: explicar qué problema resuelve un sistema de control de versiones (VCS), diferenciar un VCS centralizado de uno distribuido e identificar qué aporta Git sin confundirlo con GitHub o GitLab.
  • Fuente técnica: documentación oficial de Git: About Version Control.

1. El problema: archivos con nombres cada vez menos fiables

Imagina un proyecto con estos archivos:

web-final.html
web-final-bueno.html
web-final-bueno-ahora-si.html
web-final-bueno-ahora-si-2.html

Copiar carpetas parece sencillo, pero pronto aparecen preguntas difíciles:

  • ¿Qué cambió entre dos versiones?
  • ¿Cuál era la versión que funcionaba?
  • ¿Quién modificó una línea y cuándo?
  • ¿Cómo recuperamos una versión anterior sin perder el trabajo actual?
  • ¿Cómo trabajamos varias personas sin sobrescribirnos?

Un sistema de control de versiones o VCS (Version Control System) registra los cambios de uno o varios archivos a lo largo del tiempo. Permite consultar versiones anteriores, comparar cambios y recuperar estados del proyecto.

Git no sustituye las copias de seguridad de todo el equipo, pero sí conserva un historial estructurado del proyecto y facilita recuperar trabajo versionado.

2. Qué aporta Git

Git es un VCS distribuido. Su unidad básica de historial será el commit, que estudiarás más adelante: una versión registrada del proyecto con autoría, fecha y mensaje.

Con Git podrás:

  • guardar puntos reconocibles de la evolución del proyecto;
  • comparar el contenido entre versiones;
  • saber qué cambió y consultar el historial local;
  • crear líneas de trabajo separadas mediante ramas;
  • colaborar y sincronizar repositorios con otras personas.

Git funciona en tu ordenador. Un servicio como GitHub, GitLab o Bitbucket puede alojar repositorios remotos y añadir funciones de colaboración, pero no es Git ni es necesario para empezar a usarlo.

3. VCS local, centralizado y distribuido

Modelo Dónde está el historial Consecuencia principal
Copias manuales En carpetas con nombres elegidos a mano Es fácil confundir versiones o sobrescribir archivos.
VCS centralizado Principalmente en un servidor central Facilita una administración central, pero el servidor es un punto crítico para colaborar y registrar cambios.
VCS distribuido, como Git Cada clon contiene el historial del repositorio Puedes consultar el historial y hacer commits locales sin conexión; después puedes sincronizar con un remoto.

“Distribuido” no significa “sin servidor”. Muchos equipos usan un remoto compartido, pero cada clon conserva su propio repositorio e historial. Tampoco significa que cualquier copia local sustituya por sí sola a una política de copias de seguridad.

4. Demostración breve: un repositorio existe en tu equipo

Esta demostración solo sirve para observar qué es un repositorio local. Los comandos se trabajarán con detalle en lecciones posteriores.

Desde una carpeta vacía:

git init --initial-branch=main demo-vcs
cd demo-vcs
git status

Salida esperada, con posibles diferencias menores según la versión de Git:

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Qué ha cambiado:

Lugar Cambio
Directorio de trabajo Se ha creado la carpeta demo-vcs; aún no contiene archivos del proyecto.
Repositorio local Git ha creado el directorio oculto .git, donde guardará su información e historial.
Área de preparación e historial Aún no hay archivos preparados ni commits.
Remoto No ha cambiado nada: no hay ningún remoto configurado.

El resultado muestra una idea clave: un repositorio Git puede existir y registrar historial localmente antes de conectarse a una plataforma o a Internet.

5. Errores frecuentes

  • “Git y GitHub son lo mismo.”
    Git es la herramienta de control de versiones; GitHub es una plataforma que puede alojar repositorios Git y ofrecer colaboración adicional.

  • “Git guarda automáticamente cada cambio.”
    No. Más adelante decidirás qué cambios preparar y cuándo registrarlos en un commit.

  • “Un repositorio remoto es obligatorio.”
    No. Git permite trabajar y crear historial local sin remoto.

  • “Puedo borrar los archivos y recuperarlo todo siempre.”
    Solo se puede recuperar con Git aquello que se haya incorporado previamente a su historial. Un archivo nunca registrado no está protegido por Git.

6. Ejercicio práctico

Un equipo mantiene una aplicación para reservar aulas. Una compañera corrige un error, otra modifica los estilos y, antes de entregar, alguien borra una parte que funcionaba.

Responde en tres o cuatro frases:

  1. ¿Qué problemas tendría el equipo si guardara copias manuales con nombres como app-final-3?
  2. Indica dos ventajas de usar un VCS.
  3. Explica por qué Git puede seguir siendo útil aunque el equipo todavía no use GitHub o GitLab.
  4. ¿Qué modelo describe mejor a Git: centralizado o distribuido? Justifica la respuesta.

Criterios de revisión

  • Identifica al menos dos problemas reales de las copias manuales.
  • Diferencia Git de una plataforma de alojamiento.
  • Indica que Git conserva un historial local y que un clon contiene el repositorio.
  • No afirma que Git guarde automáticamente todos los archivos ni que sea una copia de seguridad total.

7. Resumen

Al terminar esta lección debes saber explicar que:

  • un VCS registra la evolución de archivos y permite consultar, comparar y recuperar versiones;
  • Git es un VCS distribuido;
  • cada repositorio local puede conservar historial;
  • GitHub y GitLab son servicios externos que pueden alojar repositorios Git, no requisitos para usar Git;
  • Git solo puede recuperar contenido que haya sido incorporado previamente a su historial.

Siguiente lección: GIT-02 · Instalación y configuración.

Registro de revisión técnica

Revisado el 4 de agosto de 2026. Se ha reproducido la demostración desde una ubicación temporal con git init --initial-branch=main demo-vcs y git status: se crea .git, HEAD apunta a main, no hay archivos preparados ni commits y no se configura ningún remoto. También se ha verificado la explicación de VCS centralizado y distribuido frente a la documentación oficial de Git.