Ciclo de vida

Inicializar repositorio git y ver estado

La inicialización de un repositorio Git es el primer paso para comenzar a versionar cualquier proyecto. Este proceso transforma una carpeta ordinaria en un repositorio Git funcional, creando toda la infraestructura necesaria para el seguimiento de cambios.

Creando un repositorio desde cero

Para inicializar un nuevo repositorio Git, utilizamos el comando git init dentro del directorio que queremos versionar:

mkdir mi-proyecto
cd mi-proyecto
git init

Al ejecutar git init, Git crea una carpeta oculta llamada .git en el directorio actual. Esta carpeta contiene toda la base de datos del repositorio, incluyendo el historial de commits, configuración local, referencias a ramas y metadatos del proyecto.

ls -la
# Salida:
# drwxr-xr-x  3 usuario grupo  96 Nov 15 10:30 .
# drwxr-xr-x  5 usuario grupo 160 Nov 15 10:29 ..
# drwxr-xr-x  9 usuario grupo 288 Nov 15 10:30 .git

La carpeta .git es el corazón del repositorio. Su eliminación significaría perder todo el historial de versiones, por lo que nunca debe modificarse manualmente. Git gestiona automáticamente su contenido interno.

Verificando el estado del repositorio

Una vez inicializado el repositorio, el comando git status se convierte en nuestra herramienta principal para monitorear el estado de los archivos:

git status

En un repositorio recién creado, la salida será similar a:

On branch main

No commits yet

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

Esta salida nos proporciona información crucial:

• Rama actual: Estamos en la rama main (rama por defecto)
• Estado de commits: No hay commits todavía en el historial
• Archivos para seguimiento: No hay archivos siendo rastreados

Añadiendo archivos al proyecto

Creemos algunos archivos para observar cómo cambia el estado del repositorio:

echo "# Mi Proyecto" > README.md
echo "console.log('Hola mundo');" > app.js

Ahora ejecutamos nuevamente git status:

git status

La salida mostrará:

On branch main

No commits yet

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

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

Los archivos aparecen como "Untracked files" (archivos no rastreados). Git detecta su existencia pero no los está siguiendo todavía. Para que Git comience a versionar estos archivos, debemos añadirlos explícitamente al área de preparación.

Interpretando la información de estado

El comando git status proporciona información detallada sobre tres áreas importantes:

• Working Directory: Los archivos en tu directorio de trabajo actual
• Staging Area: Los archivos preparados para el próximo commit
• Repository: Los archivos ya confirmados en el historial

Además, git status incluye sugerencias útiles sobre los comandos que puedes ejecutar según el estado actual. Por ejemplo, sugiere usar git add <file> para comenzar a rastrear archivos nuevos.

Para obtener una versión más concisa del estado, puedes usar la opción -s o --short:

git status -s

Esta versión abreviada muestra cada archivo con códigos de dos caracteres que indican su estado:

?? README.md
?? app.js

Los símbolos ?? indican archivos no rastreados. A medida que trabajemos con Git, veremos otros símbolos como A (añadido), M (modificado), o D (eliminado).

El comando git status debe convertirse en un hábito constante durante el desarrollo. Te ayuda a mantener control sobre qué cambios estás a punto de confirmar y evita sorpresas desagradables en tu historial de versiones.

Staging y commit

Una vez que Git detecta archivos en nuestro directorio de trabajo, necesitamos prepararlos para el commit a través del área de staging. Este proceso de dos pasos nos permite seleccionar exactamente qué cambios queremos incluir en cada versión de nuestro proyecto.

Añadiendo archivos al área de staging

El comando git add mueve archivos desde el directorio de trabajo al área de preparación (staging area). Podemos añadir archivos de forma individual:

git add README.md

Después de ejecutar este comando, git status mostrará:

On branch main

No commits yet

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

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

El archivo README.md ahora aparece bajo "Changes to be committed", indicando que está preparado para ser incluido en el próximo commit. El archivo app.js permanece como no rastreado.

Para añadir múltiples archivos simultáneamente, podemos usar diferentes enfoques:

# Añadir archivos específicos
git add README.md app.js

# Añadir todos los archivos del directorio actual
git add .

# Añadir todos los archivos con una extensión específica
git add *.js

Creando el primer commit

Un commit representa una instantánea completa del estado de nuestro proyecto en un momento específico. Para crear un commit, utilizamos git commit con la opción -m para incluir un mensaje descriptivo:

git add .
git commit -m "Añadir archivos iniciales del proyecto"

La salida del comando será similar a:

[main (root-commit) a1b2c3d] Añadir archivos iniciales del proyecto
 2 files changed, 2 insertions(+)
 create mode 100644 README.md
 create mode 100644 app.js

Esta información nos indica:

• Hash del commit: a1b2c3d (identificador único abreviado)
• Rama: main
• Tipo: root-commit (primer commit del repositorio)
• Estadísticas: 2 archivos cambiados, 2 líneas insertadas

Verificando el estado después del commit

Tras realizar el commit, ejecutar git status mostrará:

On branch main
nothing to commit, working tree clean

El mensaje "working tree clean" indica que no hay cambios pendientes entre el directorio de trabajo, el área de staging y el último commit. Todos los archivos están sincronizados.

Modificando archivos existentes

Cuando modificamos un archivo ya rastreado por Git, el comportamiento del staging cambia ligeramente. Modifiquemos el archivo README.md:

echo "Este es un proyecto de ejemplo" >> README.md

Al ejecutar git status:

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

no changes added to commit (use "git add" to stage changes)

El archivo aparece bajo "Changes not staged for commit", indicando que Git detecta modificaciones pero estas no están preparadas para el commit. Necesitamos usar git add nuevamente:

git add README.md
git commit -m "Actualizar descripción del proyecto"

Commits con mensajes descriptivos

Los mensajes de commit son fundamentales para mantener un historial comprensible. Un buen mensaje debe ser conciso pero descriptivo:

# Mensaje claro y específico
git commit -m "Corregir error de sintaxis en función de validación"

# Evitar mensajes vagos
git commit -m "Cambios varios"

Para mensajes más largos, puedes omitir la opción -m y Git abrirá tu editor predeterminado:

git commit

Staging selectivo de cambios

Git permite añadir cambios específicos dentro de un archivo usando la opción -p (patch):

git add -p README.md

Esta opción te permite revisar cada cambio individualmente y decidir si incluirlo en el staging area. Es especialmente útil cuando has realizado múltiples modificaciones en un archivo pero solo quieres commitear algunas de ellas.

Verificando el historial de commits

Para visualizar el historial de commits creado, utilizamos:

git log --oneline

Este comando muestra una lista concisa de todos los commits:

b2c3d4e Actualizar descripción del proyecto
a1b2c3d Añadir archivos iniciales del proyecto

Cada línea muestra el hash abreviado del commit seguido del mensaje, proporcionando una vista rápida de la evolución del proyecto.

El flujo staging-commit se convierte en el ritmo natural del desarrollo con Git: modificas archivos, los añades al staging area, y creas commits que representan unidades lógicas de cambio en tu proyecto.