Crear tu primer repositorio Git desde cero

Llegados a este punto, Git ya no es una idea teórica. Ya sabes qué problema resuelve, ya lo has instalado y ya lo has usado en un proyecto pequeño. Lo que falta ahora es entender con precisión qué ocurre cuando Git empieza a formar parte de un proyecto y cómo se construye, paso a paso, esa historia que hasta ahora solo hemos mencionado.

Un proyecto no nace siendo un repositorio. Se convierte en uno porque alguien toma una decisión consciente. Git no aparece por accidente. Git empieza a funcionar cuando tú decides que un proyecto debe recordar su pasado.

Cuando una carpeta deja de ser solo una carpeta

Antes de usar Git, una carpeta es simplemente un contenedor de archivos. Puedes crear, borrar o modificar contenido, pero todo ocurre en el presente. Si algo se rompe, no existe una referencia clara a estados anteriores. El pasado se diluye.

Cuando inicializas Git en esa carpeta, no cambias el proyecto en sí. Cambias su relación con el tiempo. A partir de ese momento, el proyecto puede tener pasado, presente y futuro diferenciados.

Git no actúa automáticamente. No guarda nada por su cuenta. Se limita a observar y a esperar que seas tú quien marque qué momentos son importantes.

El gesto que lo cambia todo: git init

Ese cambio ocurre con una acción muy concreta y deliberada:

git init

Este comando se ejecuta una sola vez, en la raíz del proyecto. No forma parte del trabajo diario ni se repite constantemente. Es un punto de partida.

Antes de ejecutarlo, Git no existe para ese proyecto. Después de ejecutarlo, Git está presente y atento.

A nivel conceptual, git init significa esto:

“Este proyecto empieza ahora a tener historia”.

No hay efectos visibles llamativos. No aparecen nuevas ventanas ni mensajes espectaculares. Git es discreto por diseño. Su valor no está en lo que muestra, sino en lo que permite hacer a partir de ese momento.

Qué cambia después de inicializar Git

Una vez Git está inicializado, el proyecto entra en un estado nuevo. Los archivos siguen siendo los mismos y el editor no cambia, pero ahora existe una separación clara entre dos planos distintos:

• El estado actual del proyecto, tal como está ahora mismo.
• Los estados del proyecto que decidas guardar como referencias estables.

Git no mezcla ambos planos. El presente existe, pero solo se convierte en pasado cuando tú lo decides.

Para observar cómo ve Git el proyecto en cada momento, existe un comando fundamental:

git status

Este comando no modifica nada. Su función es informarte. Te muestra qué archivos han cambiado y si el proyecto tiene o no estados guardados. Usarlo ayuda a alinear tu percepción con la de Git y a entender qué está ocurriendo realmente.

Un repositorio sin historia: el punto cero

Justo después de ejecutar git init, el proyecto ya es un repositorio, pero todavía no tiene historia. Esto es un punto clave que conviene interiorizar.

• Git está activo.
• La memoria está preparada.
• Pero no hay recuerdos.

Este estado no es un error ni una situación incompleta. Es el punto cero. Un repositorio recién creado es como un cuaderno nuevo: existe, pero aún no se ha escrito nada en él.

Para que exista historia, alguien tiene que empezar a escribirla.

El primer estado guardado y su importancia

El primer estado guardado no suele ser complejo. Normalmente es algo sencillo: un archivo inicial, una estructura mínima o una breve descripción del proyecto. Su valor no está en el contenido, sino en lo que representa.

Guardar el primer estado significa aceptar una idea muy concreta:

“Este es el punto desde el que quiero poder volver”.

El proceso es deliberado. Primero indicas qué cambios forman parte de ese estado:

git add nombre-del-archivo

Después guardas ese estado como un punto estable:

git commit -m "Estado inicial del proyecto"

El mensaje no es un detalle menor. Es la pieza que convierte una secuencia de datos en una historia comprensible. Sin mensajes, Git guarda información. Con mensajes, Git guarda decisiones.

Cómo empieza a crecer la historia del proyecto

A partir del primer commit, el proyecto deja de ser frágil. Ya existe un pasado al que volver. Desde ese momento, el trabajo entra en un ciclo que no cambia, independientemente del tamaño del proyecto o de su complejidad.

• Modificas archivos.
• Git detecta los cambios.
• Decides si ese estado merece ser guardado.
• Guardas un nuevo punto estable.

Ese ciclo se repite una y otra vez. No hay versiones especiales ni atajos ocultos. Git es deliberadamente simple en este aspecto porque quiere que el control esté siempre en tus manos.

Visualizar la evolución del proyecto

Para entender mejor este proceso, ayuda pensar en Git como una línea temporal que se va construyendo poco a poco. Al principio no hay nada. Luego aparece el primer punto estable. Después, nuevos puntos se van añadiendo.

Cada punto representa un estado completo del proyecto. No son archivos sueltos, sino fotografías coherentes de cómo estaba todo en un momento concreto.

También se puede ver el proceso completo desde una perspectiva más conceptual:

Nada avanza sin que tú lo decidas. Git no empuja la historia. La historia existe porque tú marcas qué momentos importan.

Ver la historia que ya existe

Hasta ahora has creado historia. El siguiente paso lógico no es crear más, sino mirar hacia atrás. Git permite recorrer los estados guardados del proyecto y ver cómo ha evolucionado con el tiempo. Para eso existe un comando sencillo:

git log

Este comando no modifica nada. No cambia archivos. No afecta al proyecto. Solo muestra la historia que ya existe. Cada entrada representa un punto estable: un estado completo del proyecto, con su mensaje y su momento en el tiempo. Cuando lo que necesitas es una vista rápida y clara del progreso, una versión resumida suele ser suficiente:

gitlog --oneline

Aquí no buscas detalles técnicos. Buscas comprobar que la historia tiene sentido y que el proyecto avanza de forma ordenada.