Es como la diferencia entre entrar a tu casa por la puerta principal versus escalar por la ventana del segundo piso - técnicamente ambos te llevan adentro, pero uno es el camino correcto y seguro.

Déjame explicarte por qué esa distinción es crucial para entender el verdadero valor de las PRs en un entorno profesional.

La diferencia clave: Control vs Colaboración

Cuando ejecutas esos comandos git directamente, estás actuando como el “dictador benevolente” de tu repositorio. Tienes el poder absoluto de decidir qué código entra y cuándo entra. Esto funciona perfectamente cuando eres el único desarrollador o cuando tienes total confianza en tu código, pero se vuelve problemático en equipos más grandes.

El proceso de Pull Request introduce una capa de governance (gobernanza) y peer review (revisión entre pares) que transforma esa operación técnica simple en un proceso colaborativo estructurado. Es como la diferencia entre cocinar solo en tu casa versus cocinar en un restaurante donde hay un chef ejecutivo que debe aprobar cada plato antes de que salga a la mesa.

Lo que realmente pasa “detrás de escena”

Cuando creas una Pull Request, la plataforma (GitHub, GitLab, Bitbucket, etc.) está esencialmente preparando esos mismos comandos git que mencionaste, pero los mantiene en un estado de “propuesta” hasta que se cumplan ciertas condiciones. Es como tener todos los ingredientes de una receta listos en la mesa, pero esperando la señal del chef para empezar a cocinar.

Durante este período de “espera”, pueden ocurrir varias cosas importantes que no suceden con el merge directo. Los sistemas de Continuous Integration pueden ejecutar baterías completas de tests automatizados, herramientas de análisis estático pueden revisar tu código en busca de code smells (olores de código - esas prácticas que técnicamente funcionan pero que a largo plazo causan problemas), y otros desarrolladores pueden revisar tu lógica línea por línea.

El concepto de “Branch Protection”

Aquí es donde se pone realmente interesante desde una perspectiva DevOps. En repositorios profesionales, la rama develop (y definitivamente main o master) suele tener branch protection rules (reglas de protección de rama) habilitadas. Esto significa que literalmente no puedes ejecutar ese git push origin develop si no cumples ciertos requisitos.

Es como si la puerta de la casa tuviera múltiples cerraduras, y cada una requiere una llave diferente. Algunas de estas “llaves” pueden ser que al menos dos personas hayan aprobado tu código, que todos los tests automáticos pasen, que no haya merge conflicts sin resolver, o que el código cumpla con ciertos estándares de calidad medidos por herramientas como SonarQube o CodeClimate.

El flujo completo en contexto real

Permíteme mostrarte cómo se vería tu ejemplo en un entorno de desarrollo real con PRs habilitadas:

Tu flujo actual (comando directo):

git checkout develop                       # Cambias a develop
git merge --no-ff feature/logs-de-usuario  # Fusionas tu feature
git branch -d feature/logs-de-usuario      # Borras la rama local  
git push origin develop                    # Subes los cambios

El flujo equivalente con Pull Requests:

git push origin feature/logs-de-usuario    # Subes tu rama al repositorio remoto
# Aquí creas la PR desde la interfaz web
# Esperas revisiones y aprobaciones
# Una vez aprobada, alguien (o tu mismo) hace clic en "Merge"
# El sistema ejecuta automáticamente algo similar a tus comandos originales

La diferencia es que entre el git push de tu rama y el merge final, hay un espacio para el quality gate (puerta de calidad) donde el equipo puede intervenir.

¿Por qué este proceso “extra” vale la pena?

Podrías preguntarte: si al final se ejecutan los mismos comandos git, ¿por qué complicar las cosas? La respuesta está en los beneficios que obtienes durante ese período intermedio.

Knowledge Transfer: Cuando otros desarrolladores revisan tu código, no solo están buscando errores. Están aprendiendo sobre la parte del sistema en la que trabajaste, entendiendo tus decisiones de diseño, y potencialmente sugiriendo mejores approaches. Es como tener una pair programming (programación en pareja) session asíncrona.

Risk Mitigation: Los tests automatizados y las revisiones manuales actúan como múltiples redes de seguridad. Es mucho menos probable que un bug crítico llegue a producción si ha pasado por varios filtros de calidad.

Documentation Automática: La descripción de tu PR, junto con los comentarios de la revisión, se convierte en documentación histórica de por qué se hicieron ciertos cambios. Esto es invaluable cuando alguien (incluyéndote a ti mismo en seis meses) necesita entender el contexto de una decisión técnica.

Cuándo usar cada approach

En proyectos personales o en las etapas muy tempranas de un proyecto donde eres el único desarrollador, hacer merge directo está perfectamente bien. Es más rápido y no hay riesgo de romper el trabajo de otros.

Pero tan pronto como tengas un segundo desarrollador en el proyecto, o cuando el código empiece a ir a un entorno que otras personas usan (staging, producción), el proceso de PR se vuelve no solo útil, sino esencial para mantener la code quality (calidad del código) y la team velocity (velocidad del equipo) a largo plazo.

¿Te hace sentido esta distinción? ¿Te gustaría que exploremos algún ejemplo específico de cómo configurar branch protection rules, o prefieres que profundicemos en las mejores prácticas para hacer code reviews efectivos?