Saltar a contenido

Capítulo 2: Tu primer repositorio

En este capítulo comienza formalmente el proyecto principal del libro: un sitio web personal que irá creciendo a lo largo de toda la obra. A partir de aquí dejarás de ver Git como una idea abstracta y empezarás a usarlo sobre un proyecto real, pequeño al inicio, pero diseñado para evolucionar de forma profesional.[cite:38][cite:42]

El objetivo no es únicamente ejecutar comandos, sino comprender qué representa cada paso dentro del flujo básico de trabajo en Git. Al terminar este capítulo habrás creado tu primer repositorio local, registrado los primeros cambios del proyecto, consultado su estado, revisado el historial y adquirido una primera disciplina para escribir commits claros y útiles.[cite:38][cite:34]

2.1 ¿Qué es un repositorio?

Un repositorio es el espacio donde Git almacena y organiza la historia de un proyecto. Dicho de forma simple, es una carpeta de trabajo que, además de contener archivos normales, está preparada para que Git pueda rastrear cambios, registrar estados importantes y conservar un historial consultable.[cite:38]

A primera vista, una carpeta común y un repositorio Git pueden parecer lo mismo. Ambas pueden contener archivos como README.md, index.html, imágenes o documentos. La diferencia es que una carpeta normal solo guarda archivos; un repositorio Git guarda archivos y la historia de cómo esos archivos cambian con el tiempo.[cite:38]

Una analogía sencilla

Imagina una carpeta física donde guardas versiones impresas de un proyecto. Si solo apilas documentos, tienes contenido, pero no necesariamente un sistema claro para saber qué cambió entre una versión y otra. Un repositorio sería como esa misma carpeta acompañada por un registro detallado que anota cada modificación importante, cuándo se hizo y con qué propósito.

Otra analogía útil es pensar en un cuaderno de laboratorio. No solo importa el resultado final, sino también el proceso: qué se probó, qué se corrigió, qué se descartó y en qué momento. Git convierte una carpeta de proyecto en algo parecido a ese cuaderno técnico.

Carpeta común vs. repositorio Git

Aspecto Carpeta común Repositorio Git
Guarda archivos Sí Sí
Conserva historial de cambios No Sí.[cite:38]
Permite revisar estados anteriores No de forma estructurada Sí.[cite:38]
Ayuda a registrar cambios de forma lógica No Sí.[cite:42]
Facilita entender la evolución del proyecto Muy poco Mucho

Qué significa que “nuestro proyecto será un repositorio”

En este libro, el proyecto principal será un sitio web personal. Ese sitio comenzará con una estructura mínima, pero desde este capítulo quedará bajo control de Git. Eso significa que cada avance importante del proyecto podrá registrarse como parte de una historia real, en lugar de depender de copias manuales de carpetas o archivos.

Esa decisión cambia por completo la forma de trabajar. Ya no se trata de “guardar otra copia por si acaso”, sino de construir una secuencia ordenada de cambios con sentido. A medida que el sitio evolucione, su repositorio contará esa historia.

Nota

Un repositorio no es solo un lugar donde viven archivos. Es un entorno donde esos archivos pueden tener memoria, contexto y trazabilidad.[cite:38]

Ejemplo cotidiano aplicado al proyecto del libro

Supón que hoy creas la estructura inicial del sitio web personal. Mañana agregas una sección de presentación. Después mejoras el título principal. Más tarde reorganizas el contenido. Si todo eso ocurre en una carpeta común, el resultado final existe, pero el camino recorrido se pierde. En un repositorio Git, cada paso puede quedar registrado.

Eso vuelve el aprendizaje más claro. También vuelve el trabajo más seguro.

[Ilustración: comparación visual entre una carpeta común con archivos sueltos y un repositorio Git mostrado como la misma carpeta conectada a una línea de tiempo ordenada de cambios, con diseño moderno y enfoque educativo]

Lo importante en esta etapa

Por ahora solo necesitas quedarte con esta idea: un repositorio es una carpeta especial desde la perspectiva de Git. Sigue siendo una carpeta del sistema, pero ahora tiene la capacidad de registrar historia y de ayudarte a construir el proyecto con un flujo profesional.[cite:38]

Breve conclusión: un repositorio Git se parece a una carpeta común, pero añade algo decisivo: memoria estructurada del proyecto. Esa diferencia es la base de todo lo que harás a partir de aquí.

2.2 Creando nuestro proyecto

A partir de esta sección comenzará el proyecto que acompañará todo el libro: un sitio web personal. Este proyecto no es un ejemplo desechable. Será la base que se irá enriqueciendo en los siguientes capítulos, por lo que conviene empezar con una estructura clara y con decisiones simples pero correctas.

La carpeta del proyecto

El primer paso consiste en crear la carpeta donde vivirá el sitio web. Esa carpeta será, más adelante, el repositorio Git del proyecto. Antes de inicializar Git, sigue siendo una carpeta normal del sistema, pero ya conviene tratarla como el espacio oficial del proyecto.

Un nombre claro ayuda desde el principio. Para mantener consistencia durante el libro, se utilizará un nombre sencillo y profesional, por ejemplo:

sitio-web-personal

Ese nombre comunica el propósito del proyecto y evita ambigüedades. No es obligatorio usar exactamente ese texto, pero sí conviene elegir un nombre comprensible, sin adornos innecesarios y fácil de reconocer.

La estructura inicial

En este capítulo la estructura del proyecto será intencionalmente simple. Comenzaremos con dos archivos:

  • README.md
  • index.html

Esta estructura mínima es suficiente para arrancar el trabajo con Git sin mezclar todavía otros temas que pertenecen a capítulos posteriores.

Archivo Propósito inicial
README.md Presentar y describir brevemente el proyecto
index.html Ser la primera página del sitio web personal

¿Por qué empezar con tan poco?

Porque un buen aprendizaje técnico no consiste en construir complejidad innecesaria desde el primer minuto. Comenzar con una estructura pequeña permite concentrarse en el flujo esencial de Git: crear, observar, preparar, registrar y revisar.

Si intentaras empezar con una docena de archivos, imágenes, carpetas y recursos, el foco se perdería. En cambio, con una base mínima cada cambio se entiende mejor y cada commit puede representar una unidad lógica clara.

Creando README.md

El archivo README.md suele ser uno de los primeros archivos en muchos proyectos. GitHub, GitLab y otras plataformas lo muestran de forma destacada porque funciona como puerta de entrada al proyecto, pero incluso antes de usar plataformas remotas, ya tiene mucho valor como documento local.[cite:42]

En nuestro caso, README.md puede comenzar con algo muy sencillo: el nombre del proyecto y una breve descripción.

Ejemplo inicial:

# Sitio Web Personal

Proyecto base del libro Git y GitHub Profesional.

No hace falta escribir una documentación extensa en esta etapa. Lo importante es comprender que el proyecto ya empieza a comunicar su identidad.

Por qué README.md importa desde el inicio

Un buen proyecto técnico no se define solo por su código. También se define por la forma en que se presenta. README.md ayuda a:

  • Identificar rápidamente el proyecto.
  • Explicar su propósito básico.
  • Dar contexto a quien lo abre por primera vez.
  • Acostumbrarte a documentar desde el principio.

Aunque ahora parece un detalle pequeño, más adelante ese hábito será muy útil cuando el proyecto crezca.

Buenas prácticas

Crear un README.md desde el inicio ayuda a pensar el proyecto como algo que debe poder entenderse, no solo ejecutarse.

Agregando index.html

El segundo archivo será index.html, la página inicial del sitio web personal. En esta etapa no buscamos un diseño sofisticado. El objetivo es contar con una primera versión real del proyecto sobre la cual registrar cambios.

Un ejemplo inicial razonable sería una página muy simple con un título y un párrafo breve.

<!DOCTYPE html>
<html lang="es">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Mi Sitio Web Personal</title>
</head>
<body>
  <h1>Hola, soy tu nombre</h1>
  <p>Este es el inicio de mi sitio web personal.</p>
</body>
</html>

Este archivo cumple perfectamente su función en esta etapa: existe, forma parte de un proyecto real y puede evolucionar en capítulos posteriores.

Estructura recomendada al terminar esta sección

Antes de continuar, el proyecto debería verse conceptualmente así:

sitio-web-personal/
├── README.md
└── index.html

Qué estamos construyendo realmente

Aunque la estructura es mínima, ya existe una idea importante: no estás practicando Git sobre archivos sueltos sin contexto. Estás comenzando un proyecto continuo. Eso significa que los commits que hagas en este capítulo formarán parte del historial real del sitio web personal que crecerá a lo largo del libro.[cite:38]

[Ilustración: ventana de explorador de archivos mostrando la carpeta sitio-web-personal con README.md e index.html, acompañada por una vista previa simple del sitio web en el navegador]

Un enfoque profesional desde el inicio

En proyectos reales, empezar con una base pequeña y bien nombrada suele ser mejor que comenzar con demasiadas piezas mal organizadas. La claridad inicial facilita todo lo demás: entender cambios, documentar el proyecto y construir historial con sentido.

Breve conclusión: ya tienes un proyecto real, pequeño pero significativo. La carpeta del sitio web personal, junto con README.md e index.html, será la base sobre la que empezarás a registrar historia con Git.

2.3 Inicializando Git

Ahora que la carpeta del proyecto existe y ya contiene archivos reales, llega el momento de convertirla en un repositorio Git. El comando que realiza este paso es:

git init

La documentación oficial explica que git init crea un repositorio nuevo en el directorio actual y que, al hacerlo, Git responde indicando que ha inicializado un repositorio vacío dentro de una carpeta llamada .git.[cite:38][cite:42]

Qué hace git init

Cuando ejecutas git init dentro de la carpeta sitio-web-personal, Git no “sube” nada a Internet ni crea todavía un historial completo por sí solo. Lo que hace es preparar el proyecto para que pueda empezar a registrar cambios localmente.[cite:38]

Ese paso es como activar la memoria del proyecto. A partir de ese momento, Git reconoce que esa carpeta ya no es una carpeta cualquiera, sino un espacio en el que podrá rastrear estados del trabajo.

Qué sucede internamente

De manera conceptual, git init crea la estructura interna que Git necesita para funcionar. La documentación oficial y la hoja de referencia de Git indican que este comando genera la carpeta .git, que es donde se almacena la información esencial del repositorio.[cite:38][cite:42]

No necesitas abrirla ni manipularla manualmente en este capítulo. Lo importante es entender que .git actúa como el corazón del repositorio.

La carpeta .git

Después de inicializar el repositorio, dentro del proyecto aparece una carpeta oculta llamada .git. Esa carpeta no es un adorno ni un archivo secundario. Contiene la información interna que hace posible que Git registre historial, conserve configuración local del repositorio y administre el estado del proyecto.[cite:42]

Puedes pensar en .git como la sala de máquinas de un barco. Los pasajeros no necesitan entender cada detalle técnico de lo que ocurre ahí dentro para poder viajar, pero sin esa sala de máquinas el barco no funcionaría.

Nota

En este capítulo no se estudiará el contenido interno de .git en profundidad. Por ahora basta con saber que ahí vive la estructura que convierte una carpeta común en un repositorio Git.[cite:38][cite:42]

Lo que git init no hace

Conviene aclarar esto desde ahora:

  • No crea automáticamente commits.
  • No registra por sí solo los archivos existentes.
  • No conecta el proyecto con GitHub.
  • No publica el proyecto.

Solo prepara el repositorio para que empieces a trabajar con Git de manera local.[cite:38][cite:42]

Ejemplo aplicado al proyecto del libro

Supongamos que entras en la carpeta sitio-web-personal y ejecutas git init. A partir de ese instante:

  • el proyecto ya tiene estructura de repositorio;
  • Git puede empezar a observar cambios;
  • todavía no existe un commit inicial;
  • los archivos actuales siguen estando en la carpeta, pero ahora pueden formar parte de un historial.

Una forma visual de entenderlo

Antes del siguiente diagrama, observa la diferencia conceptual entre una carpeta normal y una carpeta convertida en repositorio.

flowchart LR
    A[Carpeta del proyecto] --> B[git init]
    B --> C[Se crea la estructura .git]
    C --> D[El proyecto se convierte en repositorio Git]

Este flujo muestra que git init no crea de inmediato una historia completa. Lo que hace es habilitar el entorno para que esa historia pueda comenzar.

Por qué este paso es tan importante

En la práctica, git init marca el momento en que el proyecto deja de ser solo contenido y pasa a ser también proceso. Desde aquí, cada cambio relevante podrá convertirse en una parte visible del historial.

Eso tiene un enorme valor didáctico. No estás practicando sobre ejemplos desconectados: estás dando inicio al repositorio real del proyecto que acompañará todo el libro.

Curiosidad

La documentación oficial se refiere a la zona de preparación como “index”, y el tutorial explica que git add toma una instantánea de archivos y la coloca allí antes de convertirla en parte del repositorio mediante un commit.[cite:38]

Después de inicializar

Una vez ejecutado git init, el siguiente paso natural no es todavía “guardar todo sin mirar”, sino observar el estado del proyecto. Por eso la siguiente sección se centra en git status, una herramienta fundamental para entender qué está viendo Git en cada momento.[cite:38][cite:42]

Breve conclusión: git init es el punto de partida del repositorio. Crea la estructura básica de Git, añade la carpeta .git y convierte la carpeta del proyecto en un entorno listo para comenzar a registrar historia.

2.4 El estado del proyecto

Una vez inicializado el repositorio, la herramienta más útil para entender qué está ocurriendo es:

git status

La documentación oficial describe git status como un resumen breve de la situación actual del proyecto, mostrando qué cambios están preparados para el próximo commit y qué archivos siguen sin estar preparados.[cite:38][cite:42]

Si hubiera un solo comando que conviene ejecutar con frecuencia cuando se está aprendiendo Git, sería este.

¿Qué muestra git status?

git status responde preguntas muy importantes:

  • ¿Git está viendo archivos nuevos?
  • ¿Hay archivos modificados?
  • ¿Esos cambios ya están preparados para el próximo commit?
  • ¿El proyecto está limpio o todavía hay trabajo pendiente?

Eso convierte a git status en una especie de panel de control del repositorio.

Archivos sin seguimiento

Cuando Git detecta archivos que existen en la carpeta del proyecto pero todavía no forman parte del seguimiento normal del repositorio, los muestra como untracked files o archivos sin seguimiento.[cite:38]

En nuestro proyecto, justo después de usar git init, es muy probable que README.md e index.html aparezcan en esa condición. Esto no significa que haya un error. Significa, simplemente, que Git sabe que existen, pero aún no se le ha indicado que deben formar parte del próximo registro.

Archivos rastreados

Un archivo rastreado es uno que Git ya conoce como parte del proyecto. Puede estar sin cambios, modificado o preparado para commit. La diferencia clave es que Git ya lo considera dentro de la historia del repositorio.

La transición desde “sin seguimiento” a “rastreado” ocurre cuando el contenido de ese archivo se incorpora al flujo normal del repositorio, normalmente a través del área de preparación y un commit.[cite:38]

Estados posibles de un archivo

Aunque más adelante verás matices adicionales, por ahora puedes pensar en estos estados principales:

Estado Significado
Sin seguimiento Git ve el archivo, pero todavía no forma parte del historial esperado
Modificado El archivo ya existe en el repositorio, pero fue cambiado
Preparado El archivo o sus cambios fueron colocados en el área de preparación
Confirmado en historial El estado preparado ya quedó registrado mediante un commit

Este modelo coincide con la lógica explicada por el tutorial oficial: primero hay contenido en el directorio de trabajo, luego ese contenido se prepara en el índice, y finalmente se registra en el repositorio mediante un commit.[cite:38]

Primer ejemplo: proyecto recién inicializado

Imagina este escenario:

  1. Creas la carpeta del proyecto.
  2. Agregas README.md e index.html.
  3. Ejecutas git init.
  4. Después ejecutas git status.

Lo esperable es que Git informe que existen archivos sin seguimiento, porque aún no se han preparado ni registrado.[cite:38]

Segundo ejemplo: archivo modificado

Supón que más adelante index.html ya forma parte del historial, pero editas el título principal del sitio. Si ejecutas git status, Git te mostrará que ese archivo fue modificado. Eso quiere decir que el directorio de trabajo contiene cambios nuevos, pero todavía no forman parte del siguiente commit.[cite:38][cite:42]

Tercer ejemplo: archivo preparado

Ahora imagina que después de modificar index.html decides prepararlo para el próximo commit. En ese momento, git status te mostrará ese archivo como listo para ser incluido en el siguiente registro del historial.[cite:38]

Este comportamiento es importante porque revela algo central en Git: cambiar un archivo no equivale automáticamente a guardarlo en la historia. Existe una etapa intermedia donde decides qué contenido formar parte del próximo commit.

Una lectura útil de git status

Antes del siguiente diagrama, conviene visualizar cómo cambia la relación entre el archivo y Git a medida que trabajas.

flowchart LR
    A[Archivo nuevo] --> B[Sin seguimiento]
    B --> C[Preparado]
    C --> D[Registrado en commit]
    D --> E[Modificado nuevamente]

Este flujo ayuda a entender que el estado de un archivo no es fijo. Va cambiando conforme Git lo detecta, tú lo preparas y finalmente lo incorporas al historial.

Cómo interpretar los resultados sin miedo

Al principio, la salida de git status puede parecer muy verbal. Sin embargo, la intención de Git es ayudarte. Normalmente indica con claridad si hay archivos nuevos, archivos modificados o cambios preparados, y suele incluir mensajes útiles sobre qué hacer a continuación.[cite:38]

En esta etapa, no necesitas memorizar cada palabra de la salida. Lo importante es responder tres preguntas cada vez que ejecutes el comando:

  1. ¿Qué archivos ve Git?
  2. ¿Cuáles están listos para el próximo commit?
  3. ¿Qué cambios todavía no forman parte de ese próximo commit?

Consejo

Usa git status con frecuencia. Más que un comando ocasional, debe convertirse en una costumbre. Te ayuda a entender el estado real del proyecto antes de tomar decisiones.[cite:38][cite:42]

Aplicado al proyecto del libro

Durante este capítulo trabajarás varias veces con README.md e index.html. Cada vez que crees uno de esos archivos, lo modifiques o lo prepares, git status te mostrará el estado actualizado. Eso hará visible el ciclo básico de Git en tiempo real.

Breve conclusión: git status es la ventana más clara para saber qué está pasando en tu repositorio. Gracias a él puedes distinguir archivos nuevos, modificados y preparados, y entender el estado real del proyecto antes de crear un commit.

2.5 Preparando archivos

Después de observar el estado del proyecto, el siguiente paso natural es preparar los archivos que deseas incluir en el próximo commit. Para eso se utiliza el comando git add.[cite:38][cite:42]

La documentación oficial explica algo muy importante: git add no solo sirve para “agregar archivos nuevos”, sino para tomar una instantánea del contenido indicado y colocarlo en el área de preparación, llamada también índice o index, listo para ser incluido en el siguiente commit.[cite:38]

Qué significa “preparar” un archivo

Preparar un archivo significa seleccionar el estado actual de su contenido para el próximo registro del historial. No es simplemente marcar el nombre del archivo; es decirle a Git: “esta versión de este contenido es la que quiero incluir en el siguiente commit”.[cite:38]

Esa idea conecta directamente con el capítulo anterior, donde viste la arquitectura conceptual de Git:

  • el archivo se modifica en el Working Directory;
  • luego su contenido se mueve al área de preparación;
  • después puede convertirse en parte del repositorio mediante un commit.

git add archivo

La forma más precisa de preparar cambios es indicar un archivo específico.

git add README.md

o

git add index.html

Esta opción es muy útil cuando quieres controlar exactamente qué parte del proyecto entrará en el próximo commit.[cite:42]

git add .

Otra forma habitual es preparar todos los archivos nuevos y modificados desde el directorio actual hacia abajo:

git add .

La hoja oficial de referencia de Git lo describe como una forma de añadir todos los archivos sin seguimiento y los cambios no preparados al área de preparación.[cite:42]

Es cómodo, pero conviene usarlo con criterio. Cuando el proyecto es pequeño puede ser práctico. Cuando el proyecto crece, puede incluir cambios que no querías registrar todavía.

La diferencia entre ambas formas

Comando Qué hace Cuándo conviene
git add archivo Prepara un archivo específico Cuando quieres control preciso.[cite:42]
git add . Prepara todo lo nuevo y modificado desde el directorio actual Cuando todos los cambios pertenecen al mismo paso lógico.[cite:42]

Qué ocurre dentro del área de preparación

Cuando ejecutas git add, Git toma una instantánea del contenido actual del archivo y la coloca en la zona de preparación, que el tutorial oficial llama index.[cite:38]

Eso tiene una consecuencia didáctica muy importante: si modificas el archivo otra vez después de usar git add, la nueva edición ya no estará automáticamente preparada. La instantánea preparada corresponde al momento en que ejecutaste git add. Si cambias el archivo después, tendrás que volver a prepararlo para que la nueva versión entre al próximo commit.[cite:38]

Un ejemplo muy claro con index.html

Supón este flujo:

  1. Escribes una primera versión de index.html.
  2. Ejecutas git add index.html.
  3. Luego cambias el título principal del archivo.
  4. Ejecutas git status.

Lo que verás es muy revelador: Git puede mostrar que parte del archivo está preparada y que al mismo tiempo existen modificaciones no preparadas. Esto ocurre porque el área de preparación tiene una instantánea anterior, mientras que el directorio de trabajo ya contiene una versión nueva.[cite:38]

Ese comportamiento puede parecer extraño al inicio, pero en realidad es una de las mayores fortalezas de Git: te permite decidir con precisión qué contenido quedará en el siguiente commit.

Flujo conceptual de preparación

Antes del diagrama, conviene resumir la lógica con la que Git mueve un cambio hacia el historial.

flowchart LR
    A[Working Directory] --> B[git add]
    B --> C[Staging Area]
    C --> D[git commit]
    D --> E[Local Repository]

Este flujo representa uno de los modelos más importantes de Git. El contenido nace en el directorio de trabajo, pasa por el área de preparación y finalmente queda registrado en el repositorio local mediante un commit.[cite:38]

Aplicación directa en el proyecto del libro

En el sitio web personal, utilizarás git add varias veces. Por ejemplo:

  • primero para preparar README.md;
  • después para preparar index.html;
  • luego para preparar cambios posteriores cuando mejores el contenido.

Esto te permitirá observar cómo Git no registra cambios por accidente. Exige una decisión consciente sobre qué se incluirá en el siguiente paso del historial.

Error común

Pensar que git add “sube” un archivo al repositorio de forma definitiva. En realidad, lo coloca en el área de preparación para que después pueda formar parte de un commit.[cite:38][cite:42]

¿Cuándo usar git add . y cuándo no?

Usa git add . cuando estés seguro de que todos los cambios actuales pertenecen a una misma unidad lógica de trabajo. Por ejemplo, si acabas de crear los archivos iniciales del proyecto y todo ese contenido corresponde al arranque del sitio, puede ser razonable.

En cambio, si has hecho cambios distintos —por ejemplo, documentación por un lado y modificaciones importantes del contenido web por otro—, puede ser mejor preparar archivos específicos para no mezclar cosas distintas en un solo commit.

Buenas prácticas

Preparar archivos con intención mejora la calidad del historial. Un historial limpio no nace en el commit; empieza desde cómo decides usar git add.

Breve conclusión: git add prepara contenido para el próximo commit. Entender esta etapa es esencial porque te enseña que Git no registra cambios automáticamente: primero los observas, luego los seleccionas y finalmente los incorporas al historial.

2.6 Creando el primer commit

Una vez que los archivos correctos están preparados, el siguiente paso es registrarlos en la historia del proyecto mediante un commit. La documentación oficial define el commit como la operación que almacena permanentemente el contenido del índice en el repositorio.[cite:38]

En otras palabras, el commit convierte la preparación en historia.

¿Qué representa un commit?

Un commit es un punto de referencia en la evolución del proyecto. No es simplemente “guardar”, ni tampoco una copia desordenada de todo lo que existe. Es un registro con significado: captura un estado concreto del proyecto y lo acompaña de un mensaje que explica qué se hizo.[cite:34][cite:38]

Esa idea es central. Un commit no debería representar cualquier cosa. Debería representar una unidad lógica de trabajo.

git commit

La forma básica es:

git commit

Según la hoja de referencia oficial, este comando crea un commit y abre el editor de texto para que escribas el mensaje correspondiente.[cite:42]

git commit -m

Otra forma muy habitual es escribir el mensaje directamente en la línea del comando:

git commit -m "Crear estructura inicial del proyecto"

La hoja oficial también documenta esta forma como una manera directa de crear el commit con un mensaje incluido.[cite:42]

El primer commit del proyecto

En el caso del libro, el primer commit debería representar el nacimiento del proyecto bajo Git. Si en la carpeta ya existen README.md e index.html, y ambos reflejan la estructura inicial del sitio web personal, entonces un mensaje razonable podría ser:

git commit -m "Crear estructura inicial del sitio web personal"

Ese mensaje tiene una ventaja importante: describe una acción concreta y coherente. No dice solo “primer commit”, que informa muy poco, sino qué contenido se está registrando realmente.

Qué hace bueno a un commit

Un buen commit reúne dos cualidades:

  1. Agrupa cambios que pertenecen a una misma idea.
  2. Explica esa idea con un mensaje claro.

Por ejemplo, si en un solo paso creaste el README.md y la primera versión de index.html, tiene sentido registrarlos juntos como inicio del proyecto.

Pero si, además de eso, cambiaste el título del sitio tres veces, corregiste errores tipográficos no relacionados y reescribiste media página, quizá convenga dividir mejor el trabajo para que el historial sea más comprensible.

Ejemplos buenos y malos

Tipo Mensaje de commit Evaluación
Bueno Crear estructura inicial del sitio web personal Claro y específico
Bueno Agregar README inicial del proyecto Explica la acción concreta
Bueno Actualizar contenido inicial de index.html Describe el cambio de forma útil
Malo cambios Demasiado vago
Malo arreglos No dice qué se hizo
Malo commit 1 No aporta contexto
Malo aaaa No tiene valor informativo

Por qué un commit debe ser una unidad lógica de trabajo

Piensa en el historial como una narración técnica del proyecto. Si cada commit representa una idea clara, el historial se puede leer y entender. Si cada commit mezcla muchas cosas sin relación o usa mensajes vacíos, el historial pierde valor.

En proyectos reales, esto importa mucho. Un historial claro ayuda a:

  • revisar qué se hizo;
  • identificar dónde apareció un problema;
  • entender la intención de cada cambio;
  • colaborar con otras personas de forma más ordenada.

Flujo de creación del primer commit

Antes del siguiente diagrama, conviene visualizar cómo un conjunto de archivos preparados se transforma en una entrada del historial.

flowchart TD
    A[README.md e index.html preparados] --> B[git commit]
    B --> C[Git registra un nuevo estado del proyecto]
    C --> D[El historial del repositorio comienza]

Este momento es importante porque marca el nacimiento real del historial del proyecto. Antes de este paso existía la carpeta y existía Git inicializado, pero todavía no había una historia registrada.

Ejemplo paso a paso aplicado al proyecto

Un recorrido razonable en esta sección sería:

  1. Verificar con git status que README.md e index.html existen y están en el estado esperado.[cite:38][cite:42]
  2. Preparar esos archivos con git add.[cite:38][cite:42]
  3. Confirmar nuevamente con git status que quedaron listos para commit.[cite:38]
  4. Ejecutar git commit -m con un mensaje claro.[cite:42]
  5. Consultar otra vez git status para verificar que el repositorio quedó limpio.[cite:38]

Ese flujo enseña algo muy importante: un commit no aparece por accidente. Es el resultado de observar, preparar y registrar.

Consejo

Antes de hacer un commit, pregúntate: “¿este conjunto de cambios cuenta una sola historia?”. Si la respuesta es sí, probablemente vas bien.

Qué ocurre después del commit

Después de crear un commit, Git conserva ese estado como parte del historial del repositorio. Los archivos pasan a formar parte de la historia registrada del proyecto. A partir de ahí, cualquier nueva modificación se comparará con ese estado ya guardado.[cite:38]

Ese es el momento en que el sitio web personal deja de ser solo una carpeta con archivos y se convierte, de verdad, en un proyecto con memoria.

Error común

Hacer un commit demasiado grande “para ahorrar tiempo”. Lo habitual es que eso complique la comprensión del historial y vuelva más difícil revisar cambios después.

Breve conclusión: un commit es una unidad lógica de historia. Registra un estado del proyecto con significado y, cuando está bien hecho, convierte el historial en una narración técnica clara y útil.

2.7 Consultando el historial

Una vez creado el primer commit, tu proyecto ya tiene historia. El siguiente paso es aprender a consultarla. Para eso Git ofrece, entre otras opciones, dos comandos esenciales:

git log

git log --oneline

La documentación oficial indica que git log permite ver el historial de cambios y que git log --oneline ofrece una vista más resumida.[cite:38][cite:42]

git log

git log muestra los commits del repositorio, normalmente en orden inverso al tiempo en que fueron creados: los más recientes aparecen primero.[cite:38]

Cuando lo ejecutas, Git presenta información como:

  • el identificador del commit;
  • el autor;
  • la fecha;
  • el mensaje del commit.[cite:38]

Eso significa que no solo ves “qué existe”, sino cómo fue construyéndose el proyecto.

git log --oneline

Esta variante comprime la salida en una línea por commit. La hoja de referencia oficial la incluye como una forma rápida de revisar el historial.[cite:42]

Resulta muy útil cuando el número de commits empieza a crecer, porque permite obtener una visión general sin tanta información detallada.

Cómo interpretar el historial

Cada entrada del historial representa un estado significativo del proyecto. Si en este capítulo haces varios commits relacionados con el sitio web personal, el historial podría contar algo como esto, de forma conceptual:

  • primero se creó la estructura inicial;
  • luego se añadió el README.md;
  • después se mejoró la página principal;
  • más tarde se corrigió contenido o se reorganizó el texto.

Eso es precisamente lo que vuelve valioso al historial: no solo muestra resultados, muestra evolución.

Los hashes, explicados de forma sencilla

En la salida de git log aparece un identificador largo compuesto por caracteres. La documentación oficial muestra ejemplos de estos nombres de commit y explica que puede usarse una parte inicial suficientemente larga para identificar uno de manera única.[cite:38]

Ese identificador suele llamarse hash de forma simplificada. En este capítulo basta con entenderlo como una huella digital del commit. Su función es permitir que Git identifique de manera precisa cada punto del historial.[cite:38]

No necesitas memorizar hashes ni comprender todavía cómo se calculan. Lo importante es reconocer que cada commit tiene una identidad única.

Un ejemplo aplicado al proyecto del libro

Supón que ya hiciste estos tres commits:

  • Crear estructura inicial del sitio web personal
  • Agregar descripción inicial al README
  • Actualizar contenido principal de index.html

Cuando ejecutes git log, verás esas entradas acompañadas de sus identificadores, autor y fecha. Si usas git log --oneline, verás una versión más compacta que te permitirá seguir la secuencia general del proyecto con rapidez.[cite:38][cite:42]

Una forma visual de entender la evolución

Antes del siguiente diagrama, observa el historial como una serie de puntos conectados que representan estados del proyecto.

flowchart LR
    A[Commit 1: estructura inicial] --> B[Commit 2: README inicial]
    B --> C[Commit 3: contenido inicial de index.html]
    C --> D[Commit 4: mejora del encabezado principal]

Este diagrama muestra una idea fundamental: el historial no es una pila de archivos aislados, sino una secuencia conectada de cambios significativos.

Por qué consultar el historial importa tanto

Aprender Git no consiste solo en registrar cambios, sino en poder leer la historia del proyecto. Cuando sabes consultar el historial, empiezas a comprender de verdad qué ventaja ofrece Git frente al método de guardar carpetas con nombres ambiguos.

En lugar de buscar a ciegas entre copias viejas, puedes revisar una secuencia ordenada de decisiones técnicas.[cite:38]

¿Sabías que...?

El tutorial oficial de Git explica que los commits pueden consultarse de varias formas y que incluso una parte inicial del identificador suele bastar para referirse a uno de manera única dentro del repositorio.[cite:38]

Una práctica recomendable desde ahora

Después de cada commit importante, acostúmbrate a revisar el historial. No hace falta hacerlo de manera obsesiva, pero sí lo suficiente para desarrollar intuición sobre cómo Git está construyendo la historia del proyecto.

Ese hábito vuelve visible algo que, de otro modo, podría quedar abstracto: cada cambio bien registrado fortalece la legibilidad del repositorio.

Breve conclusión: git log y git log --oneline te permiten leer la historia del proyecto. Gracias a ellos, el repositorio deja de ser solo una caja donde guardas cambios y se convierte en una línea de tiempo comprensible.

2.8 Buenas prácticas para los commits

Saber hacer commits no es lo mismo que hacerlos bien. Un historial útil depende en gran parte de la calidad de los mensajes y de la forma en que decides agrupar cambios.

La documentación oficial de git commit recomienda comenzar el mensaje con una línea breve que resuma el cambio, idealmente de no más de 50 caracteres, y dejar una descripción más amplia después si hace falta.[cite:34] Aunque en proyectos pequeños muchas veces se usa solo una línea, esa recomendación ya muestra una idea clave: el mensaje del commit debe comunicar con claridad.

Mensajes claros

Un buen mensaje responde, de forma breve y concreta, qué hizo ese commit.

Ejemplos correctos para nuestro proyecto:

  • Crear estructura inicial del sitio web personal
  • Agregar README inicial del proyecto
  • Actualizar título principal de index.html
  • Corregir texto de presentación en la página inicial

Estos mensajes funcionan porque describen una acción específica y conectada con el contenido real del proyecto.

Ejemplos incorrectos:

  • cambios varios
  • actualización
  • cosas nuevas
  • prueba
  • listo

Estos mensajes fallan porque obligan a adivinar qué ocurrió.

Frecuencia de commits

Una buena práctica general es hacer commits cada vez que completas una unidad lógica de trabajo. No demasiado pronto, pero tampoco tan tarde como para mezclar muchas cosas distintas en un solo bloque.

En el proyecto del libro, por ejemplo, tendría sentido hacer commits cuando:

  • queda lista la estructura inicial;
  • se crea el README.md con contenido básico;
  • index.html recibe una primera versión útil;
  • se hace una mejora concreta del contenido.

¿Cuándo realizar un commit?

Haz un commit cuando puedas responder claramente: “este cambio representa un avance identificable”.

Eso puede significar:

  • completar una parte del proyecto;
  • corregir algo puntual;
  • mejorar un archivo con un objetivo claro;
  • dejar el proyecto en un estado coherente y revisable.

No conviene hacer commits solo por ansiedad ni esperar hasta acumular una cantidad excesiva de cambios.

Qué evitar

Hay varios hábitos que conviene evitar desde el comienzo:

Qué evitar Por qué es mala idea
Commits con mensajes vagos Dificultan entender el historial
Un solo commit con demasiados cambios distintos Mezcla varias historias en una sola
Commits por cada mínimo movimiento irrelevante Rompen el ritmo y llenan el historial de ruido
Preparar todo con git add . sin revisar Puede incluir cambios no deseados.[cite:42]
No revisar git status antes de confirmar Aumenta el riesgo de registrar algo incorrecto.[cite:38]

Un criterio útil: una idea, un commit

No siempre será posible dividir el trabajo de manera perfecta, pero como regla mental funciona muy bien esta frase:

una idea, un commit.

Si el commit puede explicarse con una sola acción clara, el historial probablemente será más limpio y útil.

Ejemplo correcto e incorrecto con el proyecto del libro

Imagina dos formas de trabajar sobre el sitio web personal.

Forma correcta:

  1. Crear README.md con la descripción del proyecto.
  2. Hacer un commit específico para ese cambio.
  3. Después editar index.html para añadir el título y el párrafo inicial.
  4. Hacer otro commit enfocado en esa mejora.

Forma incorrecta:

  1. Crear README.md.
  2. Editar index.html.
  3. Cambiar el nombre del proyecto.
  4. Corregir errores tipográficos.
  5. Reescribir parte del contenido.
  6. Hacer un único commit llamado cambios.

En el segundo caso, el historial pierde claridad. Resulta mucho más difícil entender qué se hizo realmente y por qué.

La relación entre buenos commits y buenos proyectos

Un historial limpio no es solo una cuestión estética. Tiene efectos prácticos.

  • Facilita revisar avances.
  • Hace más claro el proceso de aprendizaje.
  • Ayuda a detectar errores.
  • Prepara el proyecto para trabajo colaborativo futuro.
  • Mejora la presentación profesional del repositorio.

Aunque este capítulo todavía no usa GitHub, ya conviene trabajar como alguien que sabe que su historial debe poder leerse y comprenderse.

Buenas prácticas

Antes de confirmar un commit, revisa dos cosas: el estado del proyecto con git status y la claridad del mensaje que vas a escribir.[cite:38][cite:34]

Mini guía para evaluar un commit antes de crearlo

Hazte estas preguntas:

  • ¿Todos los cambios preparados pertenecen a una sola idea?
  • ¿El mensaje explica claramente qué hiciste?
  • ¿El commit sería comprensible para otra persona dentro de una semana?
  • ¿Este punto del historial merece existir como referencia independiente?

Si la mayoría de las respuestas es sí, estás en buen camino.

Error común

Pensar que el mensaje del commit es un detalle sin importancia. En realidad, es la etiqueta humana que hace legible la historia técnica del proyecto.[cite:34][cite:38]

Breve conclusión: las buenas prácticas de commit convierten el historial en una herramienta útil, no solo en una acumulación de registros. Mensajes claros y cambios bien agrupados hacen que Git trabaje a tu favor desde el principio.

Práctica guiada

En esta práctica guiada aplicarás el flujo completo del capítulo sobre el proyecto real del libro: el sitio web personal. El objetivo es que el repositorio exista al terminar la actividad, con varios cambios registrados y un historial ya visible.

Paso 1: crear la carpeta del proyecto

Crea la carpeta sitio-web-personal en la ubicación donde trabajarás durante el libro. Esta será la base del proyecto continuo.

Paso 2: crear README.md

Dentro de la carpeta, crea el archivo README.md con una presentación breve del proyecto. El objetivo es documentar desde el inicio qué representa este sitio web.

Ejemplo:

# Sitio Web Personal

Proyecto base del libro Git y GitHub Profesional.

Paso 3: crear index.html

Agrega una primera versión simple de la página principal del sitio web personal.

Ejemplo:

<!DOCTYPE html>
<html lang="es">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Mi Sitio Web Personal</title>
</head>
<body>
  <h1>Hola, soy tu nombre</h1>
  <p>Bienvenido a mi sitio web personal.</p>
</body>
</html>

Paso 4: inicializar Git

Entra en la carpeta del proyecto y ejecuta:

git init

Con esto, la carpeta quedará convertida en repositorio Git y aparecerá la estructura interna .git.[cite:38][cite:42]

Paso 5: revisar el estado inicial

Ejecuta:

git status

Comprueba que Git detecta los archivos del proyecto y observa si aparecen como archivos sin seguimiento.[cite:38]

Paso 6: preparar los archivos iniciales

Ahora prepara el contenido para el primer commit. Puedes hacerlo archivo por archivo o preparar todo el contenido inicial si pertenece a una sola unidad lógica de trabajo.[cite:42]

Ejemplos:

git add README.md

git add index.html

O bien:

git add .

Paso 7: verificar el estado antes del commit

Vuelve a ejecutar:

git status

La idea es comprobar que los archivos están listos para formar parte del primer commit.[cite:38]

Paso 8: crear el primer commit

Registra el inicio del proyecto con un mensaje claro:

git commit -m "Crear estructura inicial del sitio web personal"

Con este paso comienza oficialmente el historial del proyecto.[cite:38][cite:42]

Paso 9: realizar una mejora sencilla en README.md

Edita README.md y agrega una línea adicional, por ejemplo una breve descripción más clara del propósito del sitio.

Luego revisa el estado:

git status

Observa cómo Git detecta el archivo como modificado.[cite:38]

Paso 10: preparar y registrar ese cambio

Prepara el archivo actualizado y crea un nuevo commit con un mensaje específico.

Ejemplos:

git add README.md

git commit -m "Agregar descripción inicial al README"

Paso 11: mejorar index.html

Haz una pequeña mejora en la página principal, como cambiar el párrafo de bienvenida o mejorar el encabezado principal.

Luego repite el flujo:

git status

git add index.html

git commit -m "Actualizar contenido inicial de index.html"

Paso 12: consultar el historial

Finalmente, revisa el historial completo y su versión resumida:

git log

git log --oneline

Deberías ver una secuencia de commits que cuenta el inicio del proyecto.[cite:38][cite:42]

Resultado esperado de la práctica

Al terminar, habrás completado esta lista:

  • Crear la carpeta del proyecto.
  • Inicializar Git.
  • Crear el archivo README.md.
  • Agregar un archivo index.html.
  • Registrar varios cambios con commits.
  • Consultar el historial.
  • Verificar el estado del proyecto.

Vista global del ciclo básico de Git

Antes del cierre del capítulo, este diagrama resume el flujo esencial que acabas de practicar.

flowchart LR
    A[Crear o modificar archivos] --> B[git status]
    B --> C[git add]
    C --> D[git commit]
    D --> E[git log]

Este ciclo representa la base operativa de Git para un proyecto local: trabajar, observar, preparar, registrar y revisar.[cite:38][cite:42]

[Ilustración: secuencia visual de cinco pasos del proyecto sitio-web-personal, mostrando creación de archivos, revisión de estado, preparación en staging, creación de commit y consulta del historial, con diseño limpio tipo manual técnico moderno]

Breve conclusión: la práctica guiada convierte la teoría en experiencia. Ya no solo sabes qué es un repositorio: ahora has creado uno real y has comenzado el historial del proyecto principal del libro.

Cierre del capítulo

En este capítulo diste uno de los pasos más importantes de todo el libro: crear el primer repositorio del proyecto principal. A partir de una carpeta sencilla, la convertiste en un repositorio Git, registraste los primeros archivos del sitio web personal y comenzaste a construir un historial real de trabajo.[cite:38][cite:42]

También aprendiste el ciclo básico que usarás una y otra vez: observar el estado del proyecto, preparar cambios, crear commits y revisar el historial. Esa secuencia es pequeña en apariencia, pero constituye la base práctica del control de versiones moderno.[cite:38][cite:34][cite:42]

Todavía no has conectado el proyecto con GitHub, y eso es correcto. En esta etapa el objetivo era dominar primero el flujo local y comprender cómo nace la historia de un proyecto dentro de Git. El siguiente capítulo ampliará ese trabajo llevando el repositorio hacia un entorno compartido.[cite:38][cite:42]

Bibliografía