¿Qué es .gitignore?: Cuándo y por qué usarlo

El archivo .gitignore es un archivo de texto que indica a Git qué archivos o directorios debe ignorar y no rastrear en el repositorio. Sirve para excluir archivos temporales, configuraciones locales o generados automáticamente que no deben formar parte del historial del proyecto.

Cuando desarrollamos un proyecto, es normal que se generen archivos específicos del entorno local, como logs, archivos de configuración personal o binarios compilados. Si incluimos estos archivos en el repositorio puede desde ocurrir conflictos, aumentar innecesariamente el tamaño del repositorio o hasta exponer información sensible. Si utilizamos .gitignore mantenemos el repositorio enfocado únicamente en el código.

Lo mejor es configurar el archivo .gitignore desde el comienzo del proyecto para evitar que ciertos archivos se añadan al repositorio. Una vez que un archivo ha sido rastreado por Git, añadirlo al .gitignore no lo eliminará del historial.

El .gitignore también facilita la colaboración en equipos ya que al especificar qué archivos deben ser ignorados, se previene que otros colaboradores suban archivos innecesariosde su entorno local.

Patrones básicos y wildcards: Ignorar múltiples archivos y carpetas

El archivo .gitignore utiliza patrones y comodines (wildcards) para controlar qué archivos y carpetas deben ser ignorados por Git. Esto permiten especificar reglas para excluir múltiples elementos sin tener que enumerarlos individualmente.

El comodín más común es el asterisco (*), que representa cualquier secuencia de caracteres. Por ejemplo, para ignorar todos los archivos con extensión .log, se añade al .gitignore la siguiente línea:

*.log

Esto indica a Git que ignore todos los archivos que terminen con .log, independientemente de su nombre.

Para ignorar todos los archivos dentro de una carpeta específica, se puede usar el nombre de la carpeta seguido de una barra y un asterisco. Si se quiere excluir todo el contenido del directorio temp/, se agrega:

temp/*

De este modo, Git ignorara todos los archivos y subdirectorios dentro de temp/ y el repositorio no tendrá archivos temporales.

El doble asterisco (**) se utiliza para representar recursivamente cualquier directorio o archivo en múltiples niveles. Si se necesita ignorar todos los archivos .cache en cualquier subcarpeta, se añade:

**/*.cache

Esto asegura que todos los archivos con extensión .cachesean ignorados, independientemente de su ubicación en el proyecto.

Para excluir carpetas enteras, se escribe el nombre de la carpeta seguido de una barra:

/build/

Esta línea indica a Git ignorar el directorio build/ y todo su contenido, muy útil para excluir archivos generados en la compilación.

Es posible combinar comodines para patrones más específicos. Si se quiere ignorar todos los archivos que comienzan con temp y terminan con .txt, se utiliza:

temp*.txt

Con esta regla, archivos como temp1.txt o temporary.txt se ignoran.

Para excepciones, el signo de exclamación (!) permite incluir archivos o carpetas que previamente fueron ignorados por otra regla. Por ejemplo, si se quieren ignorar todos los archivos .xml excepto config.xml, se escribe:

*.xml
!config.xml

Git ignora todos los archivos .xml, pero sigue rastreando config.xml.

El carácter de interrogación (?) reemplaza a un solo carácter. Si se necesita ignorar archivos como log1.txt, log2.txt, pero no log10.txt, se utiliza:

log?.txt

Esto ignora log1.txt hasta log9.txt, pero no afecta a log10.txt.

Para ignorar archivos o carpetas que empiezan con un punto, como .env o .cache, se puede especificar:

.* 

Esta regla excluye todos los archivos y directorios ocultos de nivel superior. Para ser más específico y solo ignorar .env, escribes:

.env

Hay que prestar atención al uso de barras inclinadas para definir rutas relativas. Una barra inicial (/) indica la raíz del repositorio. Por ejemplo, para ignorar únicamente el archivo /todo.txt en la raíz y no otros archivos con el mismo nombre en subdirectorios:

/todo.txt

Git evalúa las reglas en el orden en que aparecen en el .gitignore. Por eso mismo, las excepciones deben colocarse después de las reglas que las incluyen.

Creación y estructura del archivo: Ubicación y sintaxis comunes

El archivo .gitignore es un archivo de texto plano que debe estar nombrado exactamente como .gitignore, sin extensiones ni nombres adicionales.

La forma más fácil de crear el archivo es con un editor de texto. Por ejemplo, en la terminal, se puede ejecutar:

touch .gitignore

Esto creará un archivo vacío llamado .gitignore en el directorio actual. Luego, se abre con un editor y se añaden las reglas necesarias para ignorar los archivos o directorios que se quieran.

La ubicación del archivo .gitignore influye en cómo Git aplica las reglas. De normal se coloca en la raíz del repositorio, para definir reglas globales que afectan a todo el proyecto. Sin embargo, también se puede tener archivos .gitignore en subdirectorios específicos. Pero hay que tener en cuenta que las reglas dentro de estos archivos se aplicarán sólamente a los archivos y carpetas dentro de ese subdirectorio.

Las rutas especificadas en el .gitignore son relativas al directorio donde se encuentra el archivo. Por ejemplo, si tienes un archivo /config/secret.txt y el .gitignore está en la raíz del repositorio, para ignorar este archivo debes añadir:

config/secret.txt

La sintaxis común en el archivo .gitignore incluye varias características que permiten una configuración flexible:

• Comentarios: Las líneas que comienzan con el carácter # son consideradas comentarios. Útil para explicar el propósito de reglas o secciones dentro del archivo.

# Ignorar archivos de configuración locales

Líneas en blanco: Las líneas vacías son ignoradas por Git. Sirven para mantener organización y legibilidad.

Patrones con barras inclinadas: Una barra inclinada (/) al inicio o al final de un patrón indica una ruta específica o un directorio. Por ejemplo, para ignorar únicamente el directorio logs en la raíz:

/logs/

• Negaciones: Utilizando el signo de exclamación (!), se puede indicar que Git no debe ignorar un archivo o directorio que previamente había sido excluido por otra regla. Esto es útil para excepciones específicas.

# Ignorar todos los archivos .txt
*.txt

# Excepto README.txt
!README.txt

• Comodines y patrones avanzados: Se pueden utilizar patrones como * y ? para crear reglas que abarquen varios archivos o directorios.

Además del archivo .gitignore específico del proyecto, Git permite definir un archivo global de exclusión para el usuario. Esto sirve para ignorar archivos que no deberían ser rastreados en ningún repositorio, como archivos generados por el sistema operativo. Para configurar un .gitignore global se ejecuta el siguiente comando:

git config --global core.excludesfile ~/.gitignore_global

Luego, se crea el archivo ~/.gitignore_global y se añaden las reglas deseadas. Por ejemplo:

# Archivos de sistema macOS
.DS_Store

# Archivos de Thumbnails en Windows
Thumbs.db

# Archivos de respaldo generados por editores
*~

Algunas buenas prácticas para estructurar el archivo .gitignore son:

• Agrupar reglas por categoría: Ordena las reglas de manera que las relacionadas estén juntas. Por ejemplo, agrupa todas las reglas que ignoran archivos de log, archivos de compilación o configuraciones de IDE.

# Archivos de log
*.log
logs/
/logs

# Archivos de compilación
/build/
/dist/

# Configuraciones de IDE
.vscode/
.idea/

Añadir comentarios: Explica el propósito de las reglas o grupos de reglas, lo que facilita la comprensión y el mantenimiento del archivo por parte de otros colaboradores.

Evitar reglas redundantes: Revisa las reglas para asegurarte de que no se estén repitiendo o que no haya patrones que se solapen innecesariamente.

Actualizar el .gitignore cuando sea necesario: A medida que el proyecto evoluciona, pueden aparecer nuevos archivos o directorios que deban ser ignorados. Es importante mantener el .gitignore actualizado para reflejar estos cambios.

El archivo .gitignore forma parte del repositorio y debe ser añadido al control de versiones mediante git add .gitignore.

Otra cosa a tener en cuenta es que si un archivo ya ha sido rastreado por Git, añadirlo al .gitignore no hará que Git lo ignore retroactivamente. En esos casos, es necesario dejar de rastrear el archivo con:

git rm --cached nombre_del_archivo

Y luego confirmar el cambio con un commit para asegurar que el archivo se elimine del repositorio pero permanezca en el directorio de trabajo sin ser eliminado físicamente.

Caso práctico: usar gitignore en archivo .env en Python con dotenv

En este caso práctico, se va a ver cómo utilizar .gitignore para evitar que Git rastree el archivo .env en un proyecto de Python que utiliza la biblioteca dotenv. Al manejar información sensible como claves API o contraseñas, es necesario asegurarse de que estos datos no se suban al repositorio.

Supongamos que estamos desarrollando una aplicación en Python que requiere acceder a una base de datos y a servicios externos. Para gestionar las variables de entorno, utilizamos la biblioteca python-dotenv, que permite cargar automáticamente las variables definidas en un archivo .env.

El archivo .env podría contener información confidencial como:

API_KEY=123456789abcdef
DB_PASSWORD=mi_contraseña_segura
SECRET_KEY=clave_ultra_secreta

Este archivo .env no puede incluirse en el control de versiones, así que añadimos .env al archivo .gitignore en la raíz del proyecto:

# Archivos de configuración locales
.env

De esta manera, Git ignora el archivo .env y evita que sea rastreado y subido al repositorio. Si el archivo .env ya había sido añadido previamente, es necesario removerlo del index de Git con:

git rm --cached .env

Este comando elimina el archivo .env del seguimiento de Git pero lo mantiene en el sistema de archivos local. A continuación, realizamos un commit para reflejar los cambios:

git commit -m "Agrega .env a .gitignore y elimina del seguimiento"

Para facilitar la configuración a otros desarrolladores, se recomienda dar un archivo de ejemplo llamado .env.example:

API_KEY=tu_api_key
DB_PASSWORD=tu_contraseña
SECRET_KEY=tu_clave_secreta

Incluimos .env.example en el repositorio para que sirva como plantilla. Los colaboradores pueden copiar este archivo y renombrarlo a .env, añadiendo sus propias credenciales. En el archivo README.md, indicamos los pasos para configurar el entorno:

## Configuración del entorno

Crea un archivo **.env** en la raíz del proyecto:

    ```bash
    cp .env.example .env
    ```

Edita **.env** y proporciona tus credenciales:
- `API_KEY`: clave de acceso a la API.
- `DB_PASSWORD`: contraseña de la base de datos.
- `SECRET_KEY`: clave secreta para la aplicación.

En el código de la aplicación cargamos las variables de entorno utilizando python-dotenv:

from dotenv import load_dotenv
import os

# Cargar las variables del archivo .env
load_dotenv()

API_KEY = os.getenv('API_KEY')
DB_PASSWORD = os.getenv('DB_PASSWORD')
SECRET_KEY = os.getenv('SECRET_KEY')

# Verificar que las variables se han cargado correctamente
if not API_KEY or not DB_PASSWORD or not SECRET_KEY:
    raise EnvironmentError("Faltan variables de entorno necesarias")

Con load_dotenv(), las variables definidas en .env se añaden al entorno de ejecución. Accedemos a ellas con os.getenv(). Se recomienda verificar que se hayan cargado correctamente para evitar errores en tiempo de ejecución.

Al excluir el archivo .env del repositorio, estamos protegiendo información confidencial y mantenemos el código seguro. Además, al proporcionar un .env.example y actualizar la documentación, facilitamos la configuración a otros miembros del equipo sin crear problemas de seguridad.

Hay que recordar que nunca debemos compartir el archivo .env en ningún sitio público ni en repositorios.