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

Colaboración sin errores: Pull Requests en GitHub

18/42
Recursos

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?

  1. Crear una Rama Nueva: Al iniciar cambios, crea una rama local específica. Por ejemplo, developer01.
  2. Subir la Rama a GitHub: Usa git push -u origin para subir tu rama.
  3. 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?

  1. 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.
  2. Resolver Conflictos: GitHub verifica automáticamente conflictos potenciales, mostrando una marca verde si está listo para fusionarse sin problemas.
  3. 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.

Aportes 16

Preguntas 1

Ordenar por:

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

puedes combinar git add y git commit con git commit -am "mensaje commit" !!!
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.
No tengo amigos para hacer pull-request 😪
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"`
alguien me explica porqué me aparece asi? ![](https://static.platzi.com/media/user_upload/image-86da75fb-418e-4e9b-be84-8386265dfd90.jpg) segui los mismos pasos: ![](https://static.platzi.com/media/user_upload/image-4b2cf8e0-f883-49e0-a20b-c9d67cdf3bd1.jpg)
💡 **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`: ```txt git reflog ``` Verás una lista como esta: ```txt 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** ```txt git reset --hard <ID_DEL_COMMIT> ``` Ejemplo: ```txt 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: ```txt git push --force ``` **2️⃣ Eliminar archivos o directorios no deseados en el Pull Request** ### ✅ **Eliminar archivos individuales** ```txt git rm archivo_no_deseado.txt git commit -m "Eliminando archivo innecesario" ``` ✅ **Eliminar un directorio completo** ```txt git rm -r directorio_no_deseado/ git commit -m "Eliminando directorio innecesario" ``` ✅ **Si quieres eliminarlo solo de Git pero mantenerlo en local** ```txt git rm -r --cached directorio_no_deseado/ git commit -m "Eliminando directorio solo del control de versiones" ``` Luego, **sube los cambios al Pull Request**: ```txt git push ``` **3️⃣ Opcional: Sobrescribir el commit anterior en el PR** Si solo quieres modificar el último commit sin crear uno nuevo: ```txt git commit --amend -m "Corrección: eliminando archivos no deseados" ``` Y si el PR ya estaba en GitHub, **fuerza la actualización**: ```txt 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. 😎
# **🔹 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** 1. Ve al repositorio en GitHub. 2. Haz clic en **"Pull Requests" > "New Pull Request"**. 3. Selecciona la rama **feature-nueva-funcionalidad** y compárala con **main**. 4. Agrega un **título claro** y una **descripción detallada**. 5. 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** 1. Ve al PR en GitHub. 2. Revisa los cambios en la pestaña **"Files changed"**. 3. Agrega comentarios en líneas específicas si es necesario. 4. 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: 1. En el PR, haz clic en **"Merge pull request"**. 2. Confirma con **"Confirm merge"**. 3. (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** 1. Descarga los cambios más recientes:git fetch origin git checkout feature-nueva-funcionalidad git merge main 2. Edita los archivos en conflicto (verás marcas como `<<<<<<<` en el código). 3. Guarda los cambios y haz un nuevo commit:git add . git commit -m "Resueltos conflictos de fusión" 4. 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.
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
Que hago en este caso? Segui todos los pasos de la clase, elimine la rama developer01 del repositorio remoto. Y luego tambien elimine la rama developer01 localmente, luego hice gi pull para obtener los cambios ![](https://static.platzi.com/media/user_upload/Captura%20de%20Pantalla%202025-01-15%20a%20la%28s%29%2018.12.43-459ef252-15cc-4610-9b29-27db507ec738.jpg)
Que hago en este caso? Segui todos los pasos de la clase, elimine la rama developer01 del repositorio remoto. Y luego tambien elimine la rama developer01 localmente, luego hice gi pull para obtener los cambios ![](https://static.platzi.com/media/user_upload/Captura%20de%20Pantalla%202025-01-15%20a%20la%28s%29%2018.07.31-90b806fd-cb32-4709-80a0-f400ad3419ed.jpg)
En cada clase destaco las animaciones utilizadas, excelente!! ayuda muchísimo en el aprendizaje. ![](https://static.platzi.com/media/user_upload/Captura%20de%20Pantalla%202025-01-15%20a%20la%28s%29%2017.32.12-2804dcb8-2540-49e9-92b2-511bda18b70c.jpg)
Si alguien quiere practicar sus Pull Requests y merges, añadanme como @ferdeb en GitHub && @\_ferdeb en X.com, siempre es bueno practicar con diferentes repos!
Excelente aportación
Si entiendo bien, este proceso es por si cada persona individualmente crea la rama de manera local. Aunque también las ramas podrían crearse de manera online. Lo que si considero importante, es el pull request y chequeo de todos los miembros del equipo para hacer merge final a la rama principal.
![](https://static.platzi.com/media/user_upload/image-4f26a6e3-ffcd-433a-a0ec-76837f8f3652.jpg)
![](https://static.platzi.com/media/user_upload/%7B70DAC69F-B573-4789-94EA-486D480A215A%7D-4675247e-0386-48cf-9696-306d82fd1d4b.jpg)