← Volver al listado de tecnologías ← Índice de Forgejo

Forgejo: Pull Requests - flujo de revision

28 de febrero de 2026 Por: Artiko

forgejopull-requestscode-reviewbranch-protectionmerge

Capitulo 10: Pull Requests en Forgejo

Un Pull Request (PR) es el mecanismo formal para proponer cambios al codigo base. Combina la revision de codigo, la discusion y la integracion continua en un solo lugar.

Crear un Pull Request

Desde una rama del mismo repositorio

El flujo habitual es trabajar en una rama y luego abrir un PR hacia main (o la rama base de tu proyecto):

# Crear y cambiar a una nueva rama
git checkout -b feat/nueva-funcionalidad

# Hacer cambios y commit
git add .
git commit -m "feat: agregar exportacion CSV"

# Subir la rama al remoto
git push origin feat/nueva-funcionalidad

Forgejo detecta la rama recien subida y muestra un banner con el boton Compare & Pull Request. Haz click para abrir el formulario de creacion.

Desde un fork

Si no tienes permisos de escritura en el repositorio original, puedes hacer un fork y abrir el PR desde tu copia:

Haz fork del repositorio desde la UI de Forgejo
Clona tu fork y trabaja en una rama
Sube los cambios a tu fork
En la UI de tu fork, Forgejo ofrece la opcion de crear un PR hacia el repositorio original

Campos del formulario

Base branch: la rama de destino (generalmente main o develop).

Compare branch: la rama con tus cambios.

Titulo: describe que hace el PR. Usa el mismo formato que los commits: feat: agregar exportacion CSV.

Descripcion: explica el contexto, los cambios realizados y como probarlos. Soporta Markdown completo.

Reviewers: usuarios que deben revisar el PR. Puedes agregar multiples reviewers.

Labels: para clasificar el PR (igual que en issues).

Milestone: para asociar el PR a un objetivo.

Proceso de revision (Code Review)

Comentarios en linea

Al abrir la pestana Files changed en un PR, puedes hacer click en cualquier linea de codigo para agregar un comentario especifico. Esto es mas preciso que comentar en el hilo general.

Para agregar un comentario a multiples lineas consecutivas, arrastra desde la primera hasta la ultima linea antes de hacer click.

Agregar sugerencias de codigo

En un comentario en linea, puedes proponer un cambio especifico usando el bloque de sugerencia:

```suggestion
nueva linea de codigo aqui
```

El autor del PR puede aplicar la sugerencia con un solo click, lo que genera un commit automatico con el cambio propuesto.

Estados de revision

Cuando terminas de revisar, selecciona uno de los tres estados:

Comment: dejas comentarios sin tomar una decision formal
Approve: apruebas el PR, esta listo para mergear
Request changes: solicitas cambios antes de poder aprobar

El autor recibe una notificacion en cada caso. El PR muestra visualmente cuantas aprobaciones tiene y si hay revisiones que solicitan cambios.

Conversaciones

Los comentarios pueden marcarse como resueltos una vez que el autor los atiende. Esto mantiene el hilo de revision limpio y hace visible el progreso.

Estrategias de merge

Forgejo ofrece tres estrategias de merge. La correcta depende del flujo de trabajo de tu equipo.

Merge Commit

main:    A --- B --------- M
                 \         /
feature:          C --- D

Crea un commit de merge que une las dos ramas. Preserva el historial completo de commits de la rama feature. El historial queda no lineal pero muestra exactamente que rama introdujo que cambios.

Cuando usarla: proyectos que requieren trazabilidad completa, cuando los commits individuales de la rama tienen valor historico.

Squash and Merge

main:    A --- B --- S
                 \
feature:          C --- D (aplastados en S)

Combina todos los commits de la rama en uno solo antes de mergear. El historial de main queda lineal y limpio. Los commits intermedios de trabajo (WIP, typos, etc.) no llegan a main.

Cuando usarla: ramas con muchos commits pequenos de trabajo que no agregan valor al historial. Es la estrategia mas comun en proyectos con historial cuidado.

Rebase and Merge

main:    A --- B --- C' --- D'
                 \
feature:          C --- D (rebase sobre B)

Reaplica los commits de la rama uno a uno sobre la rama base, creando historial lineal sin commit de merge. Cada commit mantiene su mensaje original.

Cuando usarla: cuando los commits son atomicos y con buenos mensajes, y se quiere un historial lineal sin sacrificar la granularidad.

Branch Protection Rules

Las reglas de proteccion de ramas evitan cambios accidentales en ramas criticas.

Configurar proteccion

Ve a Settings del repositorio > Branches > Add Branch Protection Rule.

Nombre del patron: puede ser el nombre exacto de la rama (main) o un patron con wildcard (release/*).

Opciones disponibles

Requerir aprobaciones antes del merge: define cuantas aprobaciones son necesarias (1, 2, etc.). Un PR no se puede mergear hasta alcanzar el numero requerido.

Requerir que los checks de status pasen: selecciona que checks de CI deben estar en estado “success” antes de permitir el merge. Esto integra Forgejo Actions u otros sistemas de CI.

Bloquear push directo: obliga a que todos los cambios entren por un PR. Ni siquiera los administradores pueden hacer push directo a la rama protegida.

Bloquear force push: impide sobrescribir el historial de la rama. Critico para ramas compartidas.

Bloquear eliminacion de la rama: impide que alguien borre la rama protegida accidentalmente o de forma maliciosa.

Requerir que las ramas esten actualizadas: el PR debe estar al dia con la rama base antes de poder mergear. Reduce los conflictos post-merge.

Ejemplo de configuracion para `main`

Patron: main
- Bloquear push directo: activado
- Bloquear force push: activado
- Bloquear eliminacion: activado
- Aprobaciones requeridas: 1
- Status checks requeridos: ci/build, ci/test

Auto-merge

El auto-merge permite configurar un PR para que se mergee automaticamente cuando se cumplan todas las condiciones requeridas (aprobaciones y checks de CI).

Habilitar auto-merge en un PR

En la pagina del PR, si el repositorio tiene auto-merge habilitado, aparece el boton Enable Auto-Merge junto al boton de merge manual.

Al activarlo, seleccionas la estrategia de merge (commit, squash o rebase) y el PR queda en espera. En cuanto se cumplen todas las condiciones, Forgejo realiza el merge automaticamente.

Esto es util cuando:

El CI tarda varios minutos y no quieres esperar
Tienes un PR aprobado pero falta un check que todavia esta corriendo

Cerrar ramas automaticamente despues del merge

Activar esta opcion en Settings > Pull Requests elimina automaticamente la rama feature despues de que el PR es mergeado. Mantiene el repositorio limpio sin acumular ramas obsoletas.

Si necesitas recuperar la rama despues del merge, Forgejo muestra el boton Restore Branch durante un tiempo en la pagina del PR cerrado.

Draft PRs

Un Draft PR indica que el trabajo esta en progreso y no esta listo para revision formal.

Crear un Draft PR

Al abrir el formulario de creacion, en el boton de submit hay una flecha desplegable que ofrece la opcion Create Draft Pull Request.

Comportamiento de un Draft

Aparece marcado como “Draft” en la lista de PRs
Los reviewers reciben notificacion pero saben que no deben revisar todavia
El boton de merge esta desactivado, incluso si se cumplen todas las condiciones
Es posible agregar comentarios y hacer commits adicionales normalmente

Convertir a PR listo

Cuando el trabajo esta completo, el autor presiona Mark as Ready for Review en la pagina del PR. Esto notifica a los reviewers y habilita el proceso de revision formal.

Siguiente: Capitulo 11: Organizaciones y equipos —>