El trabajo diario con Git

En este artículo aprenderá el ciclo de trabajo básico que se repite todos los días: obtener una copia del proyecto, guardar los cambios (commit), enviarlos a GitHub (push) y configurar qué archivos innecesarios se ignoran con .gitignore. Es el mismo ciclo que Claude Code recorre por usted cuando trabaja con un repositorio, así que entenderlo le sirve por partida doble.

Los ejemplos y las capturas de pantalla corresponden a los IDE de JetBrains; los nombres de las acciones y su ubicación pueden variar en su versión. Para los ejercicios, use un repositorio de práctica aparte. En un proyecto de trabajo, siga sus reglas sobre ramas, commits y envío de cambios.

Clonar un proyecto

Ya tiene un repositorio en GitHub y ahora necesita una copia local en su ordenador para empezar a trabajar. Este proceso se llama clonación.

Paso 1. Abra el IDE. Si hay algún proyecto abierto, ciérrelo con File | Close Project. En la ventana de inicio (Welcome Screen), elija Clone Repository (o Get from VCS).

Paso 2. En la ventana que se abre, pegue la URL del repositorio. Esta opción es cómoda si clona el repositorio de otra persona: la URL se copia de la página del repositorio en GitHub.

Si clona su propio repositorio, lo más sencillo es iniciar sesión en GitHub directamente desde el IDE con Log in to GitHub. El IDE abrirá el navegador para la autorización.

En la página que se abre, pulse el botón verde Authorize JetBrains. A partir de ese momento podrá elegir sus repositorios directamente de una lista en el IDE. Seleccione el proyecto que necesita y pulse Clone.

Paso 3. Decida si confía en el proyecto. Si es su propio repositorio y lo conoce bien, puede elegir Trust Project. Si es desconocido, revise primero su contenido y las instrucciones para ejecutarlo: confiar en él permite que el IDE ejecute acciones del proyecto.

Paso 4. Abra el proyecto. En Windows, el IDE puede proponer exclusiones del antivirus para acelerar la indexación. Para aprender Git no son necesarias; no desactive la protección solo para clonar un repositorio.

Guardar cambios - commit

Un commit es una instantánea, el estado guardado del proyecto en un momento concreto. Piense en él como en un punto de guardado de un videojuego: siempre puede volver a él si algo sale mal. Cada commit tiene un identificador único y un mensaje que describe los cambios.

Así es un historial de commits: cada commit nuevo se construye sobre el anterior, y juntos forman la cronología de cómo ha evolucionado el proyecto.

Paso 1. Haga cambios. Abra el archivo README.md y añada una descripción del proyecto. En cuanto empiece a editarlo, el IDE mostrará su nombre en azul en el panel del proyecto: el archivo ha cambiado, pero los cambios todavía no están guardados en Git. Junto a las líneas modificadas, el IDE mostrará una barra de color: verde para las líneas añadidas y azul para las modificadas.

Abra la pestaña Commit y revise los archivos modificados. En el modo habitual de JetBrains se muestran como listas de cambios (changelists); el área de staging de Git hay que activarla aparte en la configuración. No confunda las casillas que marca en esta ventana con un índice que ya haya preparado en la terminal.

Esto es lo que vemos:

• Changes - archivos que Git ya sigue y que se han modificado (en nuestro caso, README.md);
• Unversioned Files - archivos nuevos que Git ve en la carpeta del proyecto, pero que todavía no sigue.

Paso 2. Revise el diff seleccionado. Los archivos nuevos de Unversioned Files todavía no tienen seguimiento. Los resultados de compilación, la caché y la configuración personal suelen excluirse con .gitignore. La configuración compartida del proyecto puede guardarse en Git, así que revise las reglas del proyecto antes de ignorar la carpeta .idea/ entera.

Paso 3. Haga el commit. Escriba un mensaje claro, por ejemplo docs: Describe the project in README, revise el diff seleccionado y pulse Commit. Si hay comprobaciones previas al commit activadas, espere el resultado. Abra Git Log y compruebe que el commit nuevo contiene el archivo que quería incluir.

Enviar cambios a GitHub - push

Por ahora sus commits solo están en su ordenador. Para compartirlos con el equipo o guardarlos en un lugar seguro, hay que enviarlos al repositorio remoto en GitHub.

Push actualiza la rama remota seleccionada con sus commits. No descarga el trabajo de otras personas ni envía archivos sin commit.

Paso 1. Pulse Push. El botón Push está en la barra superior principal (Main Toolbar) y tiene forma de flecha hacia arriba y a la derecha.

Paso 2. Revise y confirme. Se abrirá una ventana con todos los commits listos para enviar. Es la última oportunidad de asegurarse de que envía exactamente lo que quiere. Pulse Push.

Cuando el envío termine bien, el IDE mostrará una notificación. Compruebe en ella el repositorio y la rama de destino: en este ejercicio es origin/main. El texto de la notificación depende de la versión del IDE.

Paso 3. Compruebe el resultado en GitHub. Abra la página del repositorio en GitHub en el navegador: verá que sus cambios y archivos ya están allí.

Panel de control de Git

El IDE tiene una ventana de herramientas Git propia, además de acciones rápidas en la barra superior. Es su centro de control de versiones. Los botones principales:

• Commit (marca de verificación) - abre el panel para guardar cambios;
• Push (flecha hacia arriba y a la derecha) - la ventana para enviar commits a GitHub;
• Branches - el widget para gestionar ramas (en la esquina superior izquierda);
• Show Git Log - todo el historial de commits del proyecto, su propia máquina del tiempo.

Obtener actualizaciones

Update Project obtiene los cambios y los integra en la rama local; el IDE usa merge o rebase según la configuración. Antes de actualizar, guarde el trabajo sin terminar y compruebe qué método de actualización está seleccionado.

Antes de una tarea nueva, revise el estado de los archivos y si la rama que necesita está al día. Si han aparecido commits de otras personas, obténgalos e intégrelos según las reglas del proyecto. Actualizar puede obligarle a resolver conflictos, y tampoco garantiza que no vuelvan a aparecer más adelante.

Ignorar archivos innecesarios - .gitignore

Si en el proyecto aparecen archivos auxiliares o resultados de compilación y no quiere que acaben en el repositorio por accidente, hay que añadirlos a las exclusiones. Para ello, en la raíz del proyecto se crea un archivo especial llamado .gitignore.

Qué se suele ignorar y por qué

Casi cualquier stack tiene archivos que no deben ir a Git, porque son propios de su ordenador o se generan de nuevo en cada compilación:

• carpetas de compilación (por ejemplo build/, dist/) - resultados de la compilación que es fácil volver a generar;
• caché del gestor de paquetes y dependencias (por ejemplo node_modules/) - pueden ocupar cientos de megabytes y son propios de su sistema;
• la configuración personal del IDE, por ejemplo el estado de la ventana de trabajo. En .idea/ también puede haber configuración compartida del proyecto, así que ignorar la carpeta entera solo tiene sentido si esa es la regla acordada en el proyecto;
• archivos del sistema operativo (.DS_Store, Thumbs.db) - basura auxiliar que el sistema operativo crea automáticamente.

Cómo añadir un archivo a la lista de ignorados a mano:

Paso 1. Supongamos que ha creado un archivo local notes.txt con notas en borrador. Haga clic derecho sobre él en el árbol del proyecto.

Paso 2. Vaya al menú Git -> Add to .gitignore -> Add to .gitignore. Esta opción añadirá el archivo seleccionado al .gitignore de la raíz del proyecto.

Si todavía no existe un archivo .gitignore, el IDE le propondrá crearlo: acepte.

Paso 3. El IDE añadirá automáticamente el nombre del archivo a .gitignore.

Un archivo sin seguimiento que coincida con la regla normalmente desaparecerá de la lista de archivos para añadir; el color en el IDE depende del tema. Esto no impide añadirlo de forma forzada ni sirve para quitar del historial lo que ya se guardó. Haga commit del propio .gitignore si la regla debe aplicarse a todo el equipo.

Reglas de .gitignore

En el archivo se indican patrones de nombres de archivos y carpetas que Git debe ignorar. Las líneas vacías se ignoran, y un comentario empieza con el símbolo #.

• * - sustituye cualquier cantidad de caracteres. Por ejemplo, *.log ignora todos los archivos con la extensión .log;
• / al final de un patrón indica un directorio. Por ejemplo, build/ ignora todo el contenido de la carpeta build;
• ! al principio de la línea invierte la regla. Por ejemplo, con la regla *.log, la línea !important.log excluye ese archivo de la regla de ignorado; empezará a tener seguimiento después de añadirlo;
• ** entre barras coincide con cualquier número de carpetas anidadas, incluso con ninguna. Por ejemplo, logs/**/*.log encontrará tanto logs/a.log como logs/2026/09/a.log.

Ejemplo de archivo .gitignore

# Carpetas de compilación y caché
build/
dist/
node_modules/

# Estado personal del IDE (JetBrains)
.idea/workspace.xml

# Archivos del sistema operativo
.DS_Store
Thumbs.db

Plantillas listas

No hace falta escribir estos archivos desde cero. Existen plantillas listas y probadas por la comunidad:

1. la colección de .gitignore de GitHub para distintos lenguajes y frameworks: https://github.com/github/gitignore;
2. gitignore.io - un servicio web que genera un .gitignore para sus tecnologías (basta con escribir el lenguaje, el sistema operativo y el IDE).

Cómo funciona junto con Claude Code

El ciclo diario es justo lo que Claude Code sabe recorrer por usted. Esto es lo que conviene vigilar:

• Claude puede hacer el commit y el push por su cuenta; usted comprueba qué ha entrado en el commit y lee el mensaje;
• un .gitignore bien cuidado ayuda a excluir lo que sobra, pero los archivos seleccionados hay que revisarlos igualmente antes del commit;
• antes de actualizar, usted revisa el estado de la rama y el trabajo sin terminar, y después, el resultado de la integración.

Artículo anterior: Introducción a Git y GitHub · Artículo siguiente: Ramas y fusión en Git