Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Guía git base

Git para principiantes, control de versiones esencial.

Universidad Nacional de Río Negro

¿Por qué usar Git?

Git es un sistema de control de versiones distribuido que te permite llevar un registro detallado de los cambios en tu código. Es como tener un “historial de cambios” súper poderoso que no solo guarda qué cambió, sino también quién lo cambió, cuándo y por qué.

Esta guía te llevará desde la Instalación hasta dominar los Comandos esenciales para uso diario para uso diario, incluyendo cómo trabajar con Trabajando con repositorios remotos como GitHub. Al final entenderás perfectamente el Flujo de trabajo básico que usan los desarrolladores profesionales.

Ventajas del control de versiones

Conceptos fundamentales

Antes de empezar a usar Git, es importante entender algunos conceptos clave. Estos conceptos aparecerán constantemente cuando uses los Comandos esenciales para uso diario y entender bien la diferencia entre el Working Directory (Directorio de trabajo), Staging Area (Área de preparación) y los commit es fundamental para dominar Git.

Repositorio (repo)

Es una carpeta de proyecto que Git está “controlando”. Contiene todos los archivos de tu proyecto más un historial completo de sus cambios.

commit

Es como una “foto” de tu proyecto en un momento específico. Cada commit tiene:

Working Directory (Directorio de trabajo)

Es donde tenés los archivos en los que estás trabajando actualmente.

Staging Area (Área de preparación)

Es un espacio intermedio donde “preparás” los cambios antes de confirmarlos con un commit.

Estados de los archivos

Instalación y configuración inicial

Instalación

En Linux (Ubuntu/Debian):

sudo apt update
sudo apt install git

En Linux (CentOS/RHEL/Fedora):

sudo dnf install git

En macOS:

# Con Homebrew
brew install git

# O usar el que viene con Xcode
xcode-select --install

En Windows:

Configuración inicial

Antes de usar Git por primera vez, configurá tu identidad. Esta información aparecerá en todos los commit que hagas:

git config --global user.name "Tu Nombre"
git config --global user.email "tu.email@ejemplo.com"

Configuraciones útiles adicionales:

1
2
3
4
5
6
7
8
9
# Editor por defecto (opcional)
git config --global core.editor "code --wait"  # VS Code
git config --global core.editor "nano"         # Nano (simple)

# Colores en la terminal
git config --global color.ui auto

# Verificar configuración
git config --list

Primeros pasos: tu primer repositorio

Crear un nuevo repositorio

# Crear directorio y entrar
mkdir mi-proyecto
cd mi-proyecto

# Inicializar Git
git init

Esto crea una carpeta oculta .git donde Git guarda toda la información del repositorio. Una vez inicializado, podés comenzar a usar todos los Comandos esenciales para uso diario para gestionar tus archivos.

Tu primer commit

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Crear un archivo
echo "# Mi Primer Proyecto" > README.md

# Ver el estado
git status

# Agregar archivo al staging area
git add README.md

# Verificar el estado nuevamente
git status

# Hacer el commit
git commit -m "Primer commit: agregar README"

Comandos esenciales para uso diario

git status - ¿Qué está pasando?

git status es tu comando de diagnóstico más importante. Te muestra el estado actual de tu repositorio, incluyendo qué archivos fueron modificados, cuáles están en el staging area listos para commit, y cuáles son completamente nuevos (untracked). Es como preguntarle a Git “¿qué está pasando aquí?” y obtener un resumen completo de la situación. Usalo constantemente para entender dónde estás parado antes de hacer cualquier operación.

git status

Este comando te muestra:

git add - Preparar cambios

git add es el comando que mueve archivos desde tu directorio de trabajo al Staging Area (Área de preparación). Piensa en el staging area como un “área de preparación” donde seleccionás exactamente qué cambios querés incluir en tu próximo commit. Esto te permite hacer commits granulares y específicos, incluso si modificaste múltiples archivos. Podés agregar archivos individuales, grupos de archivos, o todos los cambios de una vez. Es fundamental para mantener un historial limpio y organizado.

1
2
3
4
5
6
7
8
9
10
11
12
# Agregar un archivo específico
git add archivo.txt

# Agregar varios archivos
git add archivo1.txt archivo2.txt

# Agregar todos los archivos modificados
git add .

# Agregar archivos por patrón
git add *.py        # todos los .py
git add src/        # todo en la carpeta src

git commit - Confirmar cambios

git commit toma todos los archivos que están en el Staging Area (Área de preparación) y los guarda permanentemente en el historial de tu Repositorio (repo). Cada commit es como una “fotografía” de tu proyecto en ese momento específico, con un mensaje descriptivo que explica qué cambios se hicieron y por qué. Es irreversible en el sentido de que una vez hecho el commit, esos cambios quedan grabados en la historia para siempre. Los buenos mensajes de commit son cruciales para entender la evolución del proyecto más adelante.

1
2
3
4
5
6
7
8
9
10
11
# Commit con mensaje
git commit -m "Descripción del cambio"

# Commit con mensaje más detallado
git commit -m "Título del commit

Descripción más detallada de lo que se cambió
y por qué se hizo el cambio."

# Agregar y hacer commit en un paso (solo archivos ya tracked)
git commit -am "Mensaje del commit"

git log - Historial de cambios

git log te muestra el historial completo de commits en tu Repositorio (repo). Es como un libro de registro que documenta toda la evolución de tu proyecto, mostrando quién hizo qué cambios, cuándo y por qué. Cada entrada incluye el hash único del commit, el autor, la fecha y el mensaje descriptivo. Con diferentes opciones podés personalizar la vista: ver solo una línea por commit, buscar commits específicos, ver estadísticas de archivos modificados, o incluso filtrar por autor o fecha. Es esencial para entender cómo llegó tu proyecto al estado actual.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Ver historial completo
git log

# Ver historial compacto (una línea por commit)
git log --oneline

# Ver últimos 5 commits
git log -5

# Ver cambios en archivos
git log --stat

# Buscar commits por mensaje
git log --grep="bugfix"

git diff - Ver diferencias

git diff te muestra exactamente qué cambió entre diferentes estados de tu proyecto. Sin argumentos, compara tu Working Directory (Directorio de trabajo) actual con el Staging Area (Área de preparación), mostrándote qué modificaciones aún no agregaste. Con --staged compara el staging area con el último commit, y con referencias específicas podés comparar cualquier punto en la historia. Cada diferencia se muestra línea por línea, con colores que indican qué se agregó (verde) y qué se eliminó (rojo). Es fundamental para revisar tus cambios antes de hacer un commit y para entender qué modificó alguien más en el código.

1
2
3
4
5
6
7
8
9
10
11
12
# Ver cambios no preparados (working directory vs staging)
git diff

# Ver cambios preparados (staging vs último commit)
git diff --staged

# Ver diferencias de un archivo específico
git diff archivo.txt

# Comparar con un commit anterior
git diff HEAD~1    # comparar con el commit anterior
git diff HEAD~3    # comparar con 3 commits atrás

Trabajando con archivos

Agregar archivos nuevos

Para que Git empiece a hacer seguimiento de un archivo nuevo, primero tenés que agregarlo explícitamente con git add - Preparar cambios. Los archivos nuevos aparecen como “untracked” en git status - ¿Qué está pasando? hasta que los agregues al staging area. Una vez agregados y confirmados con git commit - Confirmar cambios, Git comenzará a monitorear todos los cambios futuros en esos archivos.

1
2
3
4
5
6
7
8
9
10
# Creamos el archivo
touch nuevo-archivo.py
echo 'print("Hola mundo")' > nuevo-archivo.py

# Git no lo conoce todavía
git status

# Agregarlo al tracking
git add nuevo-archivo.py
git commit -m "Agregar script hola mundo"

Modificar archivos existentes

Cuando modificás un archivo que Git ya está trackeando, aparecerá como “modified” en git status - ¿Qué está pasando?. Git detecta automáticamente todos los cambios, pero no los incluye en commits hasta que explícitamente los agregues con git add - Preparar cambios. Esto te permite revisar los cambios con git diff - Ver diferencias antes de confirmarlos, asegurándote de que solo incluís las modificaciones que realmente querés guardar en el historial.

1
2
3
4
5
6
7
8
9
# Modificar archivo
echo 'print("Hola Git!")' >> nuevo-archivo.py

# Ver los cambios
git diff nuevo-archivo.py

# Preparar y confirmar cambios
git add nuevo-archivo.py
git commit -m "Actualizar mensaje de saludo"

git mv - Renombrar archivos

git mv le dice a Git que un archivo fue renombrado o movido, preservando su historial completo. Es superior a renombrar manualmente porque Git entiende que es el mismo archivo con nuevo nombre, manteniendo todo el historial de cambios asociado. Si renombrás manualmente, Git lo ve como un archivo eliminado y otro nuevo creado, perdiendo la continuidad histórica. Siempre usá git mv para mantener la integridad del historial de versiones.

1
2
3
4
5
6
7
8
9
# Renombrar usando Git (recomendado)
git mv archivo-viejo.txt archivo-nuevo.txt
git commit -m "Renombrar archivo"

# Si ya renombraste manualmente
mv archivo-viejo.txt archivo-nuevo.txt
git add archivo-nuevo.txt
git rm archivo-viejo.txt
git commit -m "Renombrar archivo"

git rm - Eliminar archivos

git rm elimina archivos tanto del sistema de archivos como del tracking de Git en una sola operación. Es diferente a simplemente borrar el archivo manualmente, porque también le dice a Git que deje de hacerle seguimiento. Con --cached podés mantener el archivo físicamente pero sacarlo del control de versiones (útil para archivos que agregaste por error al repo). Es la forma correcta de “des-trackear” archivos sin perder el trabajo local.

1
2
3
4
5
6
7
# Eliminar del sistema de archivos y de Git
git rm archivo-innecesario.txt
git commit -m "Eliminar archivo innecesario"

# Solo eliminar de Git (mantener en el sistema)
git rm --cached archivo-secreto.txt
git commit -m "Dejar de trackear archivo secreto"

Deshaciendo cambios

git restore - Descartar cambios no confirmados

git restore (o git checkout -- en versiones anteriores) descarta completamente las modificaciones no guardadas en tu Working Directory (Directorio de trabajo), regresando los archivos al estado del último commit. Es como un “deshacer” definitivo para cambios que no querés conservar. Una vez ejecutado, los cambios se pierden permanentemente, así que usalo solo cuando estés seguro de que querés eliminar las modificaciones. Es útil cuando experimentaste algo que no funcionó y querés volver al estado conocido y estable.

1
2
3
4
5
6
7
8
9
# Descartar cambios en un archivo específico
git checkout -- archivo.txt

# Descartar todos los cambios no confirmados
git checkout -- .

# Alternativa moderna (Git 2.23+)
git restore archivo.txt
git restore .

git restore --staged - Quitar archivos del staging area

git restore --staged (o git reset HEAD en versiones anteriores) mueve archivos desde el Staging Area (Área de preparación) de vuelta al Working Directory (Directorio de trabajo) sin perder los cambios. Es como “desagregar” archivos que agregaste con git add - Preparar cambios pero que decidiste no incluir en el próximo commit. Los cambios permanecen en tus archivos, solo se quitan del área de preparación. Es perfecto para cuando agregaste demasiados archivos de una vez y querés hacer commits más específicos y granulares.

1
2
3
4
5
6
7
8
9
# Quitar archivo específico del staging
git reset HEAD archivo.txt

# Quitar todos los archivos del staging
git reset HEAD

# Alternativa moderna (Git 2.23+)
git restore --staged archivo.txt
git restore --staged .

git commit --amend - Modificar el último commit

git commit --amend te permite “editar” el último commit, ya sea cambiando su mensaje o agregando archivos que olvidaste incluir. En realidad no modifica el commit existente, sino que crea uno nuevo reemplazando al anterior. Es extremadamente útil para corregir errores menores inmediatamente después de hacer un commit, como typos en el mensaje o archivos olvidados. Sin embargo, es peligroso si ya compartiste el commit con otros (git push - Subir cambios), porque cambiar el historial público puede crear conflictos para otros colaboradores.

# Cambiar el mensaje del último commit
git commit --amend -m "Mensaje corregido"

# Agregar archivos olvidados al último commit
git add archivo-olvidado.txt
git commit --amend --no-edit

git reset y git revert - Volver atrás en el tiempo

git reset --hard mueve tu Repositorio (repo) a un commit anterior, eliminando completamente todos los commits posteriores. Es “destructivo” porque pierdes permanentemente el trabajo realizado después de ese punto. En contraste, git revert crea un nuevo commit que deshace los cambios de un commit específico, preservando todo el historial. git reset reescribe la historia, git revert la extiende. Para trabajo colaborativo siempre preferí git revert porque no altera el historial que otros podrían tener.

1
2
3
4
5
6
7
8
# Ver historial para encontrar el commit
git log --oneline

# Volver a un commit específico (DESTRUCTIVO)
git reset --hard abc1234

# Crear un nuevo commit que deshace cambios (SEGURO)
git revert abc1234

Archivo .gitignore

El archivo .gitignore le dice a Git qué archivos o carpetas debe ignorar completamente, como si no existieran. Es esencial para evitar que archivos temporales, dependencias generadas automáticamente, o información sensible terminen en tu Repositorio (repo). Una vez que un archivo está listado en .gitignore, Git no lo mostrará en git status - ¿Qué está pasando? ni permitirá agregarlo accidentalmente. Es una de las primeras cosas que deberías configurar en cualquier proyecto nuevo.

Podemos revisar GitHub/gitignore para ejemplos ajustados a diferentes tipos de proyectos.

Crear .gitignore

# Crear el archivo
touch .gitignore

Patrones comunes

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# Archivos del sistema
.DS_Store
Thumbs.db

# Archivos de backup
*.bak
*.tmp
*~

# Logs
*.log
logs/

# Dependencias
node_modules/
venv/
__pycache__/

# Archivos de configuración local
.env
config.local.json

# Archivos compilados
*.o
*.exe
*.class

# IDEs
.vscode/
.idea/
*.swp
*.swo

Sintaxis de .gitignore

1
2
3
4
5
6
archivo.txt         # ignorar archivo específico
*.log              # ignorar todos los .log
logs/              # ignorar carpeta completa
!importante.log    # NO ignorar este archivo (excepción)
docs/**/*.pdf      # ignorar PDFs en docs y subcarpetas
temp/*             # ignorar contenido de temp, pero no temp/

Trabajando con repositorios remotos

git remote - Conectar con GitHub/GitLab

git remote gestiona las conexiones entre tu repositorio local y repositorios remotos (como GitHub). Un “remoto” es simplemente un repositorio que existe en otro lugar (servidor, nube, otra computadora) al que podés enviar y desde el cual podés recibir cambios. Por convención, el remoto principal se llama “origin”. Configurar remotos te permite sincronizar tu trabajo local con servicios en la nube, colaborar con otros, y tener respaldos automáticos de tu código.

1
2
3
4
5
6
7
8
# Agregar un remoto llamado 'origin'
git remote add origin https://github.com/usuario/mi-proyecto.git

# Ver remotos configurados
git remote -v

# Cambiar URL del remoto
git remote set-url origin https://github.com/usuario/nuevo-repo.git

git push - Subir cambios

git push envía tus commits locales al repositorio remoto, sincronizando tu trabajo con el servidor. Es como “publicar” tus cambios para que otros los vean o para tener una copia de respaldo en la nube. La primera vez necesitás especificar con -u (upstream) qué rama remota debe trackear tu rama local. Después de eso, un simple git push es suficiente. Solo podés hacer push de commits que ya confirmaste localmente; los cambios en tu Working Directory (Directorio de trabajo) o Staging Area (Área de preparación) no se suben hasta que hagas git commit - Confirmar cambios.

1
2
3
4
5
6
7
8
# Primera vez (establecer upstream)
git push -u origin main

# Siguientes veces
git push

# Push específico
git push origin main

git pull - Bajar cambios

git pull descarga commits del repositorio remoto y los fusiona automáticamente con tu trabajo local. Es la combinación de git fetch (descargar cambios) y git merge (fusionar cambios). Usalo al comenzar a trabajar para asegurarte de tener la versión más reciente del proyecto, especialmente en proyectos colaborativos. Si hay conflictos entre tu trabajo local y los cambios remotos, Git te pedirá que los resuelvas manualmente. Es esencial para mantener tu copia local sincronizada con el trabajo de otros colaboradores.

# Bajar y fusionar cambios del remoto
git pull

# Equivale a hacer:
git fetch    # descargar cambios
git merge    # fusionar cambios

git clone - Clonar un repositorio existente

git clone descarga una copia completa de un repositorio remoto a tu computadora local, incluyendo todo el historial de commits, todas las ramas, y toda la información del proyecto. Es como “fotocopiar” un proyecto completo desde GitHub (u otro servicio) a tu máquina. Automáticamente configura el remoto “origin” apuntando al repositorio original y establece el tracking de ramas. Es la forma estándar de comenzar a trabajar en un proyecto existente o de obtener el código de cualquier proyecto open source.

1
2
3
4
5
6
7
8
9
10
# Clonar repositorio
git clone https://github.com/usuario/proyecto.git

# Clonar en carpeta específica
git clone https://github.com/usuario/proyecto.git mi-carpeta

# Ver información del repositorio clonado
cd proyecto
git remote -v
git log --oneline -5

Flujo de trabajo básico

Flujo diario típico

Este es el flujo que vas a repetir docenas de veces por día cuando trabajes con Git. Primero verificás el estado con git status - ¿Qué está pasando?, hacés modificaciones a tus archivos, revisás los cambios con git diff - Ver diferencias, los preparás con git add - Preparar cambios, los confirmás con git commit - Confirmar cambios con un mensaje descriptivo, y finalmente los subís con git push - Subir cambios. Este ciclo se vuelve tan natural como respirar y es la base de todo desarrollo profesional con control de versiones.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 1. Ver estado actual
git status

# 2. Hacer cambios en archivos
# ... editar código ...

# 3. Ver qué cambió
git diff

# 4. Preparar cambios
git add .

# 5. Confirmar cambios
git commit -m "Descripción clara del cambio"

# 6. Subir al repositorio remoto
git push

Flujo para nuevo proyecto

Este flujo te guía desde una carpeta vacía hasta un proyecto completamente configurado con Git y conectado a un repositorio remoto. Iniciás creando el Repositorio (repo) local con git init, configurás el Archivo .gitignore desde el principio para evitar problemas futuros, hacés tu Tu primer commit, conectás con el remoto usando git remote - Conectar con GitHub/GitLab, y subís todo con git push - Subir cambios. Es el proceso estándar para comenzar cualquier proyecto nuevo que querés versionar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 1. Crear proyecto local
mkdir mi-proyecto
cd mi-proyecto
git init

# 2. Crear archivos iniciales
echo "# Mi Proyecto" > README.md
echo "*.log" > .gitignore

# 3. Primer commit
git add .
git commit -m "Primer commit: estructura inicial"

# 4. Conectar con remoto
git remote add origin https://github.com/usuario/mi-proyecto.git

# 5. Subir código
git push -u origin main

Comandos de información útiles

Estado y configuración

Estos comandos te dan información crucial sobre el estado actual de tu repositorio y su configuración. git status - ¿Qué está pasando? te muestra qué está pasando ahora, git config --list muestra toda tu configuración de Git, y git remote - Conectar con GitHub/GitLab con git log te dan contexto sobre conexiones remotas e historial. Son comandos “de solo lectura” que nunca modifican nada, perfectos para orientarte cuando no estás seguro del estado actual del proyecto.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Estado actual
git status

# Configuración actual
git config --list

# Información del repositorio
git remote -v
git log --oneline -10

# Ver archivos tracked
git ls-files

# Ver espacio usado
du -sh .git

Exploración del historial

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Historial gráfico simple
git log --graph --oneline

# Historial con detalles
git log --stat

# Buscar en commits
git log --grep="fix"
git log --author="mi-nombre"

# Ver cambios de un archivo
git log -p archivo.txt

# Ver quién modificó cada línea
git blame archivo.txt

Configuraciones útiles

Alias para comandos frecuentes

1
2
3
4
5
6
7
8
9
10
11
# Crear aliases útiles
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.lg "log --oneline --graph"
git config --global alias.unstage "reset HEAD --"

# Usar los aliases
git st        # equivale a git status
git lg        # log gráfico compacto

Configuraciones de editor

1
2
3
4
5
6
7
8
# Configurar VS Code como editor
git config --global core.editor "code --wait"

# Configurar Vim
git config --global core.editor "vim"

# Configurar Nano (más simple)
git config --global core.editor "nano"

Configuración de colores

# Habilitar colores
git config --global color.ui auto
git config --global color.status auto
git config --global color.diff auto
git config --global color.branch auto

Errores comunes y soluciones

“fatal: not a git repository”

# Verificar que estás en un directorio con Git
ls -la | grep .git

# Si no existe, inicializar
git init

“Author identity unknown”

# Configurar identidad
git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"

Commit sin mensaje

# Si se abre un editor, escribir mensaje y guardar
# Para salir de Vim: presionar ESC, luego :wq

# Para evitarlo, siempre usar -m
git commit -m "Mensaje descriptivo"

Archivos grandes en el historial

# Ver archivos más grandes en el repo
git ls-tree -r -t -l --full-name HEAD | sort -n -k 4

# Para eliminar archivos grandes del historial (avanzado)
# Considerar usar git-filter-branch o BFG Repo-Cleaner

Problema con line endings (Windows/Linux)

# Para Windows (convierte LF a CRLF al checkout)
git config --global core.autocrlf true

# Para Linux/Mac (mantiene LF)
git config --global core.autocrlf input

Ejercicios prácticos

Guías
Guía Bash
Guías
Guía git avanzada