Tu primer Pull Request: de la rama al merge

Pull Request… suena a ejercicio de gimnasio, pero nada que ver. Es esa cosa que suena complicada pero que, una vez que le agarrás la mano, se vuelve natural.

Si ya sabés qué es un PR (básicamente, pedir permiso educadamente para cambiar código), ahora te voy a mostrar cómo hacerlo paso a paso, sin que te agarre un ataque de pánico cuando veas la pantalla de GitHub.

Antes de Empezar: El Setup Mental

Supongamos que ya tenés un repositorio clonado en tu máquina. Puede ser un proyecto personal, uno del laburo, o ese tutorial de React que venís siguiendo hace tres meses.

La buena noticia es que hacer tu primer PR no requiere ser un genio de Git. La mala noticia es que vas a cometer errores. Tranqui, es normal, y mejor que los cometas ahora en tu repo de pruebas y no en el productivo de esa empresa gigante. Asi que ahora me doy cuenta que son solo buenas noticias!

Paso 1: Creá Tu Propia Rama

Antes que nada, asegurate de estar en la rama principal (generalmente main o master):

git checkout main
git pull origin main

Esto es fundamental. No podés levantar una casa sobre arena movediza, y no podés hacer un buen PR sobre código desactualizado. Creeme, te ahorras un par de dolores de cabeza.

Ahora creá tu propia rama. Acá viene el primer momento de “qué nombre le pongo que no suene ridículo”:

git checkout -b feature/mi-nuevo-boton
# o
git checkout -b fix/arreglo-bug-horrible
# o
git checkout -b mejora/optimizo-consulta-lenta

Usá nombres descriptivos. “feature/boton-para-exportar-pdf” es mejor que “mi-rama” o “test123”. Tu yo del futuro te lo va a agradecer cuando tengas que revisar qué carambas estabas haciendo. Idealmente vas a usar algo bien relacionado con la tarea que tengas asignada.

Paso 2: Hacé Tus Cambios (La Parte Divertida)

Acá es donde pasa la magia, la magia del codigo! Editá los archivos, escribí el código, rompé cosas, arreglalas. Es tu rama, podés hacer lo que quieras.

Pero ojo: mantené los cambios focalizados. Un PR que arregla el login, agrega validaciones al formulario de registro, y de paso cambia el color del header es un PR que se va del alcance de la tarea original. Es importante que las tareas y los PRs sean lo mas granulares posibles. Tambien pensa en la persona que lo va a leer, no puede estar navegando por 50 archivos modificados.

Paso 3: Commiteá Como la Gente

Cuando tengas los cambios listos, no hagas esto:

git add .
git commit -m "cambios"

Hacé esto:

git add archivo-que-cambiaste.js
git add otro-archivo.css
git commit -m "Agrego validacion de email en formulario de registro"

Por que? Porque los mensajes de commit son como las notas que dejás para tu futuro yo. “cambios” no te dice nada. “Agrego validación de email” te dice exactamente qué hiciste y por qué. Incluso para las personas que vengan detrás, les da una idea de lo que sucedió.

Paso 4: Subí Tu Rama al Repositorio

git push origin feature/mi-nuevo-boton

Si es la primera vez que subís esta rama, Git te va a tirar un mensaje largo explicándote cosas. Leelo una vez, pero básicamente te está diciendo que la rama se creó exitosamente en el servidor.

Paso 5: Creá el Pull Request

Acá es donde GitHub se vuelve tu amigo. Andá al repositorio en tu navegador y vas a ver algo así:

“feature/mi-nuevo-boton had recent pushes less than a minute ago” con un botón verde que dice “Compare & pull request”.

GitHub es inteligente. Sabe que acabás de subir una rama nueva y te sugiere crear el PR automáticamente. Dale click a ese botón.

Paso 6: Ponele onda al PR!

Acá es donde la mayoría se tira a menos. El título no puede ser “Fix”. Tampoco puede ser “Cambios varios para mejorar cosas”.

Un buen título cuenta una historia, generalmente vinculado a la tarea que tenias trabajada:

• ✅ “Agrego validación de email con expresión regular”
• ✅ “Corrijo bug de double-click en botón de pago”
• ✅ “Optimizo consulta de usuarios que tardaba 3 segundos”
• ❌ “Fix”
• ❌ “Update code”
• ❌ “Cambios”

La descripción es tu momento de brillar, pero tampoco te pongas muy lírico, es una descripción tecnica, no un capitulo de Tolkien. Aca te dejo una idea, no tiene que ser identico, pero asi ayuda mucho:

## Que cambie?
Agregue validación de email en el formulario de registro usando una regexp.

## Por que?
Se podian registrar direcciones de correo invalidas.

## Como probarlo:
1. Ir a /registro
2. Intentar registrarse con "email-invalido"
3. Deberia mostrar mensaje de error
4. Intentar con "usuario@ejemplo.com"
5. Deberia funcionar normal

## Capturas / evidencia de pruebas
[Acá irían las capturas si las tenés]

Por qué es importante esto? Porque el que revisa tu código no está en tu cabeza. No sabe por qué hiciste lo que hiciste. Una buena descripción es la diferencia entre un PR que se aprueba en una hora y uno que queda dando vueltas una semana con comentarios de “no entiendo qué hace esto”.

Paso 7 (opcional): busca alguien que lo pueda ver y aprobar

GitHub te permite asignar reviewers. Si estás en un equipo, probablemente tengas una idea de quién sabe de lo que estás tocando. Generalmente colegas con un toque mas de experiencia. Algunos equipos tienen reviewers asignados, otros van agarrando a medida que se lo encuentran.

No le asignes el PR a todo el equipo. Elegí una o dos personas máximo. O si tenes un canal alternativo, como un slack, o un teams, pedi alguien ahi que te lo revise.

Paso 8: Esperá (Y Aprendé a Manejar el Rechazo)

Acá viene la parte psicológica que nadie te cuenta. Tu código va a ser juzgado. Van a encontrar cosas para cambiar. Te van a pedir modificaciones. Si es gente buena onda, te van a comprender como junior que sos y es un buen momento para ser mentoreado.

No te lo tomes personal, nunca. El review de código no es un juicio sobre tu valor como persona. Es un control de calidad, como cuando un editor revisa un artículo antes de publicarlo.

Paso 9: Respondé a Los Comentarios (Sin Ponerte a La Defensiva)

Cuando lleguen los comentarios del review, leelos con mente abierta. Algunos van a ser sugerencias, otros van a ser observaciones sobre bugs que no viste.

Si no entendés algo, preguntá. Es preferible quedar como el que pregunta que como el que rompió producción porque no quiso admitir que no entendía (igual, no deberia llegar a produccion, por eso te pidieron los cambios).

Para hacer cambios, simplemente edita los archivos en tu rama local, hace el commit, y el push otra vez:

git add archivo-modificado.js
git commit -m "Corrijo validacion segun comentario del review"
git push origin feature/mi-nuevo-boton

Los cambios aparecen automáticamente en el PR.

Paso 10: La Aprobación (Seee!! Vamo’!)

Cuando tu PR sea aprobado, vas a sentir una mezcla de alivio y satisfacción que es adictiva. O quizas, no. Cada cual es distinto. Lo importante es que podes estar orgulloso, lograste hacer algo y trabajaste colaborativamente en equipo!

El reviewer va a hacer click en “Approve” y después alguien (puede ser la misma persona) va a hacer el merge. Tu código se junta con la rama principal y pasa a formar parte del proyecto.

Paso 11: Podes, y mejor hacerlo, borrar la rama

Una vez que el PR está mergeado, podés borrar la rama en la que trabajaste, incluso es super recomendado, para evitar después tener que andar investigando que ramas tienen algo que sirve y cuales no:

git checkout main
git pull origin main  # Para bajarte tu codigo ya integrado
git branch -d feature/mi-nuevo-boton  # Borra la rama local
git push origin --delete feature/mi-nuevo-boton  # Borra la rama remota

GitHub también te ofrece un botón para borrar la rama automáticamente después del merge. Usalo.

Los Errores Clásicos (Y Cómo Evitarlos)

Error #1: El PR Mamut No hagas PRs de 50 archivos tocados. Nadie los va a revisar bien. Es mejor hacer tres PRs chicos que uno gigante. Si la tarea necesita tantas modificaciones, quizas es sintoma de que hay que hacer tareas mas pequeñas.

Error #2: Commits de Desarrollo No commitees cada vez que guardás el archivo. Hacé cambios coherentes, probá que funcionen, y después commiteá. Pero tampoco hagas la inversa, no cambies 20 archivos y los subas al final de la semana. Equilibrio.

Error #3: No Probar Antes de Subir Tu código puede funcionar en tu máquina y romperse en otro lado. Probá siempre antes de crear el PR. Si hay pruebas, y más te vale que haya, ejecutalas. Si fallan, señal que lo que hiciste aun no esta listo.

Error #4: Tomárselo Personal El código no sos vos. Las sugerencias del review no son ataques personales. Son oportunidades de aprender.

Error #5: Mergear Sin Review Aunque tengas permisos para mergear tus propios PRs, no lo hagas sin que nadie lo revise! No sabes si te equivocaste en algo y podes romper algun entorno.

Pull Requests Como Conversación

Un PR no es solo código. Es una conversación entre vos y el equipo sobre cómo mejorar el proyecto. Es documentación de por qué se tomaron ciertas decisiones. Es una oportunidad de aprender de otros desarrolladores más experimentados.

Al principio puede dar miedo exponer tu código para que lo revisen. Pero con el tiempo te vas a dar cuenta de que los mejores equipos son los que revisan código sin miedo, donde todos aprenden de todos.

Tu primer PR va a ser imperfecto. El segundo también. Pero cada uno va a ser mejor que el anterior.

Hasta el developer más senior del equipo tuvo que hacer su primer Pull Request alguna vez. Al menos tenes esta guia bajo la manga, que te va a alivianar el proceso!

Por muchas más!