Al terminar este bloque vas a poder

Antes de empezar

Dos integrantes de tu equipo modifican el mismo archivo el mismo día

Uno sincroniza su cambio primero

El segundo intenta sincronizar el suyo

Git no lo permite

¿Qué hacen ahora?

Dónde estamos dentro del taller

Bloque I    Del problema al producto
Bloque II   Colaboración y arquitectura      ← estás aquí
Bloque III  Construcción del sistema
Bloque IV   Contenedores despliegue y escalabilidad
Bloque V    Integración y presentación final

Lo que ya tienen y lo que falta

¿Qué es Git?

Git permite

• volver a cualquier punto anterior del historial
• saber quién cambió qué y por qué
• que varias personas trabajen en el mismo proyecto sin sobrescribirse

¿Qué almacena realmente un commit?

Un error común es pensar que un commit almacena "solo lo que cambió" como si fuera un diff acumulado.

Internamente Git es eficiente y no duplica archivos que no cambiaron pero conceptualmente cada commit es un punto en el tiempo completo al que siempre puedes volver.

Referencia — Pro Git capítulo 1 sección "What is Git" git-scm.com/book

Centralizado vs distribuido

Por eso pueden hacer commit sin conexión a internet y sincronizar después con push

Git no es GitHub ni GitLab

Este bloque necesita ambos Git para versionar y la plataforma para colaborar

Para profundizar en Git

• Documentación oficial — git-scm.com/doc
• Pro Git libro completo y gratuito — git-scm.com/book
• Referencia rápida de comandos — git-scm.com/docs

El libro Pro Git está disponible completo en español desde el mismo sitio

El problema que Git resuelve

Cuatro problemas que resuelve

Un dato de contexto

• Se diseñó para que miles de programadores colaboraran sin un servidor central que se convirtiera en cuello de botella.

• Por eso cada persona tiene una copia completa del historial en su propia computadora.

Los tres estados de un archivo

Referencia — Pro Git capítulo 1.3 "The Three States" git-scm.com/book

De un estado a otro

Cada comando básico mueve un archivo de un estado al siguiente

edita el archivo        →  MODIFICADO
git add archivo          →  PREPARADO
git commit -m "..."      →  CONFIRMADO

Por eso es el primer comando que van a ejecutar antes de cualquier otro

Las tres áreas de tu proyecto

A cada estado le corresponde un lugar físico en tu computadora

La carpeta .git — dónde vive todo esto

El directorio de Git de la lámina anterior tiene nombre y ubicación exactos

$ ls -a
.  ..  .git  app  composer.json  routes  ...

git init la crea vacía git clone la crea ya llena con todo el historial descargado

Qué contiene .git

$ ls .git
HEAD  config  objects/  refs/  hooks/  index

Referencia — Pro Git capítulo 1.3 y capítulo 10 "Git Internals" git-scm.com/book

Qué pasa si borras .git

Se pierde para siempre

• todo el historial de commits
• todas las ramas locales
• toda la configuración de ese repositorio

Antes del primer commit — configurar tu identidad

Antes de usar Git en una computadora nueva necesitas decir quién eres

Cada commit que hagas va a quedar firmado con este nombre y correo

$ git config --global user.name "Juan Pérez"
$ git config --global user.email "juan.perez@info.uas.edu.mx"

--global aplica esta configuración a todos los repositorios de tu computadora no solo a uno

Verificar tu configuración

$ git config user.name
Juan Pérez

$ git config user.email
juan.perez@info.uas.edu.mx

$ git config --list
user.name=Juan Pérez
user.email=juan.perez@info.uas.edu.mx
core.editor=nano

Dos formas de empezar un repositorio

Para el proyecto del equipo casi siempre van a usar clone alguien ya creó el repositorio con init la primera vez

Qué hace git clone exactamente

clone no es solo descargar archivos hace cuatro cosas en un solo paso

1. Descarga el historial completo de commits no solo la última versión
2. Crea la carpeta .git local con todo ese historial adentro
3. Crea el directorio de trabajo con la última versión de cada archivo
4. Configura automáticamente un remoto llamado origin apuntando de vuelta al repositorio de donde clonaste

Ejemplo guiado — init y clone

$ git init
Repositorio Git vacío inicializado en /home/juan/reservafic/.git/

$ git clone git@github.com:equipo/reservafic.git
Clonando en 'reservafic'...
remote: Enumerando objetos: 120, listo.
Receiving objects: 100% (120/120), 45.20 KiB | 2.10 MiB/s, listo.

$ cd reservafic
$ git remote -v
origin  git@github.com:equipo/reservafic.git (fetch)
origin  git@github.com:equipo/reservafic.git (push)

clone configuró origin sin que lo pidieran por eso git push y
git pull ya saben a dónde ir

Comandos básicos

Ya configuraron su identidad y ya tienen un repositorio local estos son
los comandos que van a usar todos los días

Qué no debe entrar al repositorio

Laravel genera un .gitignore por defecto al crear el proyecto que ya
excluye lo esencial

/vendor
/node_modules
.env
/storage/*.key
/public/hot

Referencia — documentación oficial de Laravel sección de instalación laravel.com/docs/installation

Por qué importa cada exclusión

Si git status muestra cambios dentro de vendor/ algo está mal
configurado en el .gitignore

Ejemplo guiado — status y add

$ git status
  modificado:  app/Models/Prestamo.php

$ git add app/Models/Prestamo.php
$ git status
  Cambios a ser confirmados:
  modificado:  app/Models/Prestamo.php

Ejemplo guiado — ver qué cambió con diff

Antes de hacer add conviene revisar exactamente qué se modificó

$ git diff app/Models/Equipo.php
diff --git a/app/Models/Equipo.php b/app/Models/Equipo.php
index 3f2a1b0..8c9d2e1 100644
--- a/app/Models/Equipo.php
+++ b/app/Models/Equipo.php
@@ -10,6 +10,7 @@ class Equipo extends Model
     protected $fillable = [
         'nombre',
         'ubicacion',
+        'numero_serie',
     ];

Las líneas con + son nuevas las líneas con - se eliminaron

Ejemplo guiado — commit y log

$ git commit -m "feat: agregar numero_serie al modelo Equipo"
[main a1b2c3d] feat: agregar numero_serie al modelo Equipo
 1 file changed, 3 insertions(+)

$ git log --oneline
a1b2c3d feat: agregar numero_serie al modelo Equipo
9f8e7d6 feat: crear cuenta con validación de correo
3c2b1a0 commit inicial del proyecto

El commit ya quedó en el historial local con un identificador propio

Ejemplo guiado — crear tu primera rama

$ git branch
* main

$ git checkout -b feature/numero-serie-equipo
Cambiado a nueva rama 'feature/numero-serie-equipo'

$ git branch
* feature/numero-serie-equipo
  main

El asterisco muestra en qué rama estás parado ahora mismo

Ejemplo guiado — sincronizar con el remoto

$ git push origin feature/numero-serie-equipo
Enumerando objetos: 5, listo.
To github.com:equipo/reservafic.git
 * [new branch]      feature/numero-serie-equipo -> feature/numero-serie-equipo

$ git pull origin main
De github.com:equipo/reservafic.git
Ya está actualizado.

push sincroniza tus commits hacia el remoto pull sincroniza los commits nuevos del equipo hacia tu copia local

Una rama es trabajo aislado

Técnicamente una rama es solo un puntero a un commit crearla es instantánea y barata

main
 └── feature/nombre-corto-de-la-funcionalidad

Modelo con ReservaFIC

Ambos parten de main

Ambos trabajan en paralelo

Ninguno bloquea al otro

De una rama suelta a una estrategia

Ese acuerdo del equipo se llama una estrategia de ramificación no es
una regla de Git es una regla del equipo

Tres estrategias comunes

Comparativa

Referencias — Driessen "A successful Git branching model" nvie.com — GitHub Flow docs.github.com — Trunk-Based Development trunkbaseddevelopment.com

Cuál usa ReservaFIC

• Su equipo es pequeño
• No hay releases formales con número de versión que coordinar entre
  clientes distintos
• main siempre debe quedar en un estado funcional

Git Flow tiene sentido cuando existen varias versiones en producción al
mismo tiempo algo que este proyecto académico no tiene

Ejemplo guiado — ciclo de vida completo de una rama

Paso 1 y 2 — crear la rama y trabajar

$ git checkout -b feature/numero-serie-equipo
Cambiado a nueva rama 'feature/numero-serie-equipo'

$ git add app/Models/Equipo.php database/migrations/2026_09_13_000000_add_numero_serie_to_equipos_table.php
$ git commit -m "feat: agregar numero_serie al modelo Equipo"
[feature/numero-serie-equipo 4f5e6d7] feat: agregar numero_serie al modelo Equipo
 2 files changed, 12 insertions(+)

Paso 3 — sincronizar la rama

$ git push origin feature/numero-serie-equipo
Enumerando objetos: 7, listo.
To github.com:equipo/reservafic.git
 * [new branch]      feature/numero-serie-equipo -> feature/numero-serie-equipo

La rama ya existe en GitHub lista para abrir un pull request

Paso 4 y 5 — integrar y cerrar

Desde GitHub abren el pull request el equipo revisa y aprueban el merge

$ git checkout main
$ git pull origin main
From github.com:equipo/reservafic.git
 * branch            main       -> FETCH_HEAD
Actualizando a1b2c3d..9e8f7d6
Fast-forward
 app/Models/Equipo.php | 4 ++++
 1 file changed, 4 insertions(+)

$ git branch -d feature/numero-serie-equipo
Eliminada la rama feature/numero-serie-equipo (era 4f5e6d7)

Pull request y code review

Si tu plataforma es GitLab el mismo concepto se llama merge request

Estrategias de fusión

Git elige automáticamente cómo fusionar no es algo que decidan ustedes
manualmente cada vez

Referencia — Pro Git capítulo 3.2 sección "Basic Merging" git-scm.com/book

Ejemplo guiado — merge sin conflicto

Antes de ver un conflicto observa cómo se ve un merge que sale bien

$ git checkout main
$ git merge feature/validar-doble-reserva
Actualizando 9e8f7d6..2c1b0a9
Fast-forward
 app/Services/ReservaService.php | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

Fast-forward significa que main no tenía commits nuevos propios
Git simplemente movió el puntero hacia adelante

Qué es una auto-fusión

Dos integrantes cambiaron el mismo archivo pero en partes distintas
Git no necesita ayuda para combinarlas

$ git merge feature/agregar-reporte
Auto-fusionando app/Http/Controllers/ReporteController.php
Merge made by the 'ort' strategy.
 app/Http/Controllers/ReporteController.php | 12 ++++++++++++
 1 file changed, 12 insertions(+)

La ventana que se abre para el mensaje de fusión

Un merge que no es fast-forward crea un commit nuevo y ese commit
necesita un mensaje

Merge branch 'feature/agregar-reporte' into main

# Escribe un mensaje para explicar por qué es necesaria esta fusión
# especialmente si fusiona una rama actualizada dentro de una rama
# de tema

Git abre tu editor configurado con este mensaje ya escrito

Si su editor es nano guardan con Ctrl+O Enter y cierran con Ctrl+X

Para saltarse la ventana y aceptar el mensaje por defecto directamente git merge rama --no-edit

Conflicto de fusión

Un conflicto no es un error del sistema

Es Git pidiendo que una persona decida

Referencia — Pro Git capítulo 3.2 "Basic Branching and Merging" sección de conflictos git-scm.com/book

Cómo se ve un conflicto real

Dos integrantes modificaron la misma validación en ReservaService.php
uno cambió el límite de días el otro cambió el mensaje de error

$ git merge feature/validar-limite-dias
Auto-fusionando app/Services/ReservaService.php
CONFLICTO (contenido): Conflicto de fusión en app/Services/ReservaService.php
La fusión automática falló arregla los conflictos y confirma el resultado

$ git status
Tienes rutas no fusionadas
  ambos modificados:  app/Services/ReservaService.php

Git se detuvo a la mitad del merge y está esperando que decidan

Los marcadores de conflicto

Al abrir el archivo Git marcó exactamente dónde chocan las dos versiones

public function validarLimite($dias)
{
<<<<<<< HEAD
    if ($dias > 7) {
        throw new Exception('Máximo 7 días de préstamo');
    }
=======
    if ($dias > 5) {
        throw new Exception('El límite de préstamo fue excedido');
    }
>>>>>>> feature/validar-limite-dias
}

Técnicas para resolver un conflicto

Más técnicas y cuándo abortar

git merge --abort

Ejemplo guiado — resolver el conflicto paso a paso

Paso 1 — decidir juntos y editar el archivo

Después de hablar con el equipo deciden conservar el límite de 7 días
pero con el mensaje más claro

public function validarLimite($dias)
{
    if ($dias > 7) {
        throw new Exception('El límite de préstamo fue excedido');
    }
}

Los marcadores <<<<<<< ======= y >>>>>>> ya no están en el archivo

Paso 2 — marcar como resuelto y confirmar

$ git add app/Services/ReservaService.php
$ git status
Todos los conflictos arreglados pero seguimos en fusión

$ git commit
[main 7d6c5b4] Merge branch 'feature/validar-limite-dias'

add le dice a Git que ya decidiste commit sin -m abre el editor
con un mensaje de merge ya escrito que pueden dejar tal cual

Paso 3 — confirmar que quedó limpio

$ git status
En la rama main
nada para hacer commit el árbol de trabajo está limpio

$ git log --oneline -3
7d6c5b4 Merge branch 'feature/validar-limite-dias'
2c1b0a9 feat: agregar validación de límite de días
4f5e6d7 feat: cambiar mensaje de error de límite

Comandos que van a necesitar pronto

git stash — guardar trabajo sin terminar

Cambiar de rama con cambios a medias sin hacer commit puede fallar Git
te va a pedir que resuelvas eso primero

$ git stash
Guardado el directorio de trabajo y el estado del índice WIP on
feature/numero-serie-equipo: 4f5e6d7 feat: agregar numero_serie

$ git status
nada para hacer commit el árbol de trabajo está limpio

$ git stash pop
Cambios no en el área de stage para el commit:
  modificado: app/Models/Equipo.php

stash guarda tus cambios a un lado pop los regresa

git reset vs git revert — dos formas de deshacer

$ git revert a1b2c3d
[main f3e2d1c] Revert "feat: agregar numero_serie al modelo Equipo"
 1 file changed, 3 deletions(-)

git log --graph — visualizar el árbol de commits

$ git log --oneline --graph --all
* 9e8f7d6 (HEAD -> main, origin/main) merge pull request #12
|\
| * 4f5e6d7 (origin/feature/numero-serie-equipo) feat: agregar numero_serie
|/
* a1b2c3d commit inicial

Este es el mismo dibujo que las estrategias de ramificación solo que
generado directamente desde tu historial real

Ampliación — más allá del temario oficial

Conventional Commits

<tipo>[ámbito opcional]: <descripción>

feat: nueva funcionalidad
fix: corrección de un error
docs: cambios de documentación
refactor: cambio interno sin alterar el comportamiento

Ámbito y cambios incompatibles

feat(prestamos): agregar validación de fecha de devolución

Un cambio que rompe algo que ya funcionaba se marca con !

feat!: cambiar el formato de respuesta de la API de préstamos

o con un pie BREAKING CHANGE en el cuerpo del commit

Versionado semántico — SemVer

MAYOR . MENOR . PARCHE

Conventional Commits y SemVer combinados

Un commit fix: normalmente sube el número de PARCHE

Un commit feat: normalmente sube el número MENOR

Un commit feat!: o con BREAKING CHANGE sube el número MAYOR

No es casualidad ambas especificaciones se diseñaron para combinarse

Del historial a un changelog

Como ya escriben feat: fix: docs: de forma consistente ese mismo
historial se puede agrupar automáticamente en un changelog

## [0.2.0] - 2026-09-16
### Added
- Validación de límite de días en préstamos

### Fixed
- Mensaje de error poco claro en validación de límite

Formato de referencia — Keep a Changelog keepachangelog.com

Un changelog se escribe para quien lo lee no para quien lo escribió

Herramientas como conventional-changelog o standard-version generan
este documento leyendo directamente sus mensajes de commit siempre que
sigan la convención

Etiquetas (tags) en Git

git tag -a v0.1.0 -m "Primer incremento funcional del Bloque II"
git push origin v0.1.0

-a crea una etiqueta anotada almacena autor fecha y mensaje

Ejemplo guiado — anotada vs ligera

$ git tag prueba-ligera
$ git tag -a prueba-anotada -m "Etiqueta de prueba"

$ git show prueba-ligera
commit a1b2c3d...

$ git show prueba-anotada
tag prueba-anotada
Tagger: Equipo ReservaFIC
Date:   Sat Sep 13 2026
Etiqueta de prueba

commit a1b2c3d...

La anotada almacena quién y cuándo la ligera solo apunta al commit

Actividad — Laboratorio 1

Guía completa: bloque02_lab01_git_colaborativo.md

Integrar con frecuencia reduce el riesgo

Una rama que vive semanas sin integrarse acumula diferencias con main

Cambios pequeños

Revisión constante

Integración frecuente

Menos probabilidad de un conflicto grande y difícil de resolver

Fuente oficial — Clean Code sobre cambios pequeños

Es la razón técnica detrás de la convención de mensajes de commit
feat: fix: docs: refactor: del Laboratorio 1

Más buenas prácticas de Clean Code

Referencia — Martin Robert C Clean Code (REF-B2-04) capítulos 2 3 y 4

Issues gestión de incidencias

Un repositorio sin issues obliga al equipo a recordar de memoria qué falta

Definition of Done

Este bloque retoma la DoD simple del Bloque I y la vuelve exigente de
verdad

Propuesta de Definition of Done para este bloque

Un incremento está terminado cuando se puede marcar cada punto

Este es un punto de partida cada equipo puede ampliarlo según su proyecto no reduzcan estos cuatro puntos

Cuatro principios

Fuente oficial — Clean Architecture y la regla de dependencia

En Laravel esto significa que el Service no debería depender de detalles
de Eloquent más de lo necesario es la idea que van a aplicar en el
Laboratorio 2 y en el Laboratorio 3 con Repository

Arquitecturas comunes

Su proyecto sigue siendo un monolito multicapa este bloque no lo convierte en microservicios

Antes del refactor con ReservaFIC

public function store(Request $request)
{
    $request->validate([...]);
    $conflicto = Prestamo::where(...)->exists();
    if ($conflicto) { return back()->withErrors('...'); }
    Prestamo::create($request->all());
    return redirect()->route('prestamos.index');
}

Validación regla de negocio y persistencia mezcladas en un solo lugar

Después del refactor con ReservaFIC

FormRequest   valida la forma de los datos
Service       decide la regla de negocio
Controlador   coordina no decide

Actividad — Laboratorio 2

Guía completa: bloque02_lab02_arquitectura.md

Un patrón tiene tres partes

Fuente oficial — el catálogo original

No van a aprender los 23 en este bloque solo el que resuelve un problema
real de su proyecto

Tres familias

La pregunta correcta

Un patrón donde no hace falta agrega complejidad sin beneficio

Modelo con ReservaFIC — Repository

El problema

El Service llama directamente a Eloquent

Si cambian de motor de base de datos hay que tocar el Service

El patrón

Repository separa el Service de los detalles de acceso a datos

Actividad — Laboratorio 3

Guía completa: bloque02_lab03_patrones_diseno.md

Cierre — volviendo al problema inicial

Retoma la situación del inicio

Dos integrantes modifican el mismo archivo y uno no sabe qué hacer con
el conflicto

Con ramas de característica ese problema no habría bloqueado a ninguno

El conflicto es Git pidiendo que alguien decida

Un pull request con revisión real lo hubiera detectado antes

En síntesis

• Git almacena un historial único y permite combinar trabajo en
  paralelo de forma controlada
• Las ramas de característica permiten trabajar en paralelo según
  la estrategia de ramificación que elija el equipo
• Un pull request con code review real evita código sin revisar
• Un conflicto de fusión se resuelve decidiendo no evitando
• Conventional Commits y SemVer dan estructura y significado al
  historial y a las etiquetas de versión
• Separación de responsabilidades cohesión y acoplamiento organizan
  el código antes de que crecer sea un problema
• Un patrón de diseño resuelve un problema real identificado primero

Lo que sigue

En el Bloque III van a construir componentes APIs persistencia de
datos y pruebas automatizadas sobre la arquitectura que documentaron
aquí

Referencias

• Gamma Helm Johnson y Vlissides — Design Patterns (1994)
• Freeman y Robson — Head First Design Patterns (2020)
• Martin Robert C — Clean Architecture (2017)
• Martin Robert C — Clean Code (2008)
• Hunt y Thomas — The Pragmatic Programmer (2019)
• Documentación oficial de Git — git-scm.com/doc
• Conventional Commits — especificación v1.0.0 (ampliación) — conventionalcommits.org
• Semantic Versioning — especificación v2.0.0 (ampliación) — semver.org
• Driessen — A successful Git branching model (ampliación) — nvie.com
• GitHub Flow — documentación oficial (ampliación) — docs.github.com
• Trunk-Based Development (ampliación) — trunkbaseddevelopment.com

Ficha completa de cada fuente con relevancia por contenido: bloque02_materiales_referencias.md (REF-B2-01 a REF-B2-T07)