git init: crea tu primer repositorio paso a paso

Tienes una carpeta con tu proyecto y quieres empezar a guardar su historia sin miedo a romperla. Buena noticia: no necesitas GitHub todavía, ni una cuenta en ningún sitio, ni internet. Un solo comando convierte esa carpeta en un repositorio Git y en este post te explico qué es git init, tu primer repositorio y cómo llegar hasta tu primer commit sin tocar nada que no debas.

Antes de empezar necesitas dos cosas: tener Git instalado (si al escribir git --version te sale un número, lo tienes) y saber entrar en la carpeta de tu proyecto con cd. Con eso vas sobrado.

¿Qué hace git init exactamente?

git init crea una subcarpeta oculta llamada .git dentro de tu proyecto, y ahí es donde Git guarda toda la historia de tus cambios. No modifica tus archivos, no borra nada y no envía nada a ningún servidor. Tu código sigue exactamente igual que antes.

Piensa en un repositorio como una carpeta normal a la que le has activado un “grabador de versiones”. Cada vez que guardas un punto de control, Git anota qué había en ese momento para que puedas volver más tarde. Ese grabador vive entero dentro de .git. Si borras esa subcarpeta, tu proyecto vuelve a ser una carpeta normal y pierdes solo la historia, no el código.

La palabra clave aquí es local. Un repositorio local vive en tu ordenador y funciona sin conexión. Es tuyo y de nadie más hasta que decidas subirlo.

¿git init o git clone? ¿Cuál necesitas?

Usa git init cuando empiezas de cero con código que ya está en tu máquina, y usa git clone cuando quieres copiar un repositorio que ya existe en un servidor. Esa es toda la diferencia, pero conviene verla al lado:

	git init	git clone <url>
Punto de partida	Una carpeta tuya, con o sin archivos	Un repositorio que ya existe online
Qué hace	Crea .git vacío en tu carpeta	Descarga el repo completo con toda su historia
¿Necesita URL remota?	No	Sí, la del repositorio
Caso típico	Proyecto nuevo desde cero	Bajar un proyecto de un compañero o de GitHub

Si estás leyendo esto porque acabas de crear una carpeta y quieres versionarla, tu comando es git init. git clone es para cuando el trabajo de otra persona ya está en algún sitio y tú solo lo traes a tu máquina.

Paso 1: inicializar el repositorio

Entra en la carpeta de tu proyecto y ejecuta git init indicando el nombre de la rama inicial. Voy a usar una carpeta de ejemplo llamada mi-proyecto:

# Entra en la carpeta de tu proyecto
cd mi-proyecto

# Inicializa el repositorio y nombra la rama inicial "main"
git init -b main

La opción -b main (abreviatura de --initial-branch=main) le dice a Git que llame main a la primera rama. Una rama es simplemente una línea de trabajo con un nombre; de momento te basta con saber que tu historia irá creciendo sobre main. Si no pones -b, Git usa el nombre que tengas configurado en init.defaultBranch, y si no has configurado nada ese nombre por defecto sigue siendo master en todas las versiones de Git publicadas hasta hoy (está previsto que pase a main cuando llegue Git 3.0, que todavía no ha salido). Poniéndolo tú, no dependes de la configuración de cada máquina.

Al ejecutarlo verás algo así:

Initialized empty Git repository in /Users/tu-usuario/mi-proyecto/.git/

Eso es todo lo que hace. Ha aparecido la carpeta .git (oculta, por eso el punto delante) y tu repositorio ya existe. Todavía está vacío de historia: no hay ningún commit guardado aún.

Paso 2: crear un archivo y ver el estado

git status te dice en qué situación está cada archivo respecto a Git. Es el comando que más vas a usar. Vamos a crear un archivo primero:

# Crea un README con una línea de texto
echo "# Mi proyecto" > README.md

# Pregunta a Git qué ve
git status

La respuesta será parecida a esta:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	README.md

nothing added to commit but untracked files present (use "git add" to track)

Aquí aparecen dos palabras que hay que entender bien. Un archivo untracked (sin rastrear) es uno que Git ve en la carpeta pero que aún no vigila: sabe que está ahí, pero no guarda sus cambios. Un archivo tracked (rastreado) es uno que ya forma parte del repositorio y del que Git registra cada modificación. Tu README.md está untracked porque acabas de crearlo y todavía no le has dicho a Git que lo tenga en cuenta.

Ese “todavía no le has dicho” es justo el siguiente paso.

Paso 3: preparar los cambios con git add

git add mueve un archivo a la staging area, la zona donde preparas lo que entrará en el próximo commit. Aquí va la analogía que a mí me hizo clic cuando empecé: imagina que vas a enviar un paquete. La staging area es la caja. git add es meter cosas en la caja, y el commit (el paso siguiente) es cerrarla y etiquetarla. Puedes meter y sacar cosas de la caja todas las veces que quieras antes de cerrarla.

# Mete el README en la caja (la staging area)
git add README.md

Este comando no imprime nada, lo cual asusta al principio. Pregúntale a Git otra vez:

git status

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   README.md

README.md ha pasado de “untracked” a “changes to be committed”. Ya está en la caja, listo para el commit.

Cuando tengas varios archivos y quieras meterlos todos de golpe, existe git add ., que añade todo lo que haya en la carpeta actual y por debajo:

# Añade TODOS los archivos nuevos y modificados de la carpeta
git add .

Al principio, mejor git add <archivo> uno a uno, así ves exactamente qué estás preparando. git add . es cómodo, pero también es la forma más fácil de colar en un commit algo que no querías.

Paso 4: tu primer commit

git commit toma todo lo que hay en la staging area y lo guarda como un punto permanente en la historia del proyecto. Un commit es una foto de tus archivos en un momento concreto, con un mensaje que explica qué cambiaste y por qué.

# Cierra la caja y guarda el punto de control con un mensaje
git commit -m "Primer commit: añade README"

La opción -m te deja escribir el mensaje ahí mismo, entre comillas. La salida será algo así:

[main (root-commit) a3f9c21] Primer commit: añade README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Ese a3f9c21 es el hash del commit: un identificador único que Git genera para cada punto de la historia. Aparece abreviado, pero por dentro es un código más largo formado solo por números y letras de la a a la f. No tienes que memorizarlo; te sirve para referirte a ese commit cuando quieras volver a él. (root-commit) significa que es el primero de todos, la raíz de tu historia.

Para verlo en una línea limpia:

# La historia del proyecto, un commit por línea
git log --oneline

a3f9c21 (HEAD -> main) Primer commit: añade README

Enhorabuena, acabas de pasar de “carpeta con archivos” a “primer commit hecho”. HEAD -> main te indica que estás situado sobre la rama main y que ese es el último commit.

Antes de seguir, prueba tú mismo el ciclo add y commit en este ejercicio interactivo. Se aprende mucho más tecleándolo que leyéndolo:

Cargando ejercicio...

Errores comunes al empezar

Estos son los tropiezos que casi todo el mundo tiene la primera semana. Reconocerlos ahora te ahorra un rato de frustración.

Ejecutar git init dentro de otro repositorio

Si haces git init en una carpeta que ya está dentro de otro repositorio Git, acabas con repos anidados y con un lío difícil de entender: los cambios de la carpeta interna no aparecen donde esperas. Antes de inicializar, comprueba con git status que no estás ya dentro de un repositorio. Si Git te responde con un estado en lugar de decir que no es un repositorio, párate: ya hay uno ahí.

Olvidar git add y creer que el commit “no ve” tus archivos

Este es el más frecuente. Creas un archivo, haces git commit directamente y Git responde que no hay nada que guardar. No está roto: es que un archivo untracked no entra en un commit hasta que pasa por git add. Si git status te muestra algo bajo “Changes to be committed”, entrará; si sigue en “Untracked files”, no.

Pensar que git commit -a incluye archivos nuevos

Verás por ahí el atajo git commit -a -m "..." (o git commit -am "..."), que promete saltarse el git add. Ojo con esto: -a solo prepara automáticamente modificaciones y borrados de archivos que Git ya rastrea. Un archivo nuevo, untracked, no lo toca. Como en tu primer commit el archivo será nuevo, git commit -a no lo incluirá y necesitas un git add previo de todas formas.

Hacer commit sin haberte identificado

Git guarda en cada commit quién lo hizo, con tu nombre y tu email. Si nunca los has configurado, al intentar el commit te pedirá que lo hagas antes de continuar. Es una configuración de un minuto que se hace una sola vez por máquina, y la tienes explicada en la guía para configurar Git por primera vez.

Confundir git init con “crear un repo en GitHub”

git init crea un repositorio local, en tu ordenador. Crear un repositorio en GitHub crea uno remoto, en sus servidores. Son cosas distintas y complementarias: primero versionas en local con git init, y más adelante (si quieres) conectas ese repo local con uno remoto para subir tu trabajo. GitHub es opcional; git init funciona perfectamente tú solo y sin conexión.

¿Y ahora qué?

Ya tienes un repositorio con su primer commit, y esa es la parte que más intimida, ya hecha. A partir de aquí repites el ciclo (git add, git commit) cada vez que avances, y en algún momento subes tu trabajo a un remoto con git push. Ese flujo completo, de la carpeta local a GitHub, lo desgloso en el post sobre cómo funcionan git add, commit y push. Y si quieres el panorama general antes de seguir, empieza por la guía de Git para dar tus primeros pasos.

Si prefieres aprender esto tecleando de verdad, con ejercicios corregidos al momento, tienes el recorrido completo en el curso Git de cero a profesional. Está pensado justo para este punto: acabas de hacer tu primer commit y quieres afianzarlo.

Checklist de tu primer repositorio

• Git instalado y git --version responde con un número
• Estás dentro de la carpeta correcta con cd antes de inicializar
• git init -b main ejecutado y la carpeta .git creada
• git status muestra tus archivos como untracked al principio
• Los archivos que quieres guardar están preparados con git add
• Primer commit hecho con git commit -m "..." y mensaje claro
• git log --oneline muestra tu commit con su hash

Preguntas Frecuentes

¿git init sube algo a internet?

No. git init trabaja solo en tu ordenador y crea un repositorio local dentro de la carpeta .git. No envía nada a ningún servidor ni necesita conexión. Para que tu código llegue a internet hace falta, más adelante, conectar el repo con un remoto y usar git push.

¿Puedo deshacer un git init?

Sí, y es sorprendentemente simple: borra la carpeta oculta .git que se creó al inicializar. Al eliminarla, la carpeta vuelve a ser un directorio normal sin control de versiones y tus archivos de código quedan intactos. Lo único que pierdes es la historia de commits que hubieras guardado.

¿Por qué la rama se llama main y no master?

Durante años la rama inicial por defecto de Git se llamaba master, y main se adoptó después como nombre más habitual. Con git init -b main eliges el nombre tú y no dependes de la versión de Git que tenga cada máquina. Funcionalmente una rama main y una master son idénticas; solo cambia el nombre.

¿Necesito una cuenta de GitHub para usar git init?

No. Git y GitHub son cosas distintas. Git es la herramienta de control de versiones que corre en tu máquina, y git init es puramente local. GitHub es un servicio online para alojar repositorios y colaborar. Puedes usar Git durante todo un proyecto sin abrir jamás una cuenta de GitHub.

¿Qué es exactamente la carpeta .git?

Es donde Git guarda todo: cada commit, cada versión de cada archivo, las ramas y la configuración del repositorio. Está oculta (el punto inicial la esconde en la mayoría de sistemas) porque no tienes que tocarla a mano casi nunca. Mientras esa carpeta exista dentro de tu proyecto, tu carpeta es un repositorio Git; si la borras, deja de serlo.

Un concepto nuevo cada semana

Suscribirme