Trabajar con pull requests y ramas en Git es como un partido de ping pong: tú envías tu rama, alguien la revisa, se fusiona a main y el ciclo vuelve a empezar. Aquí verás cómo aprobar un pull request, crear una rama nueva, sincronizar cambios y resolver un conflicto real en Visual Studio Code, todo siguiendo una rutina diaria que te evita dolores de cabeza.
¿Cómo revisar y aprobar un pull request en GitHub?
Antes de escribir una sola línea de código, lo primero es revisar si hay pull requests pendientes del equipo. Es parte de la rutina sana de cualquier persona que colabora en un repositorio compartido.
En el ejemplo, hay un pull request creado por Miguel que agrega métodos para los mejores superhéroes de Marvel. Al entrar a la sección de cambios, lo verde indica lo que añadió y lo rojo lo que removió o modificó. Tras confirmar que el archivo está completo y que la plantilla del pull request fue diligenciada correctamente, se aprueba y se hace merge a main [1:30].
¿Qué hago después de aprobar un pull request? Eliminas la rama asociada. Si ya fue fusionada a main, esa rama dejó de tener propósito y mantenerla solo genera ruido en el repositorio.
¿Por qué borrar la rama después del merge?
Mantener ramas muertas confunde al equipo y ensucia la vista del repositorio. Una vez que el código vive en main, esa rama cumplió su función. Borrarla es responsabilidad compartida entre quien aprueba y quien creó el pull request.
¿Cómo crear una rama nueva y hacer commit con Git?
Con main limpio y actualizado, llega tu turno. En este caso, toca agregar un método llamado Courses Platzi que muestre cursos como Docker, Bash y Linux dentro del archivo app.py.
El flujo desde la terminal es directo y siempre el mismo:
git branch para confirmar en qué rama estás parado.git status para ver qué archivos fueron modificados.git add para agregar los cambios al staging.git commit -m "Platzi method added" para registrar el cambio con un mensaje claro.git push -u origin amin/tarea16 para subir la rama nueva al remoto [4:45].
El flag -u en el push establece la rama remota como upstream, lo que te permite usar git push y git pull sin argumentos en los próximos comandos.
¿Qué pasa si main tiene cambios nuevos antes de tu push?
Aquí está el detalle que muchas personas pasan por alto. Si main recibió cambios mientras tú trabajabas en tu rama, lo ideal es traer esos cambios antes de subir los tuyos. De lo contrario, el conflicto se resolverá directamente en GitHub y eso suele ser más incómodo.
La secuencia recomendada es: cambiar a main con git switch main, traer las actualizaciones con git pull, volver a tu rama con git switch amin/tarea16 y finalmente fusionar con git merge main.
¿Cómo resolver un conflicto de merge en Visual Studio Code?
Al correr git merge main, Git te avisa si hay conflictos. En este caso, ambos métodos —el de superhéroes de Marvel y el de cursos de Platzi— ocupan el mismo espacio en app.py y Git no sabe cuál conservar.
Visual Studio Code ofrece la opción Resolve in Editor, que te muestra los dos bloques en conflicto lado a lado. Puedes elegir quedarte con uno, con otro o aceptar ambos cambios. En este escenario, lo correcto es aceptar el merge completo: ni quieres borrar el trabajo de Miguel ni perder el tuyo [7:20].
¿Qué es un conflicto de merge? Es cuando dos ramas modifican la misma línea de un archivo y Git no puede decidir cuál versión conservar. Tú resuelves manualmente cuál bloque queda.
Una vez resuelto, haces commit de la fusión. Desde VS Code puedes usar el botón Sync Changes, que ejecuta un pull y push en un solo paso.
¿Cómo cierras el ciclo del pull request?
Con los cambios ya en GitHub, creas un nuevo pull request desde tu rama hacia main. Es importante revisar que el destino del merge sea el correcto: en este caso, main recibiendo los cambios de amin/tarea16.
Cuando Miguel aprueba y hace merge, el estado del pull request cambia a merged y él borra tu rama, devolviendo el favor. El archivo app.py en main ahora contiene tanto los superhéroes de Marvel como los cursos de Platzi.
¿Cuál es la rutina ideal para evitar conflictos en Git?
La práctica vuelve este flujo casi automático. Al principio se siente burocrático, pero con el tiempo te das cuenta de que sigues una secuencia limpia que protege el trabajo de todo el equipo.
La rutina diaria recomendada tiene tres pasos:
- Revisa los pull requests pendientes del equipo y apruébalos si están listos.
- Trae todos los cambios a tu rama main local con
git pull.
- Crea una rama separada para tu nueva tarea y trabaja ahí.
Siguiendo esta secuencia, es casi imposible toparte con un conflicto como el que se generó intencionalmente en el ejercicio. Y si llegara a ocurrir, ya tienes las herramientas para resolverlo sin pánico.
¿Qué parte del flujo te genera más dudas, el merge desde la terminal o la resolución de conflictos en VS Code? Cuéntalo en los comentarios.
