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 <rama> 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.
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á.
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.
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.
Gracias por tu aporte.
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"
Gracias por tu aporte.
No tengo amigos para hacer pull-request 😪
En cada clase destaco las animaciones utilizadas, excelente!! ayuda muchísimo en el aprendizaje.
💡 Apunte sobre cómo recuperar y corregir un Pull Request tras ungit reset --hardaccidental
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 ungit reset --hardaccidental
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 ungit reset --hardaccidental
✅ Ver el historial de cambios congit 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
✅ 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. 😎
Gracias por tu aporte.
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 verificarBRANCH="master"# Obtener el último commit localLOCAL=$(git rev-parse @)# Obtener el último commit remotoREMOTE=$(git ls-remote origin -h refs/heads/$BRANCH | cut -f1)# Compararif["$LOCAL"!="$REMOTE"]; then
echo "Hay cambios en el remoto. Haciendo git pull..." git pull
else echo "Todo está actualizado."fi
Ronaldo Jimenez
pull:
#!/bin/bash
BRANCH="master"
BRANCH="main"
Ya que en las nuevas versiones de git no se utiliza master sino main.
🔹 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 entremergeyrebaseen 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.
Es una buena practica de trabajar con ramas y realizar pull requests, cuando uno esta trabajando solo??
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.
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.
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
alguien me explica porqué me aparece asi?
segui los mismos pasos:
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!
Clase 18
Alguien para practicar pull requests?
Las tarjetas de la evaluación no se ven bien :(
Dime el paso a paso para hacer un PR
Hola, Diego Mauricio. Para realizar un Pull Request (PR) de forma profesional, sigue estos pasos:
Crea una rama: Nunca trabajes directamente en main. Crea una rama nueva para tu tarea específica.
Trabaja y confirma: Realiza tus cambios, haz git add y git commit en tu rama local.
Sube tu rama: Envía tus cambios a GitHub con git push -u origin nombre-de-tu-rama.
Abre el PR: En GitHub, verás un aviso para crear el Pull Request. Haz clic en el botón, añade un título claro y una descripción detallada de tus cambios.
Code Review: Espera a que tu equipo revise y apruebe el código.
Fusiona y limpia: Una vez aprobado, fusiona el PR a main y elimina la rama que ya cumplió su objetivo.
El Code Review (o revisión de código) entra en acción justo después de abrir el Pull Request y antes de que el código se fusione con main. Es el filtro de calidad más importante de tu equipo. Imagínalo como un proceso de edición de un periódico: el periodista escribe el artículo (tú escribes el código), pero el editor lo revisa para atrapar errores ortográficos o mejorar la redacción antes de publicarlo. Aunque al principio puede generar un poco de vulnerabilidad mostrar tu trabajo, es una herramienta invaluable de aprendizaje mutuo. Tus compañeros pueden detectar posibles bugs que pasaste por alto, sugerir métodos más eficientes o simplemente validar que tu lógica es sólida. Una vez que obtienes la aprobación (la famosa "palomita verde"), tienes la confianza total de que tu código está listo para producción.
Algo muy importante que no menciono en esta clase es el concepto de la rama base, es muy frecuente que olvidemos configurar de forma correcta la rama base para el PR o en otras palabras, la rama a la que le queremos introducir los nuevos cambios o nuestros cambios que dentro de un flujo corporativo suele ser la rama development
Este resumen sobre ramas y Pull Requests es muy práctico. Me parece clave la recomendación de no trabajar directamente en main y usar PRs, porque asegura colaboración segura y facilita el code review, lo que mejora la calidad del código y la organización del equipo.
💻 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.
