2. Instala Git y crea tu primer repositorio

Descripción

Al terminar esta lección vas a tener Git instalado y configurado en tu máquina, vas a saber qué es exactamente un repositorio —y por qué es apenas una carpeta con una carpeta oculta adentro—, vas a poder nombrar las tres zonas donde vive tu trabajo cuando Git le lleva el historial (el árbol de trabajo, el área de preparación y el historial), y vas a haber convertido la carpeta cumbre-automations, con tu workflow order-triage.json dentro, en tu primer repositorio de Git. Todo con un comando por paso y una explicación de qué respondió la terminal en cada uno.

Esto importa porque es el cimiento de todo lo que sigue. No puedes hacer un commit sin un repositorio, ni leer un diff, ni trabajar en ramas: todo se apoya sobre la carpeta que vas a inicializar hoy. Y como es la primera vez que le hablas a Git de verdad, esta lección va despacio: cada comando viene con la señal exacta que confirma que funcionó y con el tropiezo típico que comete quien empieza, para que lo reconozcas antes de caer en él.

Conexión con el módulo: la lección 1 fue el mapa; esta es el primer paso en el terreno. Aquí no vamos a guardar nada todavía —tu primer commit es la lección 3—; vamos a preparar la máquina y el repositorio para poder hacerlo. Una vez que cumbre-automations sea un repositorio, la lección 3 hace la primera foto, la 4 compara fotos, la 5 abre ramas y así hasta el final. Si algo de hoy no queda firme, el resto se tambalea, así que vale la pena hacerlo con calma.

Instalar Git en tu máquina

Empecemos por lo primero. Git es un programa que tienes que tener instalado, igual que instalaste n8n o tu navegador. Puede que ya lo tengas —muchos sistemas lo traen o lo instalaron otras herramientas— así que antes de instalar nada, vamos a preguntarle a la máquina si ya está.

Abre una terminal. Si nunca abriste una:

• En Windows, busca en el menú de inicio la aplicación Git Bash (si ya tienes Git) o PowerShell. Para esta guía te voy a recomendar Git Bash una vez que instales Git, porque se comporta igual que las terminales de Mac y Linux y así los comandos son idénticos para todos.
• En macOS, abre la aplicación Terminal (búscala con Spotlight, la lupa de arriba a la derecha, escribiendo "Terminal").
• En Linux, ya sabes dónde está tu terminal; ábrela.

Con la terminal abierta, escribe esto y presiona Enter:

git --version

Qué esperar. Si Git ya está instalado, la terminal te responde con algo así:

git version 2.45.2

El número exacto casi seguro va a ser distinto en tu máquina, y no importa: cualquier versión 2.x reciente sirve de sobra para todo el módulo. Al momento de escribir esta guía —julio de 2026— la línea 2.x es la vigente, y las versiones nuevas salen cada pocos meses. Si te aparece un número, micro-victoria: ya tienes Git, salta directo a la sección de configuración.

Si en cambio te responde algo como command not found, git: no se encontró la orden o —en Windows sin Git— una ventana que te ofrece instalarlo, entonces hay que instalarlo. Cada sistema tiene su camino.

Windows

La forma más directa es descargar el instalador oficial desde git-scm.com/download/win. Se baja un archivo .exe, lo ejecutas, y te va a hacer bastantes preguntas durante la instalación. Es normal que sean muchas y que suenen técnicas; para lo que hacemos aquí, puedes dejar casi todas en su valor por defecto y darle "Next". El instalador de Git para Windows viene con opciones sensatas de fábrica.

Hay una pantalla que sí vale la pena mirar: la que pregunta por el editor de texto por defecto. Trae seleccionado un editor llamado Vim, que es potente pero muy incómodo si no lo conoces —tiene fama de que la gente no sabe ni cómo salir de él—. Si en la lista aparece un editor que ya conoces, como Visual Studio Code o el Bloc de notas (Notepad), elígelo. Si no reconoces ninguno, no te preocupes: en esta guía casi no vamos a necesitar ese editor, y cuando lo hagamos te aviso cómo salir.

Al terminar, cierra la terminal, abre Git Bash (que el instalador acaba de agregar a tu menú de inicio) y vuelve a escribir git --version. Ahora sí debería responderte con un número.

macOS

En Mac, la forma más limpia es a través de Homebrew, un administrador de programas para la terminal que quizás ya tengas de otras guías del ecosistema (lo usamos en la guía de instalación de Python). Si tienes Homebrew, escribe:

brew install git

Se van a ver varias líneas de instalación pasando por la pantalla. Está bien, es lo esperado; déjalo terminar.

Si no tienes Homebrew, hay un atajo: escribe git --version de nuevo, y en muchas versiones de macOS aparece una ventana que te ofrece instalar las "herramientas de línea de comandos" (Command Line Tools), que incluyen Git. Acepta, espera a que termine —puede tardar varios minutos y descargar bastante— y listo. Cualquiera de los dos caminos te deja con Git funcionando.

Linux

Usa el administrador de paquetes de tu distribución. En las basadas en Debian o Ubuntu:

sudo apt update && sudo apt install git

En Fedora:

sudo dnf install git

Te va a pedir tu contraseña (el sudo es para instalar a nivel del sistema; es normal que no se vea nada mientras la escribes) y va a confirmar la instalación. Al terminar, git --version te responde con el número.

Cada computador es un mundo. Si tu instalación se comporta distinto de lo que describo —un mensaje raro, una pantalla que no menciono, un error que no está aquí— no es que hiciste algo mal: es que hay cientos de combinaciones de sistema operativo y versión. Copia el mensaje de error, pégalo en el chat de inteligencia artificial que uses o en tu buscador, y en general la respuesta aparece en el primer resultado. Aprender a resolver estos baches por tu cuenta es parte de volverte autónomo, y vas a hacerlo más de una vez en tu carrera.

Configurar Git: tu nombre para que los commits tengan autor

Antes de crear el primer repositorio, hay que decirle a Git quién eres. Recuerda de la lección 1 que cada versión guardada —cada commit— lleva registrado quién la hizo. Git necesita saber tu nombre y tu correo para poder ponerlos en esa firma. Esto se configura una sola vez por máquina, no una vez por proyecto.

Escribe estos dos comandos, reemplazando el nombre y el correo por los tuyos:

# Tu nombre, tal como quieres que aparezca firmando cada versión.
git config --global user.name "Ana Torres"

# Tu correo. Usa el mismo con el que abrirás GitHub en la lección 6.
git config --global user.email "ana.torres@cumbre.example"

Qué esperar. Nada. Ninguno de los dos comandos responde con texto, y eso te va a pasar seguido con Git: muchos comandos que funcionan bien no dicen nada. En el mundo de la terminal, el silencio suele significar éxito. Si un comando termina sin quejarse, hizo lo suyo. Solo cuando algo sale mal, Git habla.

Desmenucemos ese comando pieza por pieza, porque vas a ver esa forma muchas veces:

• git config es la orden de "ajusta una configuración de Git".
• --global significa "este ajuste vale para todas mis carpetas en esta máquina, no solo para un proyecto". Sin --global, el ajuste valdría solo dentro del repositorio en el que estés parado. Como tu nombre no cambia entre proyectos, lo pones global una vez y te olvidas.
• user.name es el nombre del ajuste que estás fijando. Hay decenas de ajustes; este guarda tu nombre de autor.
• Lo que va entre comillas es el valor. Las comillas son importantes cuando el valor tiene espacios, como un nombre y un apellido.

Hay un tercer ajuste que conviene hacer ahora, porque te ahorra una confusión más adelante. Cuando Git crea un repositorio nuevo, la primera línea de trabajo —la rama principal— necesita un nombre. Históricamente se llamaba master, y hoy el estándar de la industria y de GitHub es main. Para que tu repositorio nazca con el nombre moderno, escribe:

# Que la rama principal de los repositorios nuevos se llame "main".
git config --global init.defaultBranch main

Ramas es el tema de la lección 5; por ahora quédate solo con que acabas de pedir que la rama principal se llame main, que es lo que espera GitHub cuando lleguemos a la lección 6.

Para confirmar que todo quedó guardado, pídele a Git que te muestre su configuración:

git config --list

Qué esperar. Una lista de líneas del tipo clave=valor. Entre ellas deben aparecer tus tres ajustes:

user.name=Ana Torres
user.email=ana.torres@cumbre.example
init.defaultbranch=main

Puede haber más líneas alrededor —ajustes que Git trae de fábrica o que puso el instalador—; ignóralas, lo que nos importa es ver tu nombre, tu correo y el nombre de rama. Perfecto: Git ya sabe quién eres. Ese nombre va a firmar cada foto que tomes de aquí en adelante.

Qué es, exactamente, un repositorio

Ahora la pregunta central de la lección. Vas a oír "repositorio" cientos de veces; conviene tener una imagen precisa y no una vaga.

Un repositorio —o "repo", como le dice todo el mundo— es una carpeta común y corriente de tu computadora a la que Git le está llevando el historial. Eso es todo. No es un tipo especial de carpeta, no vive en un servidor, no requiere internet. Es tu carpeta de siempre, con tus archivos de siempre, más una carpeta oculta adentro llamada .git donde Git guarda todo el historial.

Piénsalo así: una carpeta normal es una habitación con tus cosas. Un repositorio es esa misma habitación con tus mismas cosas, pero con una cámara de seguridad en la esquina que va guardando fotos de cómo estuvo la habitación en cada momento importante. La habitación no cambia; lo que se agrega es la memoria de sus estados. Esa cámara y su archivo de fotos son la carpeta .git.

Cuando conviertes una carpeta en repositorio —lo que vas a hacer en un momento con git init— no le pasa nada a tus archivos. order-triage.json sigue ahí, idéntico. Lo único que aparece es esa carpeta .git oculta. Y cuando más adelante quieras "dejar de versionar" una carpeta, basta con borrar la .git y vuelve a ser una carpeta normal, con tus archivos intactos. El historial es una capa que se pone y se quita encima de tus archivos, sin tocarlos.

Las tres zonas donde vive tu trabajo

Aquí viene el concepto que más confunde al principio y que, una vez que hace clic, hace clic para siempre. Cuando Git le lleva el historial a una carpeta, tu trabajo existe en tres zonas distintas al mismo tiempo. No son tres carpetas; son tres estados por los que pasa un cambio.

Zona 1 — El árbol de trabajo (working tree). Es lo que ves en tu carpeta: tus archivos tal como están ahora mismo. Cuando abres order-triage.json y lo editas, estás tocando el árbol de trabajo. Es tu mesa de trabajo: lo que tienes entre manos en este instante.

Zona 2 — El área de preparación (staging area). Es una zona intermedia donde eliges qué cambios van a entrar en tu próxima foto, antes de tomarla. Es la lección 3 completa, así que por ahora solo tenla en el mapa: es el paso entre "cambié algo" y "guardé ese cambio en el historial".

Zona 3 — El historial (repository). Es la colección de fotos ya tomadas —los commits— que vive dentro de la carpeta .git. Una vez que una foto está aquí, es permanente y puedes volver a ella.

La analogía que mejor funciona es la de tomar una foto de grupo. El árbol de trabajo es la sala entera, con toda la gente moviéndose. El área de preparación es cuando dices "ustedes tres, párense aquí para la foto" —eliges quién sale—. Y el historial es la foto ya tomada y guardada en el álbum. La gente sigue en la sala después de la foto (el árbol de trabajo sigue vivo), pero la foto capturó exactamente a quienes pusiste en el encuadre en ese momento.

Este viaje en tres zonas —trabajo → preparación → historial— es el latido de Git. Todo lo que hagas de aquí en adelante es mover cambios por esas tres zonas. Hoy solo creamos el escenario; el movimiento empieza en la lección 3.

Tres comandos para no perderte en la terminal

Para crear el repositorio necesitas pararte dentro de la carpeta correcta, y para eso hacen falta tres comandos de navegación que no son de Git pero que vas a usar en cada sesión. Vale la pena tenerlos claros ahora para que la terminal deje de ser un laberinto.

• pwd ("print working directory") te dice en qué carpeta estás parado en este momento. Es tu "¿dónde estoy?". Devuelve una ruta como /Users/ana.
• ls ("list") te muestra qué hay en la carpeta actual: archivos y subcarpetas. Es tu "¿qué hay aquí?".
• cd ("change directory") te mueve a otra carpeta. cd cumbre-automations entra a esa subcarpeta; cd .. sube un nivel (los dos puntos significan "la carpeta de arriba"); cd a secas te regresa a tu carpeta personal.

Piénsalo como moverte por el explorador de archivos, pero escribiendo en vez de haciendo doble clic. cd es el doble clic para entrar a una carpeta; cd .. es el botón de "atrás"; ls es mirar el contenido; pwd es leer la barra de dirección para saber dónde estás. Exactamente lo mismo que ya haces con el mouse, con otras palabras.

El reflejo que quiero que adoptes: antes de cualquier comando de Git, corre pwd para confirmar dónde estás. Un git init corrido en la carpeta equivocada es el error práctico más común de esta lección, y pwd lo previene en dos segundos.

Crear el repositorio: git init sobre cumbre-automations

Llegó el momento. Vamos a convertir la carpeta de Cumbre en un repositorio.

Ejemplo trabajado: de carpeta común a repositorio

Paso 1 — Ten lista la carpeta con tu workflow. Necesitas una carpeta llamada cumbre-automations con tu archivo order-triage.json dentro (el que exportaste en el Módulo 1). Si aún no la tienes, créala. Puedes hacerlo con el explorador de archivos de tu sistema, dándole clic derecho a "Nueva carpeta" y arrastrando el JSON adentro —es exactamente lo mismo que hacer esto en la terminal—:

# Crea la carpeta del proyecto. mkdir = "make directory", crear carpeta.
mkdir cumbre-automations

Coloca tu order-triage.json dentro de esa carpeta. Si todavía no lo exportaste, abre order-triage en n8n, usa la opción de descargar o exportar a JSON, y guarda el archivo ahí con ese nombre.

Paso 2 — Métete en la carpeta. Git inicializa el repositorio en la carpeta donde estés parado, así que primero hay que entrar a ella:

# cd = "change directory", entrar a una carpeta.
cd cumbre-automations

Qué esperar. Otra vez el silencio del éxito: la terminal no dice nada, pero fíjate en el texto que aparece antes de donde escribes —el llamado prompt—: ahora debería incluir cumbre-automations, confirmando que estás dentro. Esa señal visual es tu confirmación de dónde estás parado, y conviene mirarla siempre antes de correr git init, por una razón que verás en los errores comunes.

Paso 3 — Inicializa el repositorio. El comando estrella de la lección:

git init

Qué esperar. Ahora Git sí responde, con una línea como esta:

Initialized empty Git repository in /Users/ana/cumbre-automations/.git/

Léela con atención, porque te está diciendo tres cosas valiosas. "Initialized": se creó el repositorio. "empty" (vacío): todavía no hay ninguna foto guardada —el historial está en blanco, y eso es correcto, tu primer commit es la lección 3—. Y la ruta que termina en /.git/: te dice exactamente dónde se creó la carpeta oculta del historial, dentro de tu cumbre-automations. Esa ruta va a ser distinta en tu máquina; lo que importa es que termine en el nombre de tu carpeta seguido de /.git/.

Si en vez de eso ves una línea que empieza con un aviso sugiriéndote configurar el nombre de la rama por defecto, no pasa nada: es un recordatorio inofensivo que aparece si te saltaste el ajuste init.defaultBranch main de más arriba. El repositorio se creó igual.

Paso 4 — Pregúntale a Git cómo está el proyecto. El comando que más vas a usar en tu vida con Git:

git status

Qué esperar. Con tu order-triage.json en la carpeta, Git responde algo así:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	order-triage.json

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

Este bloque es un pequeño reporte de estado, y aprender a leerlo es la mitad del trabajo con Git. Vamos línea por línea:

• On branch main: estás parado en la rama main, la que pediste que fuera la principal. (Ramas: lección 5. Por ahora, es donde estás.)
• No commits yet (aún no hay commits): confirma que el historial está vacío. No has tomado ninguna foto todavía.
• Untracked files: (archivos sin seguimiento): aquí está la clave. Git ve tu order-triage.json, pero todavía no le está llevando el historial. Un archivo "sin seguimiento" es uno que existe en tu carpeta pero que Git aún no ha incorporado a su memoria. Es como un invitado que llegó a la fiesta pero al que todavía no anotaste en la lista.
• La línea entre paréntesis y la última son sugerencias de Git: te está diciendo, literalmente, el comando que sigue —git add— para empezar a seguir ese archivo. Git te va guiando; solo hay que leerlo.

Y con esto, lo lograste: cumbre-automations ya es un repositorio de Git. Todavía vacío de historial, pero listo para recibir su primera foto. No es poco para tu primer contacto real con la herramienta.

Un vistazo (sin tocar) a la carpeta .git

Puede darte curiosidad ver esa carpeta oculta que se creó. Es sano echarle un ojo una vez, para desmitificarla, con una regla de oro: míralas, no la toques.

Como empieza con un punto, la carpeta .git está oculta por defecto. Para verla desde la terminal:

# ls lista los archivos; -a incluye los ocultos (los que empiezan con punto).
ls -a

Qué esperar. Entre lo que aparece vas a ver .git junto a tu order-triage.json:

.		..		.git		order-triage.json

Si entras a .git (puedes, con cd .git y luego ls), vas a encontrar una estructura de carpetas y archivos con nombres como HEAD, objects, refs, config. Ahí es donde Git guarda cada foto, cada rama y cada ajuste del repositorio. No vas a editar nada de eso a mano —jamás, ni cuando seas experto: se maneja siempre a través de los comandos de Git—. Es como la sala de máquinas de un edificio: te tranquiliza saber que existe y más o menos qué hay, pero no vas a andar moviendo palancas ahí adentro.

La razón por la que menciono esto no es para que juegues con .git, sino para que entiendas una cosa importante: todo el historial de tu proyecto vive dentro de esa carpeta. Si copias la carpeta cumbre-automations entera a otro lado —incluida su .git—, te llevas el historial completo. Si copias solo el order-triage.json sin la .git, te llevas el archivo pero pierdes toda su historia. Esa es la diferencia entre respaldar un repositorio y respaldar un archivo suelto, y va a ser relevante cuando hablemos de remotos en la lección 6.

Sal de la carpeta .git si entraste, para volver a la raíz del proyecto:

cd ..

Errores comunes

git: command not found después de instalar (práctico). Qué pasa: instalas Git, escribes git --version en la misma terminal que ya tenías abierta, y sigue diciendo que no encuentra el comando. Por qué pasa: una terminal aprende qué programas hay disponibles al momento de abrirse; si instalas algo nuevo, la terminal que ya estaba abierta no se entera. En Windows además pasa que instalaste Git pero sigues en PowerShell o en el símbolo del sistema, cuando la terminal pensada para Git es Git Bash. Cómo detectarlo: si acabas de instalar y falla, sospecha de esto antes que de la instalación. Cómo corregirlo: cierra la terminal por completo y abre una nueva —en Windows, abre específicamente Git Bash— y vuelve a intentar. Si aún falla en Windows, probablemente Git no quedó en el PATH; reinstala marcando la opción que menciona "PATH" o "line command", que es justamente la que conecta Git con la terminal.

Olvidar configurar user.name y user.email (práctico). Qué pasa: te saltas la configuración, todo parece ir bien, y en la lección 3, al hacer tu primer commit, Git te frena con un mensaje pidiendo que le digas quién eres. Por qué pasa: Git no puede firmar una foto sin autor, así que en lugar de inventarte un nombre, se detiene y lo exige. Cómo detectarlo: si al intentar un commit ves un texto que menciona user.name y user.email con instrucciones para configurarlos, es esto. Cómo corregirlo: corre los dos comandos git config --global de esta lección y repite el commit. Por eso lo hicimos ahora y no después: para que ese tropiezo no te agarre a mitad de tu primer commit.

Correr git init en la carpeta equivocada —o en tu carpeta personal (práctico y peligroso). Qué pasa: corres git init sin fijarte en dónde estás parado, y en vez de inicializar cumbre-automations inicializas tu carpeta personal entera (tu home), o el escritorio, o una carpeta que ya contenía otro repositorio. Por qué pasa: git init actúa sobre la carpeta actual, y si no revisaste el prompt, no sabes cuál es la carpeta actual. Inicializar tu carpeta personal es especialmente molesto: Git empieza a "ver" todos tus archivos personales como parte de un repositorio gigante. Cómo detectarlo: antes de git init, corre pwd (te dice la ruta exacta donde estás; significa "print working directory") y confirma que termina en cumbre-automations. Después de git init, la línea "Initialized ... in ..." te dice dónde se creó; si no es la ruta que esperabas, algo salió mal. Cómo corregirlo: si inicializaste la carpeta equivocada, entra a ella y borra la carpeta .git que se creó (rm -rf .git en Mac/Linux, o bórrala desde el explorador de archivos mostrando los ocultos). Eso deshace el git init sin tocar tus archivos, porque —recuerda— el historial es una capa que se quita sin dañar lo de abajo. Ojo con rm -rf: es un comando que borra sin preguntar, así que verifica dos veces que estás borrando la .git correcta.

Crear un repositorio dentro de otro repositorio (conceptual). Qué pasa: ya tenías cumbre-automations como repositorio y, sin querer, corres git init de nuevo dentro de una subcarpeta suya, quedando un repo anidado dentro de otro. Por qué pasa: se pierde la cuenta de qué carpetas ya son repositorios. Cómo detectarlo: git status desde distintas carpetas te dice a qué repositorio pertenece cada una; si una subcarpeta reporta un repositorio distinto del de arriba, hay anidamiento. Cómo corregirlo: para el ciclo de vida de un workflow, un repositorio por proyecto es lo correcto —cumbre-automations entero es un solo repo—. Si apareció uno anidado por error, borra la .git de la subcarpeta. Los repositorios anidados de verdad (submódulos) existen, pero son justo el tipo de Git avanzado que esta guía deja fuera a propósito; no los necesitas.

Ejercicios

Ejercicio 1 — Verifica tu instalación de punta a punta. En una terminal recién abierta, corre en orden: git --version, luego git config --list. Anota (a) qué número de versión tienes, (b) confirma que aparecen tu user.name y tu user.email con los valores correctos. Si algo falta o está mal escrito (un typo en el correo, por ejemplo), corrígelo volviendo a correr el git config --global correspondiente y verifica de nuevo.

Ver solución

Las respuestas son propias de tu máquina, y ese es el punto: el ejercicio instala el hábito de verificar tu propio entorno en vez de asumir que quedó bien. Cualquier versión 2.x reciente en (a) es correcta.

Si en (b) tu correo tiene un error de dedo, corregirlo es simplemente volver a correr git config --global user.email "el-correcto@...": el comando sobrescribe el valor anterior, no lo duplica. Ese detalle —que volver a fijar un ajuste lo reemplaza— es útil de saber: no hay que "borrar" el viejo primero.

Por qué funciona: un correo mal escrito en la configuración no da error hoy, pero en la lección 6, cuando conectes con GitHub, tus commits podrían no asociarse a tu cuenta. Detectarlo ahora, cuando cuesta diez segundos arreglarlo, te ahorra una confusión futura.

Ejercicio 2 — Nombra las tres zonas sobre un caso concreto. Sin volver a mirar la sección, describe qué es el árbol de trabajo, el área de preparación y el historial, y ubica cada uno en esta situación: abres order-triage.json, le cambias la URL del CRM, y todavía no has hecho nada más. ¿En cuál de las tres zonas está tu cambio en este momento?

Ver solución

Árbol de trabajo: tus archivos tal como están ahora en la carpeta. Área de preparación: la zona donde eliges qué cambios entran en la próxima foto. Historial: las fotos ya tomadas, dentro de .git.

Tu cambio de la URL está únicamente en el árbol de trabajo. Editaste el archivo, pero no lo pusiste en el área de preparación (eso sería git add, lección 3) ni lo guardaste en el historial (eso sería git commit). Está "suelto" en tu mesa de trabajo: si cierras sin guardarlo en Git, ese cambio no queda registrado en ninguna foto.

Por qué funciona: este es exactamente el modelo mental que hace que Git deje de sentirse mágico. Un cambio nace siempre en el árbol de trabajo y viaja hacia el historial pasando por la preparación. Tener claro en qué zona está tu cambio en cada momento es lo que te va a permitir, en la lección 3, entender por qué un commit necesita dos pasos y no uno.

Ejercicio 3 — Crea y deshaz un repositorio de práctica. En una carpeta cualquiera de práctica (no en cumbre-automations), crea una subcarpeta nueva llamada git-practice, entra a ella, corre git init y confirma con git status que quedó como repositorio. Después, deshaz el repositorio borrando su carpeta .git y confirma con git status que ya no es un repositorio. Observa qué le pasó al contenido de la carpeta.

Ver solución

Después del git init, git status te reporta que estás en un repositorio (con "On branch main", "No commits yet", etc.). Tras borrar la .git —con rm -rf .git o desde el explorador mostrando los ocultos—, git status cambia por completo: ahora responde algo como fatal: not a git repository (fatal: no es un repositorio de git). Esa es la señal de que la carpeta volvió a ser común y corriente.

Lo que quiero que veas es lo que le pasó al contenido: nada. Si habías puesto un archivo de prueba en git-practice, sigue ahí, intacto, después de borrar la .git. Eso comprueba en la práctica lo que dijimos en la teoría: el historial es una capa que se pone y se quita sin dañar tus archivos. Saber esto quita el miedo a experimentar con Git, porque git init nunca pone en riesgo tu trabajo real.

Por qué funciona: hacer y deshacer un repositorio de práctica, sobre una carpeta que no te importa, es la forma más rápida de perderle el respeto reverencial a Git. Los comandos se vuelven cosas que puedes probar sin miedo cuando compruebas con tus propias manos que son reversibles y que no tocan tus archivos.

Resumen y siguiente paso

En esta lección instalaste Git —verificando primero con git --version si ya lo tenías— y lo configuraste con tu user.name, tu user.email y el nombre de rama por defecto main, ajustes que se hacen una sola vez por máquina y que hacen que tus commits tengan autor y que tus repositorios nazcan con el nombre de rama moderno. Entendiste qué es un repositorio: una carpeta común con una carpeta oculta .git adentro que guarda el historial, una capa que se pone y se quita sin tocar tus archivos. Conociste las tres zonas por las que viaja todo cambio —árbol de trabajo, área de preparación e historial— con la imagen de la foto de grupo. Y convertiste cumbre-automations en tu primer repositorio con git init, leyendo su reporte de estado con git status y descubriendo que tu order-triage.json aparece como archivo "sin seguimiento": Git lo ve, pero todavía no le lleva el historial.

Antes de avanzar a la lección 3 deberías poder: abrir una terminal y confirmar que git --version te responde; explicar qué es un repositorio y qué contiene la carpeta .git; nombrar las tres zonas y decir en cuál nace un cambio; y correr git init y git status sobre una carpeta, entendiendo qué significa "Untracked files".

Ese archivo "sin seguimiento" es justamente el cabo suelto que ata la lección 3. Ahí vas a tomar tu primera foto: vas a mover order-triage.json del árbol de trabajo al área de preparación con git add, y de ahí al historial con git commit, viendo por qué son dos pasos y no uno. Vas a aprender qué es exactamente un commit —una foto inmutable con nota, autor y folio único— y cómo escribir buenas notas de commit para un workflow, esas que en el martes malo de Cumbre marcan la diferencia entre saber qué pasó y adivinarlo. Tu repositorio está vacío de historial; en la lección 3 empieza a llenarse.

Recursos

• Installing Git — Git Docs — la guía oficial de instalación para Windows, macOS y Linux, con los tres caminos que vimos y algunos más. La referencia a la que volver si tu sistema se comporta distinto.
• Downloads — Git — la página de descargas oficial, con el instalador de Windows y las instrucciones por sistema operativo. El punto de partida más seguro para bajar Git.
• First-Time Git Setup — Git Docs — la configuración inicial de Git, incluyendo user.name, user.email y el editor por defecto. Útil si quieres cambiar el editor que eligió el instalador.
• git init — Git Docs — la página de referencia del comando que crea el repositorio, con todas sus opciones. Denso; por ahora solo necesitas el comando pelado, pero está bien saber dónde vive la referencia completa.
• git status — Git Docs — la referencia del comando que más vas a usar, con la explicación de cada estado en el que puede aparecer un archivo.