Uso de Pull Requests en GitHub para Colaboración Efectiva

Resumen

Colaborar en GitHub requiere evitar modificar directamente la rama principal, lo que podría causar conflictos con el trabajo de otros compañeros. En su lugar, trabajar en ramas individuales y fusionarlas mediante Pull Requests (PR) es clave para un flujo de trabajo colaborativo y seguro.

¿Por qué evitar cambios directos en la rama principal?

Realizar cambios directamente en la rama principal (main) puede sobrescribir el trabajo no sincronizado de otros colaboradores. Este error común se evita al:

Crear una rama separada para cada contribuyente.
Fusionar cambios mediante una revisión en el Pull Request, antes de unirlos a la rama principal.

¿Cómo funciona un Pull Request?

Crear una Rama Nueva: Al iniciar cambios, crea una rama local específica. Por ejemplo, developer01.
Subir la Rama a GitHub: Usa git push -u origin para subir tu rama.
Notificar al Equipo: Al crear un Pull Request, notificas al equipo sobre tus cambios, lo que permite una revisión colaborativa (Code Review).

¿Qué papel juega la revisión de código?

El Code Review en los Pull Requests permite:

Evaluar y comentar los cambios antes de fusionarlos.
Aumentar la calidad y la visibilidad de los cambios propuestos.

Aunque puede ser intimidante al principio, esta práctica asegura transparencia y mejora continua en el equipo.

¿Cómo se fusiona un Pull Request?

Comparación y Revisión: Una vez que el equipo revisa los cambios y los aprueba, GitHub facilita la fusión con la rama principal.
Resolver Conflictos: GitHub verifica automáticamente conflictos potenciales, mostrando una marca verde si está listo para fusionarse sin problemas.
Eliminar la Rama: Tras la fusión, se elimina la rama para mantener el repositorio ordenado y listo para nuevas tareas.

¿Cómo puedo practicar Pull Requests de forma efectiva?

Para mejorar, colabora con un amigo o colega, practicando la creación y revisión de Pull Requests. Esta interacción entre ramas te ayudará a familiarizarte y a fluir con confianza en el proceso de colaboración en GitHub.

Jose Luis Bedoya

student•

puedes combinar git add y git commit

con git commit -am "mensaje commit"

!!!

Ronaldo Jiménez

student•

Solo incluye archivos que ya estaban siendo rastreados (es decir, ya fueron añadidos alguna vez con git add).
No incluye archivos nuevos. Si acabas de crear un archivo, primero debes hacer git add <archivo> o no se incluirá.

Fernando Emilio Díaz López

student•

Cuando borras una rama en GitHub, solo se elimina del repositorio remoto. La rama local sigue existiendo hasta que la eliminas manualmente en tu entorno local. Para borrar la rama local, debes usar el comando git branch -d nombre-de-la-rama. Esto asegura que tu trabajo local no se vea afectado si aún no has fusionado cambios. Mantener ramas locales puede ser útil para revisarlas más tarde.

Mauricio J Carrillo

student•

Adicionalmente, para eliminar la referencia de la rama remota que aún se encuentra en el repositorio local, se puede utilizar el comando git fetch -p.

Alexis Dorado Muñoz

student•

Gracias por tu aporte.

Daniel Dobles

student•

Para combinar ambos comandos (git add . y git commit -m) en una sola línea usando && para encadenarlos. Aquí tienes cómo hacerlo: git add . && git commit -m "Tu mensaje de commit"

Alexis Dorado Muñoz

student•

Gracias por tu aporte.

Gabriel Pinzon

student•

No tengo amigos para hacer pull-request 😪

Ana Rotela Cabrera

student•

En cada clase destaco las animaciones utilizadas, excelente!! ayuda muchísimo en el aprendizaje.

Kevin Isaí Santiago López

student•

💡 Apunte sobre cómo recuperar y corregir un Pull Request tras un git reset --hard accidental

Durante esta clase, subí un Pull Request con archivos que no debía incluir. Mi error fue olvidar usar git rm para eliminarlos correctamente y, en su lugar, intenté arreglarlo con git reset --hard, lo que me hizo perder cambios.

Comparto este apunte con los pasos detallados por si alguien más se encuentra en la misma situación. 🚀

👇 Aquí está el apunte completo:

(Apoyo de AI para resolver el problema)

🔹 Recuperar y corregir un Pull Request tras un git reset --hard accidental

Escenario:

Subiste un Pull Request (PR) con archivos que no debías incluir.
Intentaste arreglarlo, pero hiciste un git reset --hard en local y perdiste tu commit.
Ahora necesitas recuperar los cambios y borrar los archivos no deseados en el PR.

1️⃣ Restablecer un git reset --hard accidental

✅ Ver el historial de cambios con git reflog

Git mantiene un historial interno de cada movimiento. Para ver los commits antes del reset:

git reflog

Verás una lista como esta:

6e219fd HEAD@{1}: commit: Cambios antes del reset
38367ff HEAD@{0}: reset: moving to origin/main

El commit que tenías antes del reset es el correcto (en este caso 6e219fd).

✅ Recuperar el commit perdido

git reset --hard <ID_DEL_COMMIT>

Ejemplo:

git reset --hard 6e219fd

Con esto, habrás restaurado tu código antes del reset.

✅ Sincronizar con GitHub

Si ya habías subido la versión equivocada, necesitas sobrescribir la rama en GitHub:

git push --force

2️⃣ Eliminar archivos o directorios no deseados en el Pull Request

✅ Eliminar archivos individuales

git rm archivo_no_deseado.txt
git commit -m "Eliminando archivo innecesario"

✅ Eliminar un directorio completo

git rm -r directorio_no_deseado/
git commit -m "Eliminando directorio innecesario"

✅ Si quieres eliminarlo solo de Git pero mantenerlo en local

git rm -r --cached directorio_no_deseado/
git commit -m "Eliminando directorio solo del control de versiones"

Luego, sube los cambios al Pull Request:

git push

3️⃣ Opcional: Sobrescribir el commit anterior en el PR

Si solo quieres modificar el último commit sin crear uno nuevo:

git commit --amend -m "Corrección: eliminando archivos no deseados"

Y si el PR ya estaba en GitHub, fuerza la actualización:

git push --force

4️⃣ Confirmar que todo está corregido en el PR

Ve a GitHub y revisa que los archivos no deseados han desaparecido del PR.
Espera la revisión del equipo y listo. 🚀

Este apunte te servirá como referencia rápida para no perder la calma si vuelve a pasar. 😎

Alexis Dorado Muñoz

student•

Gracias por tu aporte.

Ronaldo Jiménez

student•

Comparto script que verifica si un repo en github (remoto) ha cambiado y así actualizar el repo local, es decir, aplicar pull:

#!/bin/bash

# Rama a verificar
BRANCH="master"

# Obtener el último commit local
LOCAL=$(git rev-parse @)

# Obtener el último commit remoto
REMOTE=$(git ls-remote origin -h refs/heads/$BRANCH | cut -f1)

# Comparar
if [ "$LOCAL" != "$REMOTE" ]; then
    echo "Hay cambios en el remoto. Haciendo git pull..."
    git pull
else
    echo "Todo está actualizado."
fi

Albert Jose Salas Yustiz

student•

Ronaldo Jimenez

pull:

#!/bin/bash

BRANCH="master"

BRANCH="main"

Ya que en las nuevas versiones de git no se utiliza master sino main.

Alexander Silvera

student•

Es una buena practica de trabajar con ramas y realizar pull requests, cuando uno esta trabajando solo??

Platzi

student•

Si está funcionando mi API, todo está en mi entorno particular y local y significa que ya la completé. Es momento de pasar todo esto a GitHub. Lo primero que voy a hacer es pasarme a mi terminal, presionar control C y mi aplicación se suspende. Limpio la terminal y estoy dentro de el folder de API. Me subo un nivel para estar en mi cuarto repo y poder escribir primero Git branch para confirmar que estoy en Amin-tarea15. Después me brinco a Git status para ver cuáles son los cambios realizados y aquí está la nueva carpeta de API. El siguiente paso es Git commit-m que diga nuevo proyecto de API creado. De nuevo no puedo atinarle al comando del commit. Ahí está. Y enter.

Samuel Soto Hoyos

student•

Si porque te va a servir en Releases para generar automáticamente las notas.

Cómo recomendación adicional te recomiendo además del título de commit, agrega descripciones a tus commits y que estas sean muy descriptivas.

Mario Alexander Vargas Celis

student•

🔹 Colaboración sin Errores: Pull Requests en GitHub 🚀

Cuando trabajas en equipo en GitHub, necesitas una forma organizada de proponer cambios en el código sin afectar directamente la versión principal. Aquí es donde entran en juego los Pull Requests (PRs).

Un Pull Request (PR) permite: ✅ Sugerir cambios en un repositorio antes de fusionarlos (merge). ✅ Revisar código en equipo para evitar errores. ✅ Mantener un historial claro de contribuciones.

1️⃣ ¿Cómo Crear un Pull Request en GitHub?

Sigue estos pasos para proponer cambios a un repositorio:

📌 1. Crear una Rama Nueva

Antes de hacer cambios, crea una rama separada:

git checkout -b feature-nueva-funcionalidad

✅ Usar nombres descriptivos para las ramas ayuda a la organización.

📌 2. Hacer Cambios y Confirmarlos (commit)

Modifica los archivos y guarda los cambios:

git add . git commit -m "Añadida nueva funcionalidad X"

📌 3. Subir los Cambios a GitHub (push)

git push origin feature-nueva-funcionalidad

📌 4. Crear el Pull Request en GitHub

Ve al repositorio en GitHub.
Haz clic en "Pull Requests" > "New Pull Request".
Selecciona la rama feature-nueva-funcionalidad y compárala con main.
Agrega un título claro y una descripción detallada.
Presiona "Create Pull Request".

2️⃣ ¿Cómo Revisar y Aprobar un Pull Request?

Después de crear un PR, otros desarrolladores pueden revisarlo antes de aprobarlo.

📌 Revisión de Código en un PR

Ve al PR en GitHub.
Revisa los cambios en la pestaña "Files changed".
Agrega comentarios en líneas específicas si es necesario.
Aprueba el PR con "Approve" o solicita cambios con "Request changes".

📌 Fusionar (merge) un Pull Request

Si el código está listo, puedes fusionarlo con la rama principal:

En el PR, haz clic en "Merge pull request".
Confirma con "Confirm merge".
(Opcional) Borra la rama después de fusionar.

3️⃣ Diferencias entre merge y rebase en PRs

Merge → Mantiene el historial de commits.
Rebase → Integra los cambios en una línea más limpia, sin historial de fusión.

Si prefieres un historial más ordenado, puedes hacer:

git rebase main

4️⃣ Resolver Conflictos en un Pull Request

Si GitHub detecta que hay cambios en la rama main que chocan con los de tu PR, verás un mensaje de "This branch has conflicts that must be resolved".

📌 Cómo Resolver Conflictos en Git

Descarga los cambios más recientes:git fetch origin git checkout feature-nueva-funcionalidad git merge main
Edita los archivos en conflicto (verás marcas como <<<<<<< en el código).
Guarda los cambios y haz un nuevo commit:git add . git commit -m "Resueltos conflictos de fusión"
Sube los cambios:git push origin feature-nueva-funcionalidad

Ahora el PR estará listo para ser fusionado.

🎯 Conclusión

🔹 Pull Requests permiten colaborar sin afectar directamente la rama principal. 🔹 Revisión de código mejora la calidad y seguridad del proyecto. 🔹 Resolver conflictos es clave para mantener el código limpio.

Ana Rotela Cabrera

student•

Despues de ver todo este video, recomiendo los siguiente pasos

El siguiente paso es ir a la terminal y con git fetch --prune Git actualiza las ramas remotas y elimina las referencias a ramas que ya no existen en el remoto:

Luego debemos movernos a la rama principal main con git checkout main

Una vez ya en main eliminamos la rama developer01 con git branch -d developer01 aqui Git indica que no esta completamente fusionada entonces debemos usar el comando git branch -D developer01

Actualizamos la rama main con git pull origin main para sincronizar nuestra rama local con la versión remota, trayendo los últimos cambios, incluido el merge de developer01.

Con git log --oneline confirmamos todos los cambios

Alex Gustavo

student•

alguien me explica porqué me aparece asi?

segui los mismos pasos:

Alex Gustavo

student•

Fernando Emilio Díaz López

student•

Hola compañero!! Creo que hiciste add y commit desde VS Code, entonces, con eso en mente, al hacer status no hay nada que añadir, y lo mismo, al hacer add y commit manual, ya lo habias realizado desde VS Code, procura llevar un orden en tus acciones, si vas a trabajar desde la GUI de VS Code o desde tu terminal de Ubuntu para que no te confundas, aunque con la practica puedes usar ambas sin perderte, saludos!

Gabriel Obregón

student•

💻 Colaborar en GitHub con Ramas y Pull Requests

🌳 CONCEPTO CLAVE

🔒 No trabajes directamente en la rama principal (main).

💡 En su lugar:

Crea ramas individuales.
Fusiona los cambios mediante Pull Requests (PR). 🔁 Así mantienes un flujo colaborativo, seguro y organizado.

🚫 POR QUÉ EVITAR CAMBIOS EN MAIN

⚠️ Riesgos:

Puedes sobrescribir trabajo ajeno.
Se generan conflictos difíciles de resolver.

✅ Buenas prácticas:

🌱 Una rama por tarea o persona.
🔍 Fusiona solo tras una revisión en PR.

🔀 ¿QUÉ ES UN PULL REQUEST?

Es una solicitud para revisar y fusionar cambios desde tu rama hacia la rama principal.

🧩 Pasos básicos:

🪴 Crear una nueva rama
- Ejemplo: developer01.
- Trabaja de forma aislada.
☁️ Subir la rama a GitHub
- Usa: git push -u origin nombre_de_tu_rama
📢 Crear el Pull Request
- Notifica al equipo.
- Permite revisión y comentarios antes de la fusión.

👀 REVISIÓN DE CÓDIGO (CODE REVIEW)

🎯 Objetivos del Code Review:

🧠 Evaluar y mejorar la calidad del código.
👥 Aumentar la visibilidad del trabajo.
🔄 Garantizar coherencia y aprendizaje en el equipo.

💬 Los revisores pueden:

Sugerir mejoras.
Detectar errores.
Validar estándares del proyecto.

✨ Resultado: un código más limpio, comprensible y colaborativo.

⚙️ CÓMO SE FUSIONA UN PULL REQUEST

🔎 Comparar y revisar:
- El equipo aprueba los cambios.
⚔️ Resolver conflictos:
- GitHub los detecta automáticamente.
- ✅ Si ves una marca verde → todo listo para fusionar.
🧹 Eliminar la rama:
- Después de fusionar, elimina la rama.
- Mantén el repositorio ordenado y listo para nuevas tareas.

José Antonio De La Paz Fonseca

student•

Me parece que quedó un poco superficial la info

Hugo Andrés Cabrera Lagos

student•

RECORDATORIO: Los pull request solo se puede trabajar desde GITHUB en este caso, ya que desde la terminal no se pueden trabajar directamente.

Samuel Soto Hoyos

student•

Puedes usar GitHub CLI para ello. El resultado va a ser similar a hacerlo desde la interfaz web de GitHub.com

Marcelino Chan Jun

student•

Al trabajar con equipos grandes y con mucha actividad en el proyecto, ¿Conocen algunas buenas practicas al momento de crear los nombres de ramas?

Samuel Soto Hoyos

student••

Es importante que cada dev haga push de una sola rama. Ejemplo con el comando git push origin feat/api-auth en lugar de solo git push (Para solo mandar a remoto una rama, no varias).

Para los nombres de las ramas te aconsejo seguir \<type> / \<scope> porque es fácil de entender de que va la rama.

Daniel Andres Rojas Paredes

student•

poruqe se llama pull request si el comando que uno usa para enviar los cambios realisados a revision el push.

pull request suena a pedir permiso para jalar cambios no para enviarlos

Emerson Cedeño

student•

de hecho en [un video de Freddie sobre Git y GitHub](https://youtu.be/EscDe0jG6XM?si=mnduHrnB4ZG7VJwB\&t=684) explica un poco el tema, en resumen, se menciona que el origen del nombre, Pull Request, hace referencia a "una <u>solicitud</u> para que los cambios que uno está introduciendo sean <u>incorporados</u> al proyecto" (you're requesting to the project's owner to pull your changes), GitLab nombra a esta operación de una forma más intuitiva, Merge Request. Interesante! 🤓

SANTIAGO ALBERTO BOLIVAR CARDENAS.

student•

Que buen video, Gracias Profesor, Gracias Platzi.

Kevin Arnaldo Valladares Sanchez

student•

Alguien que tenga disponibilidad para practicar los pull request?

Amin Espinoza

teacher•

Lo siento! Andaba de vacaciones pero yo!!! Qué tal que agregas acá tu nombre? Yo te apruebo el PR si lo haces bien: https://github.com/platzi/git-github/blob/main/Contribuciones.md

David López Sandoval

student•

Aqui estoy !

Diego Perez

student•

Alguien para praticar estos pull request?

Amin Espinoza

teacher•

Lo siento! Andaba de vacaciones pero yo!!!! Qué tal que agregas acá tu nombre? Yo te apruebo el PR si lo haces bien: https://github.com/platzi/git-github/blob/main/Contribuciones.md

Adriana Carranza

student•

Colaborar en GitHub: 🔹 No modifiques main directamente → Usa ramas individuales y Pull Requests (PRs).

¿Por qué? Evita sobrescribir el trabajo de otros.

Flujo básico:

Crea una rama: git checkout -b mi-rama
Súbela: git push -u origin mi-rama
Abre un PR para revisión.

Code Review: ✔️ Mejora la calidad del código. ✔️ Fomenta el trabajo en equipo.

Fusión: ✅ GitHub marca en verde si no hay conflictos. 🗑️ Borra la rama después del merge.