Fundamentos de Git y control de versiones

1

¿Qué son Git y GitHub?

2

Configuración Inicial de Git: init y config

3

Comandos Básicos de Git: add, commit y log

4

Ramas y Fusión de Cambios: branch, merge, switch y checkout

5

Volviendo en el Tiempo en Git: reset y revert

6

Gestión de versiones: tag y checkout

7

Cómo Resolver Conflictos de Ramas en Git

8

Usando Git desde Visual Studio Code

Quiz: Fundamentos de Git y control de versiones

Introducción a GitHub

9

Por qué GitHub es clave para los Desarrolladores

10

Creación y configuración de cuenta de GitHub

11

¿Cómo integrar Git y GitHub en un flujo de trabajo profesional?

12

Gestión de Repositorios en GitHub

13

Productos de GitHub: precios, planes y apps

14

Cómo configurar SSH para GitHub: Guía paso a paso

15

Clone, fork y estrellas a repositorios

16

Trabajo con repositorios remotos: push, pull y fetch

17

Gestión de Issues y Discussions en GitHub

18

Colaboración sin errores: Pull Requests en GitHub

Quiz: Introducción a GitHub

Herramientas de colaboración en GitHub

19

Introducción a GitHub Projects

20

Automatización y Gestión de Proyectos en GitHub

21

Documentación en GitHub con Markdown

22

Personaliza tu Perfil de GitHub con Markdown

23

Uso de Wikis

24

Cómo usar GitHub Gist

25

Cómo usar GitHub Pages

Quiz: Herramientas de colaboración en GitHub

GitHub Codespaces

26

Cómo usar GitHub Codespaces: Configuración y Desarrollo en la Nube

27

Cómo configurar entornos de desarrollo avanzados en GitHub Codespaces

28

Pair Programming con Codespaces y Visual Studio Code

29

Cómo usar GitHub.dev Editor

Quiz: GitHub Codespaces

Seguridad y buenas prácticas en GitHub

30

Cómo Usar Tokens en GitHub para Acceso Seguro a Repositorios Privados

31

Gestión de Dependencias y Seguridad con Dependabot en GitHub

32

Mantenimiento de repositorios seguros

33

Gestión de datos sensibles y políticas de seguridad

Quiz: Seguridad y buenas prácticas en GitHub

Administración de GitHub

34

Administración de organizaciones en GitHub

35

Cómo personalizar tu perfil de GitHub con GitHub Actions

36

GitHub CLI para administración

Quiz: Administración de GitHub

Gestión de Cambios con Pull Requests

37

Importancia de los Pull Requests y Ramas en GitHub

38

Revisión y Fusión de Pull Requests

39

Git Rebase

Quiz: Gestión de Cambios con Pull Requests

GitHub Releases

40

Introducción a los GitHub Releases

41

Publicación de paquetes en GitHub y PyPI

Quiz: GitHub Releases

Cierre

42

ProTips: Mejora tu productividad diaria en GitHub

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Revisión y Fusión de Pull Requests

38/42
Recursos

Aportes 5

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Para fusionar un pull request, considera lo siguiente: 1. **Revisión de cambios**: Verifica los cambios propuestos, asegúrate de que cumplen con los estándares del proyecto y no introducen errores. 2. **Conflictos**: Asegúrate de que no haya conflictos entre la rama del pull request y la rama principal (main). Si los hay, resuélvelos antes de fusionar. 3. **Pruebas**: Realiza pruebas para confirmar que los cambios no rompen la funcionalidad existente. 4. **Comentarios**: Lee los comentarios y discusiones en el pull request para entender el contexto y la intención del autor. 5. **Aprobaciones**: Asegúrate de que al menos un revisor apruebe el pull request antes de fusionarlo. Siguiendo estos pasos, garantizarás un proceso de fusión eficaz y colaborativo.
Les recomiendo este recuso para aprender un poco más sobre las prácticas de ingeniería de Google (especificamente sobre Code Review) espero les sirva \[Google Engineering Practices Documentation]\(https://github.com/google/eng-practices)
## **Revisión y Fusión de Pull Requests en GitHub** 🚀 Los **Pull Requests (PRs)** son esenciales en el flujo de trabajo colaborativo de GitHub, ya que permiten la revisión, validación y fusión de cambios en un proyecto. Un **buen proceso de revisión y fusión** mejora la calidad del código y previene errores antes de integrarlo en la rama principal (`main` o `develop`). ### **📌 Revisión de Pull Requests** La revisión de un PR implica analizar el código, detectar errores y sugerir mejoras antes de fusionarlo. 🔹 **Pasos para revisar un Pull Request en GitHub:** 1️⃣ **Abrir el PR** en GitHub desde la pestaña "Pull Requests". 2️⃣ **Leer la descripción** del PR para entender los cambios. 3️⃣ **Revisar los archivos modificados** en la pestaña "Files changed". 4️⃣ **Comentar líneas de código** si hay sugerencias o problemas. 5️⃣ **Ejecutar pruebas** (si es posible) para verificar que el código funciona correctamente. 6️⃣ **Aprobar o solicitar cambios**: * ✅ **"Approve"** si el código es correcto. * 🔄 **"Request changes"** si se requieren modificaciones. * 📌 **"Comment"** para discutir sin aprobar ni rechazar. 📌 **Ejemplo de revisión usando GitHub CLI:** \# Ver lista de PRs abiertos gh pr list \# Ver detalles de un PR específico gh pr view \<PR\_ID> \# Dejar un comentario en un PR gh pr comment \<PR\_ID> --body "Este código se ve bien, pero considera mejorar X línea." ### **📌 Fusión de Pull Requests** Una vez aprobado el PR, el siguiente paso es fusionarlo en la rama principal. 🔹 **Opciones de fusión en GitHub:** 1️⃣ **Merge commit** (`Create a merge commit`): Mantiene el historial completo del PR. 2️⃣ **Squash and merge** (`Squash commits`): Une todos los commits en uno solo para un historial más limpio. 3️⃣ **Rebase and merge** (`Rebase commits`): Aplica los commits sobre la rama de destino sin crear un commit de fusión. 📌 **Ejemplo de fusión desde la CLI:** \# Fusionar un PR gh pr merge \<PR\_ID> --merge # Merge commit gh pr merge \<PR\_ID> --squash # Squash and merge gh pr merge \<PR\_ID> --rebase # Rebase and merge ### **📌 Buenas Prácticas para Revisar y Fusionar PRs** ✅ **Hacer revisiones detalladas** para evitar errores en producción. ✅ **Usar linters y pruebas automáticas** para validar el código antes de fusionarlo. ✅ **Comentar de manera clara y constructiva** para mejorar la colaboración. ✅ **Seleccionar la estrategia de fusión adecuada** según el flujo de trabajo del equipo. 💡 **"Una revisión efectiva y una fusión bien gestionada garantizan código limpio, estable y fácil de mantener."** 🚀
Recomendaciones * Primero verificar los pull requests existentes en GitHub, aceptarlos de ser correctos. * Descargar todos los cambios hechos del repositorio remoto en GitHub, haciendo git pull * Ya en mi repositorio local, tengo todos los cambios - igual- que en el repositorio remoto. * Ahora sí puedo empezar a crear una rama ej: minombre/tarea16 (En donde 16 podría estar relacionada con el issue ) y realizar todos los cambios que necesito.
Tu plantilla está larga. Espero Chayanne sí me lo apruebé 😂