Control de versiones
Inicio
Control de versiones
Git y Git Hub
¿Qué es el control de versiones?
Registro de cambios
Sistema que registra cambios en archivos a lo largo del tiempo, permitiendo recuperar versiones anteriores.
Beneficios principales
  • Volver a versiones anteriores de archivos o proyectos completos.
  • Comparar cambios, identificar quién y cuándo modificó algo.
  • Recuperar archivos perdidos o dañados fácilmente.
Recuperación de archivos
Usar un VCS también significa generalmente que si fastidias o pierdes archivos, puedes recuperarlos fácilmente. Además, obtienes todos estos beneficios a un coste muy bajo.
No solo aplica a código fuente, sino también a otros tipos de archivos (ej. diseños gráficos).
Sistemas de control de versiones locales
Algunas personas realizan control de versiones manual copiando archivos a diferentes directorios (a veces con fechas para identificarlos).
Sin embargo, este método es:
  • Sencillo, pero propenso a errores (ej. sobrescribir archivos accidentalmente o perder versiones).
Para solucionarlo, surgieron los VCS locales, que:
  • Usan una base de datos para registrar cambios en los archivos.
  • Permiten un mejor seguimiento de las versiones sin depender de copias manuales.
Estos sistemas fueron un primer paso hacia herramientas más eficientes de control de versiones.
Sistemas de control de versiones centralizados (RCS)
Sistemas como CVS, Subversion y Perforce usan un servidor central que almacena todos los archivos, mientras los clientes descargan y envían cambios a él.
Fueron el estándar por años, pero su dependencia de un servidor único llevó luego al desarrollo de sistemas distribuidos como Git.
Ventajas
✅ Colaboración mejorada
  • Todos los colaboradores conocen el estado del proyecto.
  • Evita conflictos al trabajar en archivos compartidos.
✅ Control administrativo
  • Gestión de permisos por usuario.
  • Más fácil de administrar que múltiples bases de datos locales.
Desventajas
❌ Punto único de fallo
  • Si el servidor central falla, se detiene toda la colaboración.
  • Pérdida total de datos si el disco se corrompe sin backups.
❌ Dependencia del servidor
  • Sin conexión, no se pueden guardar cambios centralizados.
  • Similar al riesgo de los VCS locales (historia concentrada en un solo lugar).
Sistemas de control de versiones distribuído
Los sistemas como Git, Mercurial y Bazaar revolucionaron el control de versiones al distribuir el repositorio completo en cada copia local.
Ventajas
✅Resistencia
Si falla el servidor, cualquier copia local puede restaurar el proyecto
✅Flexibilidad
Cada desarrollador tiene un historial completo y puede trabajar offline
✅Colaboración avanzada
Permite múltiples flujos de trabajo y tipos de colaboración simultáneos
A diferencia de los sistemas centralizados, los DVCS permiten modelos de trabajo más dinámicos y descentralizados.
Este enfoque resolvió las limitaciones de los sistemas centralizados, dando más poder y autonomía a los desarrolladores.
¿Qué es GIT?
Software de control de versiones
Diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente.
Creado el 17 de abril de 2005, ha tenido gran número de versiones desde entonces.
Características
  • Código abierto
  • Velocidad
  • Diseño sencillo
  • Gran soporte para desarrollo no lineal (miles de ramas paralelas)
  • Completamente distribuido
  • Capaz de manejar grandes proyectos
Propósito principal
Llevar registro de los cambios en archivos de computadora y coordinar el trabajo que varias personas realizan sobre archivos compartidos.
Fundamentos de Git
Esencia de Git:
• No es solo un VCS, es un sistema distribuido con filosofía única
• Requiere "desaprender" conceptos de SVN/Perforce para aprovecharlo plenamente
Diferencias clave:
✓ Almacenamiento inteligente: Guarda instantáneas (no solo cambios)
✓ Operación local: 90% de acciones no necesitan conexión
✓ Integridad de datos: Usa checksums (SHA-1) para todo registro
Por qué importa:
➤ Los errores comunes surgen de aplicar mentalidad centralizada
➤ Su modelo distribuido habilita flujos de trabajo imposibles en otros VCS
✅Instantáneas
Mientras otros VCS guardan cambios incrementales (deltas), Git almacena el estado completo del proyecto en cada commit, como una fotografía del sistema de archivos.
  • Cada commit contiene una copia completa (pero optimizada)
  • Archivos sin cambios se reutilizan mediante enlaces
  • Permite operaciones locales rápidas y ramificación eficiente
Almacenamiento de datos como cambios en una versión de la base de cada archivo.
Almacenamiento de datos como instantáneas del proyecto a través del tiempo.
✅ Casi todas las operaciones son locales
Mientras otros sistemas (como SVN o Perforce) dependen constantemente del servidor, casi todas las operaciones en Git se ejecutan localmente usando tu repositorio completo.
Ventajas
Velocidad ultrarrápida
Acceso inmediato al historial completo y diferencias entre versiones
Trabajo offline
Puedes commitear, crear ramas y explorar el historial sin conexión
Independencia
No necesitas VPN ni conexión estable para trabajar productivamente
✅ Tiene identidad
Git protege tus datos mediante hashes SHA-1 únicos:
  • Cada archivo y commit genera un checksum de 40 caracteres
  • Cualquier alteración cambia completamente el hash
  • Beneficios principales
Protección automática
Detecta cualquier corrupción o cambio no autorizado
Identificación precisa
Todo se referencia por su contenido (no por nombres)
Eficiencia
La misma estructura verifica datos al moverlos
Ejemplo práctico:
Si modificas 1 byte en un archivo antiguo:
  • Su hash SHA-1 cambiará completamente
  • Git invalidará todas las referencias asociadas
Nunca perderás trabajo por fallos de almacenamiento o transferencia sin que Git lo detecte.
✅ Tres estados fundamentales
Estados de los archivos
Modificado (Modified)
Cambiado en el directorio de trabajo, pero no marcado para commit.
Preparado (Staged)
Añadido al staging area (índice) listo para el próximo commit.
Confirmado (Committed)
Almacenado permanentemente en el repositorio local (Git directory).
Áreas clave
Working Directory
Donde editas los archivos (copia actual del proyecto).
Staging Area (Índice)
Filtro para seleccionar qué cambios se incluirán en el commit.
Git Directory (.git)
  • Base de datos segura con toda la historia y metadatos.
Flujo de trabajo típico
1
Modificas archivos en el working directory → modified.
2
git add → Mueves cambios al staging area → staged.
3
git commit → Guardas en el repositorio local → committed.
Uso de Git
  • Línea de comandos (Terminal)
  • Control total: Acceso a todos los comandos y funciones de Git.
  • Transferible: Lo aprendido aplica a cualquier interfaz gráfica (pero no al revés).
  • Universal: Incluido en todas las instalaciones de Git (Mac/Linux/Windows).
  • Interfaz gráfica
Clientes gráficos vs. Terminal
Instalación de Git
Linux
  • Por defecto tiene una instalación de git pero esta no estará actualizada
  • Para actualizar la instalación de git: apt-get install git
Windows
Mac
  • Por defecto tiene una instalación de git pero esta no estará actualizada
A partir de aquí todos los comandos de Git funcionan igual en todas las plataformas
Comprobación de la instalación
Una vez instalado y ejecutado el bash de Git, desde la terminal introducir el comando:
git --version
De esta forma podemos saber la versión y si se ha instalado correctamente
Identificación en Git (Configuración inicial)
Git requiere tu nombre y email para identificar tus commits:
git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"
⚠️ Esta información queda grabada permanentemente en todos tus commits.
  • Global (--global): Aplica a todos tus repositorios (solo configurar una vez).
  • Por proyecto: Omite --global para sobrescribir la configuración en un repo específico.
Para ver/modificar tu configuración:
git config --list  # Muestra toda la configuración
Para obtener ayuda sobre git, utiliza:
git help <comando>
Operaciones en Git
1
Inicialización
Crear un nuevo repositorio o clonar uno existente
2
Modificación
Realizar cambios en los archivos del proyecto
3
Preparación
Añadir archivos modificados al área de preparación
4
Confirmación
Guardar los cambios en el repositorio local
5
Sincronización
Compartir cambios con el repositorio remoto
Inicialización de un proyecto
1
Inicializa el repositorio
Para indicar que queremos realizar un control de versiones en un directorio:
git init
Esto crea un nuevo subdirectorio llamado .git que contiene todos los archivos necesarios del repositorio —un esqueleto de un repositorio Git.
Todavía no hay nada en tu proyecto que esté bajo seguimiento.
2
Añadir archivos al staging
Especifica qué archivos quieres controlar:
git add archivo1.java
git commit –m 'versión inicial del proyecto
3
Confirmar lo cambios
En este paso es obligatorio indicar un mensaje descriptivo
Cada vez que se confirma se indica cual es la rama y el checksum asociado a ese commit, ya que cada vez que se hace uno se genera un nuevo código.
git commit -m "Primer commit: versión inicial del proyecto"
Añadiendo la opción -a al comando git commit harás que Git prepare automáticamente todos los archivos rastreados antes de confirmarlos, ahorrándote el paso de git add:
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: archivo1.java
no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
1 file changed, 5 insertions(+), 0 deletions(-)
Resumen
  • git init: Crea la estructura .git para empezar a versionar
  • git add: Prepara los archivos para el commit (los añade al staging area)
  • git commit: Guarda permanentemente una "foto" de los archivos en ese estado
Estado de los archivos
Después de realizar esta pequeña práctica podemos deducir que los archivos tienen dos estados:
Tracked (Rastreados):
  • Archivos presentes en el último commit
  • Pueden estar:
  • Unmodified (Sin cambios)
  • Modified (Modificados)
  • Staged (Preparados para commit)
Untracked (No rastreados):
  • Archivos nuevos que Git no controla aún
  • No estaban en el último commit ni en el staging area
Ciclo de trabajo típico
Como ya hemos visto
  1. Modificas archivos → Modified
  1. git add → Mueves a Staged
  1. git commit → Guardas en el historial (Tracked - Unmodified)
Revisar el estado de un repositorio
git status
Es el comando diagnóstico más útil para entender el estado actual del trabajo.
Muestra el estado actual del repositorio, incluyendo:
  • Archivos rastreados (tracked) y no rastreados (untracked)
  • Cambios pendientes de commit
  • La rama actual y su estado respecto al repositorio remoto
Salidas típicas Directorio limpio
On branch master nothing to commit, working directory clean
Significado:
  • No hay archivos modificados
  • No hay archivos nuevos sin rastrear
Archivos no rastreados (ejemplo: README nuevo)
On branch master Untracked files: (use "git add ..." to include in what will be committed) README nothing added to commit but untracked files present
Significado:
  • Git detectó un archivo nuevo (README)
  • No se incluirá en commits hasta que se marque explícitamente con git add
  • Información clave Rama predeterminada: master (o main en repositorios nuevos)
Confirmar si la rama se ha sincronizado en archivos remotos
Flujo recomendado:
Usar git status frecuentemente para:
  • Verificar cambios antes de commits
  • Identificar archivos nuevos/modificados
Ejemplo de uso
# Crear archivo nuevo
echo "Contenido" > archivo.txt

# Ver estado
git status  # Muestra archivo.txt como "untracked"

# Añadir al control de versiones
git add archivo.txt
git status  # Ahora aparece listo para commit
Ignorar archivos
Es un archivo de texto que le indica a Git qué archivos o directorios no debe rastrear, evitando que se incluyan accidentalmente en commits.
Para ello, se crea un archivo llamado .gitignore, el cual debemos de editar para añadir los nombres de los ficheros o directorios que se deben de ignorar.
Casos comunes para ignorar archivos:
  • Archivos generados automáticamente (logs, caché, binarios).
  • Archivos temporales de editores (ej. *.swp, *~).
  • Dependencias (ej. node_modules/, __pycache__/).
  • Configuraciones locales o sensibles (ej. .env, *.key).
Sintaxis básica de .gitignore
Buenas prácticas
  • Crearlo al inicio del proyecto: Evita commits accidentales.
  • Usar patrones estándar: Como *.log o temp/.
  • Excluir lo necesario: Con ! (ej. !config.important).
Ejemplo de .gitignore
# Ignorar archivos de compilación  
*.o  
*.a  

# Excepción: un archivo específico  
!lib.a  

# Ignorar directorios  
build/  
node_modules/  

# Ignorar archivos temporales de editores  
*~  
*.swp  

# Ignorar archivos de documentación generada  
doc/**/*.pdf
Importante
Git no ignora archivos ya rastreados. Para eliminarlos del repositorio:
git rm --cached archivo.txt
  • Las líneas que empiezan con # son comentarios.
  • Los cambios en .gitignore deben confirmarse con git add y git commit.
Utilidad
  • Mantiene el repositorio limpio: Sin archivos innecesarios.
  • Protege datos sensibles: Evita subir contraseñas o configuraciones locales.
  • Optimiza el espacio: Evita rastrear archivos generados automáticamente.
Visualización detallada de cambios
git diff
Muestra diferencias exactas entre versiones de archivos, permitiendo:
  • Ver modificaciones no preparadas (working directory vs staging area)
  • Ver cambios preparados (staging area vs último commit)
  • Comparar versiones específicas
Uso
Ejemplo práctico Situación
Editaste README.md y lo añadiste al staging (git add)
Luego modificaste CONTRIBUTING.md sin añadirlo
git status
# Cambios para commit:
#   (usar "git restore --staged <file>..." para sacar del staging)
#       modified:   README.md
#
# Cambios no preparados:
#   (usar "git add <file>..." para actualizar)
#       modified:   CONTRIBUTING.md
Sirve para ver:
Cambios no preparados en CONTRIBUTING.md:
bash git diff
Cambios preparados en el README.md
bash git diff --staged
Todos los cambios pendientes:
bash git diff HEAD
Interpretación de la salida
La salida muestra:
  • Líneas eliminadas (prefijadas con -)
  • Líneas añadidas (prefijadas con +)
  • Contexto alrededor de los cambios (líneas sin prefijo)
  • Encabezado con rutas y metadatos
@@ -65,7 +65,8 @@ branch directly...
 Please include a nice description...
 if we have to read the whole diff...
-merged in.
+merged in. Also, split your changes...
+longer than a dozen lines.
Importante
git diff sin parámetros no muestra cambios ya preparados
Para comparar entre commits específicos:
git diff commit1 commit2
Alternativa gráfica:
git difftool
Casos de uso típicos
  1. Antes de hacer commit:
  • Verificar exactamente qué se incluirá
  • Detectar cambios accidentales
  1. Durante conflictos:
  • Entender diferencias entre versiones
  1. Revisión de historial:
  • Comparar versiones antiguas
Eliminar archivos
Permite eliminar los archivos del respositorio
Eliminar archivos correctamente
Para quitar archivos del control de versiones:
git rm archivo.txt # Elimina del repositorio y del sistema de archivos 
git commit -m "Eliminado archivo.txt"
Diferencia con borrado manual
Si solo borras con rm archivo.txt:
  • Git lo detecta como "Change not staged for commit" (eliminación pendiente)
  • Requiere:
git add archivo.txt  #o git rm archivo.txt 
git commit
Casos especiales
Ejemplo completo
# Eliminar directorio y su contenido
git rm -r directorio/
git commit -m "Eliminado directorio/"

# Quitar del repositorio pero mantener local
git rm --cached config.ini
git commit -m "Dejar de trackear config.ini"
Recuperación accidental
Si borraste un archivo importante:
git checkout HEAD -- archivo.txt  # Recupera la última versión guardada
Importante
  • Usa git status para ver el estado de los borrados
  • La opción --cached es útil para archivos que deben ignorarse (como .env)
  • Git no permite borrar cambios no guardados sin -f (protección contra pérdidas)
Cambiar el nombre de los archivos
Git no rastrea explícitamente cambios de nombre, pero detecta automáticamente renombramientos mediante análisis de contenido. Esto ocurre cuando:
  • Un archivo desaparece (equivalente a git rm)
  • Un nuevo archivo aparece (equivalente a git add)
  • El contenido es similar
Métodos para renombrar
  • Comando dedicado (recomendado):
git mv archivo_viejo archivo_nuevo
  • Equivale a tres operaciones automáticas:
mv archivo_viejo archivo_nuevo  # Renombra en disco
git rm archivo_viejo             # Elimina el nombre antiguo
git add archivo_nuevo            # Añade el nombre nuevo
  • Forma manual (alternativa):
mv archivo_viejo archivo_nuevo
git rm archivo_viejo
git add archivo_nuevo
Ejemplo práctico
# Caso 1: Uso de git mv
git mv README.md LEEME.md

# Caso 2: Proceso manual equivalente
mv guia_usuario.pdf manual.pdf
git rm guia_usuario.pdf
git add manual.pdf
Verificación:
git status
# Muestra:
# renamed: README.md -> LEEME.md
# renamed: guia_usuario.pdf -> manual.pdf
Importante
  • Git usa similitud de contenido (50%+ coincidencias) para detectar renombramientos
  • Funciona mejor con archivos de texto que binarios
  • El historial se mantiene intacto (los commits antiguos mostrarán el nombre original)
Usos
  • Para renombres complejos (múltiples archivos):
git add -A  # Detecta automáticamente renombres
  • Si Git no detecta el renombre:
git mv -f archivo_viejo archivo_nuevo  # Fuerza la detección
Historial de confirmaciones
git log
Muestra el historial de commits en orden cronológico inverso (más recientes primero), incluyendo:
  • Hash SHA-1 completo
  • Autor (nombre y email)
  • Fecha
  • Mensaje del commit
Este comando es esencial para auditorías de código, investigación de bugs y comprensión de la evolución del proyecto.
Formatos de visualización
Filtro avanzado
Ejemplos prácticos
  • Ver cambios recientes con detalles:
git log -p -3  # Muestra diferencias de los últimos 3 commits
  • Historial resumido con gráfico de ramas:
git log --oneline --graph --all
  • Buscar commits de un autor este mes:
git log --author="Juan" --since="1 month ago"
  • Cambios que afectan a una función:
git log -S"calcularTotal" --stat
Importante
  • Los hashes SHA-1 identifican commits de forma única
  • --since/--until aceptan formatos:
  • Relativos: "3 days ago"
  • Absolutos: "2023-05-01"
  • --grep busca en mensajes de commit (combinar con --all-match para AND lógico)
Deshacer cosas
Podemos deshacer acciones que hayamos realizado en git
Corregir el Último Commit
git commit --amend
Cuándo usarlo:
  • Olvidaste añadir archivos al commit
  • Te equivocaste en el mensaje del commit
  • Quieres combinar cambios nuevos con el commit anterior
Pasos:
# 1. Añade los archivos olvidados (si aplica)
git add archivo_olvidado.py

# 2. Reescribe el commit
git commit --amend
Qué ocurre:
  • El archivo contiene el mensaje anterior
  • Al guardar, se reemplaza el último commit (mismo hash si solo cambia el mensaje)
Importante:
Para commits remotos (Ya lo veremos)
  • Nunca uses --amend en commits ya pusheados (rompe el historial compartido)
  • Para commits remotos, usa git revert + nuevo commit
Quitar Archivos del Staging
git reset HEAD
Cuándo usarlo:
  • Añadiste archivos accidentalmente con git add
  • Quieres dividir cambios en múltiples commits
Flujo detallado:
# 1. Ver estado actual
git status  # Muestra archivos en staging

# 2. Quitar archivo específico
git reset HEAD archivo_accidental.txt

# Opción alternativa (todos los archivos)
git reset HEAD .
Efecto:
  • Los cambios siguen en tu directorio de trabajo
  • El archivo vuelve a aparecer como "Changes not staged"
Ejemplo:
$ git status
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
        modified:   script.js  # ← Este queremos sacar

$ git reset HEAD script.js
$ git status
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   script.js  # ← Ahora está fuera del staging
Descartar Cambios Locales
git checkout -- / git restore
Cuándo usarlo:
  • Experimentaste cambios no deseados
  • Quieres volver a la versión del último commit
Comandos equivalentes:
# Forma tradicional (aún válida)
git checkout -- archivo_dañado.html

# Versión moderna (Git 2.23+)
git restore archivo_dañado.html
Advertencia crítica:
  • Esto borra permanentemente los cambios no commiteados
  • Alternativa segura:
git stash  # Guarda cambios temporalmente
git stash drop  # Si decides eliminarlos después
Deshacer múltiples commits
git reset --hard
Escenario:
  • Hiciste 2-3 commits experimentales
  • Quieres volver a un estado anterior
Solución:
# 1. Ver historial (copiar hash objetivo)
git log --oneline

# 2. Retroceder (ej: 2 commits)
git reset --hard HEAD~2
Efecto:
  • Elimina los últimos 2 commits del historial
  • Pérdida total de los cambios en working directory
Etiquetas en Git
Git permite etiquetar puntos importantes en el historial
Útil para marcar lanzamientos o hitos relevantes.
Listar Etiquetas
Muestra todas las etiquetas en orden alfabético.
git tag
Buscar etiquetas con patrones
git tag -l 'v1.8.5*'
Crear una etiqueta
git tag nombre_etiqueta
Ver detalles de una etiqueta
git show nombre_etiqueta
Eliminar una etiqueta
git tag -d nombre_etiqueta
Alias en Git
Se usa para conseguir atajos para comandos largos o frecuentes en Git.
Personalizan la CLI para hacerla más eficiente y fácil de usar.
Crear Alias
git config --global alias.<nombre-corto> "<comando-original>"
Ejemplos comunes
git config --global alias.co checkout    # git co
git config --global alias.br branch      # git br
git config --global alias.ci commit      # git ci
git config --global alias.st status      # git st
Ejemplo práctico
# Crear alias para ver historial simplificado
git config --global alias.lg "log --oneline --graph --all"

# Uso:
git lg  # Muestra el historial en formato resumido.
Ventajas
  • Ahorra tiempo en comandos repetitivos.
  • Reduce errores al teclear menos.
  • Personalización para flujos de trabajo específicos.
Para listar los alias actuales
git config --global --list | grep alias
Creando nuestro primer respositorio
Crea una carpeta en llamada "Hola Git"
Desde la línea de comando nos situamos en esa carpeta e inicializamos Git
 git init
Podemos ver como se crea la carpeta oculta .git dentro del directorio "Hola Git"
La rama inicial se llama master como indica el archivo anterior, pero su tendencia es a cambiar su nombre a "main"
Podemos hacerlo con el siguiente comando:
git branch -m main
En todo momento podemos ver el estado de nuestro Git usando
git status
En este momento del proyecto estará así:
Indica que estamos en la rama "main". Que no se ha confirmado ningún archivo
Ahora vamos a crear un archivo de texto en su interior que se llame git1.py
Comprobamos el estado
En este caso, nos indica que hay un archivo nuevo pero que no se ha añadido ni comiteado.
Cuando es así aparece el archivo en rojo
Procedemos a añadir el archivo
git add git1.py
Comprobamos de nuevo el estado
Ahora vemos que se ha añadido el archivo porque aparece en verde, pero no se ha confirmado, de ahí que aparezca que no hay commits
A continuación lo confirmamos
git commit -m "comentario"
Comprobamos de nuevo el estado y me indica que no hay nada pendiente
Si queremos comprobar el código hash asignado y las ramas usamos
git log
Modifica git1.py, añade y confirma los cambios
Ahora hay dos versiones
Crear archivo .gitignore
Añade los archivo que quieras dentro de .gitignore
Comprobar .gitignore y añadir al commit
Comprobamos el log
Mirar las diferencias del archivo git1.py
Modifica git1.py
Usa el comando git diff
Añade un directorio temporal
Elimina el archivo temporal
Renombrar un archivo
Deshacer cambios
Puede verse como el archivo vuelve a su estado original:
Ramificaciones en Git
Los sistemas de control de versiones modernos permiten trabajar con ramas.
Una rama es una línea de desarrollo independiente que surge a partir de la rama principal (generalmente master o main).
En otros sistemas, crear ramas puede ser costoso (requiere copiar todo el código), pero en Git es rápido y eficiente.
Ventajas de Git en el manejo de ramas
  • Rapidez: Crear, cambiar y fusionar ramas es casi instantáneo.
  • Flujo de trabajo flexible: Git fomenta el uso frecuente de ramas (incluso varias veces al día).
  • Potencia: Permite experimentar sin afectar la rama principal.
¿Qué es una rama en Git?
Git almacena datos como instantáneas (snapshots) en lugar de diferencias.
Una rama en Git es simplemente un apuntador móvil que señala a un commit específico.
Cada commit guarda:
  • Una copia de los archivos (blobs).
  • Un árbol (tree) que referencia los archivos y su estructura.
  • Metadatos (autor, mensaje) y un apuntador al commit anterior.
Rama por defecto: Al inicializar un repositorio (git init), Git crea automáticamente la rama master (o main en repositorios nuevos).
  • No tiene nada de especial, es igual que cualquier otra rama.
  • Su uso común se debe a que es la rama predeterminada, no a una diferencia técnica.
  • Con el primer commit, la rama master apunta a ese commit.
  • Cada nuevo commit mueve automáticamente el apuntador de la rama hacia adelante.
Crear una nueva rama en Git
Git crea un nuevo apuntador que señala al mismo commit actual.
Ejemplo:
git branch testing  # Crea la rama "testing"
No cambia tu rama actual, solo añade un nuevo puntero.
Qué pasa con el puntero HEAD
Indica la rama actual en la que estás trabajando.
git branch solo crea la rama, pero no mueve HEAD (sigues en la misma rama).
Ver ramas y commits
Usa git log --oneline --decorate para ver:
  • Dónde apunta cada rama.
  • Cuál es el commit actual (HEAD).
Ejemplo de salida:
f30ab (HEAD, master, testing) add feature #32  
34ac2 fixed bug #1328  
98ca9 initial commit
Aquí, tanto master como testing apuntan a f30ab, pero HEAD indica que estás en master.
Cambiar entre ramas
Para moverse a otra rama, se usa:
git checkout <rama>  # Ejemplo: `git checkout testing`
Si se hace un commit, la rama HEAD, avanza sobre la rama en la que nos encontramos, si no hemos hecho ningún cambio, será sobre master o main
Esto mueve el puntero HEAD a la rama especificada.
Después de esto, vemos que la rama testing avanza, mientras que la rama master permanece en la última confirmación creada.
Si volvemos a master con:
git checkout master  # Vuelve a `master`  
git commit -a -m "otros cambios"  # Ahora `master` y `testing` tienen historiales distintos
Esto produce dos acciones:
  1. Mueve el puntero HEAD a la rama master
  1. Restaura los archivos del directorio de trabajo a su estado en el último commit de master
Efectos
Es como un "rebobinado" temporal del proyecto
  • Se deja una línea de trabajo (testing)
  • Se retoma otra línea diferente (master)
  • Ambas ramas pueden evolucionar independientemente (Al hacer commit en testing, solo esa rama avanza; master permanece donde estaba)
  • Al alternar entre ramas y hacer commits, el historial se bifurca.
Implicaciones:
  1. Git maneja automáticamente estos cambios de estado
  1. Si hay conflictos, Git previene el cambio para evitar pérdida de trabajo
  1. Cada rama mantiene su propio historial de cambios intacto
Visualización del historial divergente
Se usa git log con opciones para ver ramas y divergencias:
git log --oneline --decorate --graph --all
  • Muestra commits, ramas y cómo se separan.
  • Ejemplo de salida:
* c2b9e (HEAD,master) otros cambios  
| * 87ab2 (testing) un cambio  
|/  
* f30ab commit anterior
* 34ac2
* 98ca9
Ventajas de las ramas en Git
  • Creación y eliminación instantánea:
  • Una rama es solo un archivo pequeño (40 bytes) que apunta a un commit SHA-1.
  • No requiere copiar todo el proyecto (a diferencia de otros sistemas como SVN o CVS).
  • Fusión sencilla:
  • Git rastrea automáticamente los commits padres, facilitando merges.
  • Flujo de trabajo flexible:
  • Permite experimentar en ramas aisladas y alternar entre ellas sin costo.
Conclusión
Git incentiva el uso frecuente de ramas gracias a su rapidez y eficiencia.
  • Comandos
  • git branch: Crear ramas.
  • git checkout: Moverse entre ramas.
  • git commit: Avanzar el historial.
  • git log --graph Visualiza el historial para entender la divergencia.
Procesos básicos de ramificación
Escenario práctico
Situación Inicial
Partimos de un historial lineal con algunos commits en master
Crear una Rama para un Nuevo Issue (#53)
Comando rápido para crear y cambiar a la rama iss53:
git checkout -b iss53  # Equivalente a: git branch iss53 + git checkout iss53
Aparece un nuevo puntero iss53 en el mismo commit que master
Trabajar en la Rama iss53
Realizar cambios y commits:
git commit -a -m 'added a new footer [issue 53]'
La rama iss53 avanza, mientras master se queda atrás
Problema Crítico (Hotfix)
Cambiar a master para resolverlo:
git checkout master  # ¡El directorio de trabajo revierte al estado de `master`!
  • Importante: Git no permite cambiar de rama si hay cambios sin commit (conflictos potenciales).
Resolver el problema
Crear rama hotfix y solucionar el problema:
git checkout -b hotfix
git commit -a -m 'fixed the broken email address'
La rama hotfix avanza desde master
Fusionar hotfix en master
Fusión rápida (fast-forward):
git checkout master
git merge hotfix  # Git mueve `master` al mismo commit que `hotfix`
  • Fast-forward: Ocurre cuando no hay divergencias (la rama a fusionar está directamente adelante).
Una vez resuelto el problema
Eliminar hotfix (ya no es necesaria):
git branch -d hotfix
Retomar el Trabajo en iss53: Volver a la rama original y continuar:
git checkout iss53
git commit -a -m 'finished the new footer [issue 53]'
iss53 sigue su curso independiente de master
Procesos básicos de fusión
Fusión Simple (Fast-Forward)
Ejemplo previo: La rama hotfix se fusionó con master mediante un fast-forward, ya que no había divergencias .
Qué ocurre cuando hay conflicto?
Causa:
Modificaciones contradictorias en el mismo archivo en ambas ramas.
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Solución:
  1. Identificar conflictos con git status (archivos marcados como "unmerged").
  1. Editar manualmente los archivos conflictivos, donde Git inserta marcadores:
<<<<<<< HEAD:index.html  <!-- Versión en master -->
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">        <!-- Versión en iss53 -->
  please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
3. Resolver eligiendo un cambio o combinando ambos, eliminando los marcadores.
4. Marcar como resuelto y completar la fusión:
git add index.html  # Marca el conflicto como resuelto
git commit          # Finaliza el merge commit
Herramientas Gráficas para Conflictos
Ejecutar git mergetool para abrir una herramienta visual (ej.: meld, kdiff3).
Tras resolver, Git marca los archivos como "staged" y permite completar el commit.
Eliminar la Rama Fusionada
Una vez fusionado iss53, eliminarla:
git branch -d iss53
Gestión de ramas: Comandos
Listado de Ramas
git branch
Muestra todas las ramas locales.
El asterisco (*) indica la rama actual (donde está HEAD).
Ver Último Commit por Rama
git branch -v
Ejemplo de salida:
iss53   93b412c fix javascript issue
* master 7a98805 Merge branch 'iss53'
testing 782fd34 add scott to the author list
Filtrar Ramas Fusionadas/No Fusionadas
Ramas ya fusionadas con la rama actual:
git branch --merged
  • Uso práctico: Identifica ramas que pueden eliminarse sin perder trabajo (ej.: iss53 ya fusionada).
Ramas con trabajo no fusionado:
git branch --no-merged
  • Importante: Git bloquea su eliminación con git branch -d para evitar pérdida de cambios.
Eliminación de Ramas
Eliminar ramas fusionadas (seguro):
git branch -d iss53  # Elimina solo si está fusionada
Forzar eliminación (pérdida de cambios):
git branch -D testing  # Ignora advertencias
  • Útil para descartar experimentos fallidos.
Buenas Prácticas
Mantener limpio el repositorio:
  • Eliminar ramas fusionadas para reducir ruido.
Verificar estado antes de eliminar:
  • Usar --merged/--no-merged para evitar errores.
Ejemplo de flujo
  1. Listar ramas:
git branch -v
2. Filtrar no fusionadas:
git branch --no-merged
3. Eliminar rama segura:
git branch -d iss53
4. Forzar eliminación si es necesario:
git branch -D testing
Resumen de comandos
Resumen de ramificación
Escenario práctico para comprender la ramificación
Trabajo inicial:
  • Estás desarrollando un sitio web en la rama principal (ej. main o master).
Nueva funcionalidad:
  • Creas una rama para un nuevo tema:
git branch nueva-funcionalidad
git checkout nueva-funcionalidad
  • Trabajas en los cambios necesarios.
Problema crítico:
  • Recibes un reporte de un bug urgente que debe resolverse inmediatamente.
Manejo del bug:
  • Vuelves a la rama de producción:
git checkout main
  • Creas una rama para la corrección:
git checkout -b hotfix-bug
  • Trabajas en la solución, pruebas y confirmas los cambios:
git commit -m "Solución al bug crítico"
Fusión:
  • Fusionas la corrección a la rama principal:
git checkout main
git merge hotfix-bug
Retomar el trabajo:
  • Regresas a tu rama original para continuar con la nueva funcionalidad:
git checkout nueva-funcionalidad
Beneficios de este Flujo
Aislamiento de cambios:
  • El trabajo en la nueva funcionalidad no se ve afectado por la corrección urgente.
Respuesta rápida a problemas:
  • Puedes atender bugs críticos sin comprometer el trabajo en progreso.
Organización clara:
  • Cada tarea tiene su propia rama, facilitando el seguimiento y la colaboración.
  • Este flujo permite manejar múltiples tareas simultáneamente, manteniendo un historial limpio y facilitando la colaboración en equipo.
Comandos
Git en el Servidor
Importancia del repositorio remoto
Colaboración: Necesario para trabajar en equipo, evitando confusiones al compartir cambios directamente entre individuos.
Acceso permanente: Permite a colaboradores acceder al código incluso cuando tu computadora está offline.
Configuración básica Repositorio básico
No tiene directorio de trabajo (solo contiene datos internos de Git, equivalentes al directorio .git).
Funciona como punto centralizado para push y pull (subir y descargar del repositorio)
Protocolos soportados
Local
Sistemas de archivos compartidos (ej: NFS o mismo equipo).
git clone /opt/git/project.git          # Sin prefijo (usa hardlinks)
git clone file:///opt/git/project.git   # Con prefijo (más lento)
Ventajas:
  • Simplicidad y permisos de archivos existentes.
Desventajas:
  • Acceso remoto complicado (requiere montar discos) y menor velocidad en NFS vs SSH.
Protocolo SSH
Conexión segura a servidores remotos mediante SSH (el más común para repositorios privados).
git clone ssh://user@server:/ruta/project.git   # Formato explícito  
git clone user@server:/ruta/project.git         # Formato abreviado
Ventajas:
  • Seguridad: Encriptación integral (autenticación y transferencia de datos).
  • Facilidad de acceso remoto: No requiere montar sistemas de archivos.
  • Permisos: Usa cuentas de usuario del servidor (control granular con claves SSH).
  • Eficiencia: Protocolo optimizado para transferencia de datos (similar en velocidad a local).
Desventajas:
  • Configuración inicial: Requiere gestionar claves SSH y acceso de usuarios.
  • Acceso anónimo: No es adecuado para repositorios públicos (obliga a tener cuenta SSH).
Protocolo HTTP/HTTPS
Ideal para repositorios públicos o con autenticación básica (ej: GitHub, GitLab).
git clone http://example.com/ruta/project.git     # Sin encriptar  
git clone https://example.com/ruta/project.git    # Con encriptación SSL
Ventajas:
  • Acceso universal: Funciona detrás de firewalls/proxies (puertos 80/443 abiertos).
  • Autenticación flexible: Compatible con sistemas como OAuth o LDAP (vía HTTPS).
  • Repositorios públicos: Permite clonar sin credenciales (solo lectura).
  • Fácil despliegue: Usa servidores web estándar (Apache, Nginx).
Desventajas:
  • Rendimiento: Más lento que SSH o local (overhead de HTTP).
  • Autenticación básica: En HTTP, credenciales viajan en texto plano (HTTPS es obligatorio para seguridad).
  • Complejidad en push: Requiere configuración adicional (WebDAV o Smart HTTP).
Git Hub
GitHub es una plataforma de desarrollo colaborativo en la nube que permite gestionar proyectos de software utilizando Git. Ofrece herramientas para:
  • Alojar repositorios de código.
  • Realizar seguimiento de cambios.
  • Colaborar mediante pull requests y issues.
  • Gestionar flujos de trabajo con integración continua y despliegue automático.
Cambio de "master" a "main"
GitHub modificó el nombre predeterminado de la rama principal de master a main como parte de una iniciativa para promover un lenguaje más inclusivo.
Motivación: Evitar connotaciones negativas asociadas a "master" (en contextos históricos de esclavitud).
Impacto: Otras plataformas también adoptaron términos neutrales, aunque Git internamente aún usa "master" en algunos comandos.
Creación de un repositorio
Antes de empezar, es necesario crear un repositorio (local o remoto en GitHub) para gestionar el código.
Usaremos VS Code para trabajar con GitHub.
Repositorios públicos o privados
Configuración Inicial del Repositorio
Tres elementos clave al crear un repositorio en GitHub:
  1. README.md
  • Función: Documentación principal del proyecto (propósito, instalación, uso).
  • Formato: Markdown (.md). Se muestra automáticamente en la página del repositorio.
  • Importancia: Primera impresión para colaboradores/visitantes.
  1. .gitignore
  • Función: Excluir archivos no relevantes (ej: temporales, binarios) del control de versiones.
  • Ventaja: Mantiene el repositorio limpio y evita subir archivos innecesarios.
  1. Licencia
  • Objetivo: Define términos legales para usar/modificar/distribuir el código.
  • Opciones comunes:
  • MIT: Libre uso (requiere atribución).
  • GPL: Código derivado debe ser open-source bajo misma licencia.
  • Apache: Similar a MIT, pero con cláusulas adicionales de patentes.
En este caso, se configurará el repositorio con:
  • Un README.md básico (formato Markdown).
  • Archivo .gitignore para excluir archivos generados automáticamente (ej: node_modules/, .env).
  • Licencia MIT (permisiva y ampliamente adoptada).
Pasos para configurar un repositorio local y sincronizarlo con GitHub
1. Crear el archivo README.md
echo "# cursoGit" >> README.md
Crea un archivo README.md con el texto # cursoGit (formato Markdown).
2. Inicializar el repositorio Git
git init
Crea un directorio oculto .git con la estructura necesaria para el control de versiones.
3. Agregar el README al área de staging
git add README.md
Prepara el archivo para ser incluido en el primer commit.
4. Realizar el primer commit
git commit -m "first commit"
Guarda los cambios en el historial del repositorio con un mensaje descriptivo.
5. Renombrar la rama principal a main (opcional)
git branch -M main
Cambia el nombre de la rama predeterminada de master a main (práctica recomendada).
6. Vincular el repositorio local con GitHub
git remote add origin https://github.com/martin2745/cursoGit.git
Asocia el repositorio local con el remoto usando el alias origin (nombre convencional).
7. Subir cambios al repositorio remoto
git push -u origin main
Envía los commits a GitHub y establece main como rama predeterminada para futuros push.
Conceptos clave
  • origin: Es el nombre por defecto que Git asigna al repositorio remoto. Simplifica futuros comandos como git push o git pull.
  • Eliminar ramas locales no necesarias: Elimina ramas locales que ya no se usen (ej: ramas de prueba).
git branch -d nombreRama
Nota: Estos pasos son esenciales para comenzar un proyecto bajo control de versiones y colaborar mediante GitHub. La opción -u en git push evita especificar la rama remota en futuras actualizaciones.
Secciones clave de un repositorio en GitHub
Wiki vs README:
  • El README.md es la carta de presentación del repositorio.
  • La Wiki alberga documentación extensa (ej: manuales de usuario).
Estas herramientas facilitan la colaboración, automatización y mantenimiento de proyectos en GitHub. La pestaña Settings es crítica para gestionar permisos y seguridad.
Opciones para clonar un repositorio (Botón "Code")
HTTPS
  • Proporciona una URL para clonar el repositorio mediante el protocolo HTTPS.
git clone https://github.com/usuario/repositorio.git
  • Ventajas:
  • Funciona sin configuración adicional.
  • Ideal para principiantes o acceso rápido.
SSH
  • Ofrece una URL para clonar usando autenticación con claves SSH.
  • Requisitos:
  • Uso:
git clone git@github.com:usuario/repositorio.git
  • Ventajas:
  • Mayor seguridad (encriptación).
  • No requiere ingresar credenciales repetidamente.
Descargar ZIP
  • Permite descargar el código fuente como archivo ZIP.
  • Limitaciones:
  • No mantiene el historial de Git.
  • No permite actualizaciones posteriores con git pull.
Visualización de commits
Clic en "Commits" en la interfaz de GitHub.
  • Funcionalidades:
  • Historial completo: Lista ordenada de todos los commits.
  • Detalles por commit:
  • Cambios realizados (diff).
  • Autor y fecha.
  • Mensaje del commit.
  • Ejemplo: Al inspeccionar el commit "Conflicto solucionado", se pueden ver:
  • Archivos modificados.
  • Líneas específicas añadidas/eliminadas.
Hacer un commit desde GitHub
Vamos a modificar README.md y después hacemos un commit
Ahora tenemos dos commits
Es importante mencionar que estas modificaciones tenemos que añadirlas a nuestro repositorio local ya que en este momento solo existe en remoto.
Para ello empleamos el comando:
git pull
Cargar y descargar de GitHub
1. Traer cambios del remoto sin fusionar automáticamente con el local
  • Sincroniza información remota sin modificar el código local.
  • Verifica diferencias entre tu rama local y la remota antes de fusionar (git diff).
  • Es seguro: No altera tu historial ni tus archivos de trabajo.
git fetch <remoto> <rama>
  • <remoto>: Nombre del repositorio remoto (usualmente origin).
  • <rama>: Rama específica a descargar (opcional).
Ejemplos:
Descargar todos los cambios del remoto:
git fetch origin
Descargar cambios de una rama específica (ej: main):
git fetch origin main
2. Traer cambios del remoto fusionando con el local
Descarga los últimos cambios del repositorio remoto y los fusiona con tu rama local.
git pull <remoto> <rama>
  • <remoto>: Generalmente origin (el nombre por defecto del repositorio remoto).
  • <rama>: La rama que quieres actualizar (ej: main, develop).
Ejemplo
git pull origin main
  • Descarga los cambios de la rama main del remoto origin y los fusiona con tu rama local actual.
Opciones:
3. Enviar cambios al remoto
Sube tus commits locales al repositorio remoto.
git push <remoto> <rama>
  • <remoto>: Normalmente origin.
  • <rama>: La rama que quieres subir (ej: main, feature/login).
Ejemplo
git push origin main
  • Sube los commits de tu rama local main al repositorio remoto (origin).
Opciones:
Resumen de Flujo de Trabajo
1. Antes de trabajar:
git pull origin main  # Actualiza tu repositorio local.
2. Después de hacer cambios:
git add .            # Añade los cambios al staging.
git commit -m "Mensaje"  # Crea un commit.
git push origin main # Sube los cambios al remoto.
Posibles Errores y Soluciones
❌ ! [rejected] main -> main (non-fast-forward)
  • Causa: El remoto tiene cambios que no tienes localmente.
  • Solución:
git pull origin main  # Fusiona los cambios primero.
git push origin main # Vuelve a intentar el push.
❌ fatal: The current branch has no upstream branch
  • Causa: No has configurado la rama remota.
  • Solución:
git push -u origin main  # Establece upstream.
Resumiendo…
  • git pull → Actualiza tu repositorio local con cambios remotos.
  • git push → Envía tus cambios locales al repositorio remoto.
  • git fetch → Ideal para flujos de trabajo colaborativos donde la revisión de código es fundamental.
  • Siempre haz pull antes de push para evitar conflictos.
Si trabajas en equipo, evita --force para no romper el historial de tus compañeros.
Clonar un repositorio
Clonar repositorio
Puedes clonar un repositorio con git clone [url]:
git clone git://github.com/schacon/grit.git
Crear directorio
Esto crea un directorio llamado "grit", inicializa un directorio .git en su interior, descarga toda la información de ese repositorio, y saca una copia de trabajo de la última versión.
Personalizar nombre
Si quieres clonar el repositorio a un directorio con otro nombre que no sea grit, puedes especificarlo con la siguiente opción de línea de comandos:
git clone git://github.com/schacon/grit.git mygrit
Práctica guiada de GitHub
Objetivo: Practicar comandos básicos de Git (clone, add, commit, push, pull, fetch) y familiarizarte con GitHub.
Crear un repositorio en GitHub
  1. Ve a GitHub y haz clic en "New repository".
  1. Nómbralo mi-primer-proyecto.
  1. Elige público y marca la opción "Add a README.md".
  1. Haz clic en "Create repository".
Clonar el repositorio a tu máquina local
git clone https://github.com/tu-usuario/mi-primer-proyecto.git
cd mi-primer-proyecto
Hacer cambios locales y subirlos a GitHub
Crea un archivo hola-mundo.txt:
echo "¡Hola, GitHub!" > hola-mundo.txt
Añádelo al área de staging y haz un commit:
git add hola-mundo.txt
git commit -m "Añadir archivo de saludo"
Súbelo a GitHub:
git push origin main
Simular un cambio externo (en GitHub)
  1. Ve a tu repositorio en GitHub.
  1. Edita el README.md directamente en GitHub (añade una línea como ## Este es mi primer proyecto).
  1. Guarda los cambios (haz clic en "Commit changes").
Sincronizar cambios locales con GitHub
Descarga los cambios remotos (sin fusionar aún):
git fetch origin
Compara diferencias entre tu rama local y la remota:
git diff main origin/main
Fusiona los cambios en tu repositorio local:
git pull origin main
Resolver un conflicto (opcional avanzado)
Edita localmente el README.md (añade algo como ### Hecho desde mi computadora).
Haz commit:
git add README.md
git commit -m "Editar README localmente"
Antes de hacer push, edita el mismo archivo desde GitHub (cambia la misma línea).
Intenta hacer git push origin main. Verás un error.
Resuelve el conflicto:
git pull origin main  # Fusiona los cambios y marca conflictos.
# Edita README.md manualmente (elimina marcas de conflicto <<<<<<<).
git add README.md
git commit -m "Resolver conflicto en README"
git push origin main
Trabajar con ramas
Crea una rama nueva:
git checkout -b nueva-rama
Añade un archivo contribucion.txt y haz push de la rama:
git push origin nueva-rama