Introducción a Git

1

¿Por qué usar un sistema de control de versiones como Git?

2

¿Qué es Git?

3

Instalando Git y GitBash en Windows

4

Instalando Git en OSX

5

Instalando Git en Linux

6

Editores de código, archivos binarios y de texto plano

7

Introducción a la terminal y línea de comandos

Comandos básicos en Git

8

Crea un repositorio de Git y haz tu primer commit

9

Analizar cambios en los archivos de tu proyecto con Git

10

¿Qué es el staging y los repositorios? Ciclo básico de trabajo en Git

11

¿Qué es un Branch (rama) y cómo funciona un Merge en Git?

12

Volver en el tiempo en nuestro repositorio utilizando reset y checkout

13

Git reset vs. Git rm

Flujo de trabajo básico en Git

14

Flujo de trabajo básico con un repositorio remoto

15

Introducción a las ramas o branches de Git

16

Fusión de ramas con Git merge

17

Resolución de conflictos al hacer un merge

Trabajando con repositorios remotos en GitHub

18

Cambios en GitHub: de master a main

19

Uso de GitHub

20

Cómo funcionan las llaves públicas y privadas

21

Configura tus llaves SSH en local

22

Conexión a GitHub con SSH

23

Tags y versiones en Git y GitHub

24

Manejo de ramas en GitHub

25

Configurar múltiples colaboradores en un repositorio de GitHub

Flujos de trabajo profesionales

26

Flujo de trabajo profesional: Haciendo merge de ramas de desarrollo a master

27

Flujo de trabajo profesional con Pull requests

28

Utilizando Pull Requests en GitHub

29

Creando un Fork, contribuyendo a un repositorio

30

Haciendo deployment a un servidor

31

Hazme un pull request

32

Ignorar archivos en el repositorio con .gitignore

33

Readme.md es una excelente práctica

34

Tu sitio web público con GitHub Pages

Multiples entornos de trabajo en Git

35

Git Rebase: reorganizando el trabajo realizado

36

Git Stash: Guardar cambios en memoria y recuperarlos después

37

Git Clean: limpiar tu proyecto de archivos no deseados

38

Git cherry-pick: traer commits viejos al head de un branch

Comandos de Git para casos de emergencia

39

Git Reset y Reflog: úsese en caso de emergencia

40

Reconstruir commits en Git con amend

41

Buscar en archivos y commits de Git con Grep y log

Bonus sobre Git y Github

42

Comandos y recursos colaborativos en Git y GitHub

43

Tu futuro con Git y GitHub

Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

Utilizando Pull Requests en GitHub

28/43
Recursos

Pull request es una funcionalidad de Github (en Gitlab llamada merge request y en Bitbucket push request), en la que un colaborador pide que revisen sus cambios antes de hacer merge a una rama, normalmente master (ahora conocida como main).

Al hacer un pull request, se genera una conversación que pueden seguir los demás usuarios del repositorio, así como autorizar y rechazar los cambios.

Cómo se realiza un pull request

  • Se trabaja en una rama paralela los cambios que se desean git checkout -b <rama>.
  • Se hace un commit a la rama git commit -am '<Comentario>'.
  • Se suben al remoto los cambios git push origin <rama>.
  • En GitHub se hace el pull request comparando la rama master con la rama del fix.
  • Uno, o varios colaboradores revisan que el código sea correcto y dan feedback (en el chat del pull request).
  • El colaborador hace los cambios que desea en la rama y lo vuelve a subir al remoto (automáticamente jala la historia de los cambios que se hagan en la rama, en remoto).
  • Se aceptan los cambios en GitHub.
  • Se hace merge a master desde GitHub.

Importante: Cuando se modifica una rama, también se modifica el pull request.

Aporte creado por: David Behar

Aportes 300

Preguntas 84

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

Pull request:

Es una funcionalidad de github (en gitlab llamada merge request y en bitbucket push request), en la que un colaborador pide que revisen sus cambios antes de hacer merge a una rama, normalmente master.

Al hacer un pull request se genera una conversación que pueden seguir los demás usuarios del repositorio, así como autorizar y rechazar los cambios.

El flujo del pull request es el siguiente

  1. Se trabaja en una rama paralela los cambios que se desean (git checkout -b <rama>)
  2. Se hace un commit a la rama (git commit -am '<Comentario>')
  3. Se suben al remoto los cambios (git push origin <rama>)
  4. En GitHub se hace el pull request comparando la rama master con la rama del fix.
  5. Uno, o varios colaboradores revisan que el código sea correcto y dan feedback (en el chat del pull request)
  6. El colaborador hace los cambios que desea en la rama y lo vuelve a subir al remoto (automáticamente jala la historia de los cambios que se hagan en la rama, en remoto)
  7. Se aceptan los cambios en GitHub
  8. Se hace merge a master desde GitHub

Importante: Cuando se modifica una rama, también se modifica el pull request.

Apuntes de apoyo!

Estoy tomando el curso con una compañera de trabajo y estamos mutuamente simulando las acciones de Freddy y Anita en nuestros repositorios. Nos llamó la atención que no nos llegaron notificaciones vía GitHub cuando realizamos las interacciones, por ejemplo solicitar la revisión de código, solicitar cambios, etc. Luego descubrimos que sí nos llegaron vía correo electrónico.

Para habilitar las notificaciones directamente en GitHub como las tiene Freddy hay que ingresar a los Settings (del usuario) y luego a la sección Notifications, habilitando las casillas Web de los eventos deseados.

Espero se entienda y a alguien le sea útil!

Code Reviews por medio de Pull Requests son una forma de garantizar que el código producido y compartido sea de la mejor calidad posible y también para que los miembros del equipo comprendan y estén al día con los cambios hechos en el proyecto.

Datos importantes de esta clase:
-Los PullRequest no generan un Merge, es un preludio a este para revisar los cambios.
-Dentro de los PullRequest se puede hacer un review para analizar los commits y cambios, esto permite entender qué es lo que se espera fusionar.
-Si un PullRequest no es aprobado, se deben realizar los cambios, hacer un pull y luego si un push para que se vuelvan a evaluar.
-Si un PullRequest es aprobado, pasa a la siguiente etapa de hacer merge. Este merge es semejante a un commit.

Espero que les ayude.

Caso ejemplo: Error tipográfico en la rama master

$ git branch fix-typo
$ git checkout fix-typo

Luego de solucionar el problema:
$ git commit…
$ git push origin fix-typo

Luego se crea un nuevo Pull Request de master con fix-typo (En GitHub)
Se puede asignar el Pull Request a un miembro, o agregar miembros para que le hagan review, luego hay que " Crear el pull request " y el request pasa al…

Proceso de Code Review
Los reviewers pueden pedir cambios o aprobar el Pull Request, al terminar esto, quien sea que este a cargo de realizar los merge, debe realizarlo.
(Se debe respetar quien es el que hace los merges para tener consistencia en los Code Reviews)
Ya después se puede borrar el branch fix-typo de GitHub dependiendo de las prácticas de cada equipo

Comparto con ustedes la siguiente imagen que me ha parecido interesante.

Esc + Shift + z + z

Excelente clase, yo “usaba bien git” y resulta que eso no era nada cierto jajaa.

Resumen hecho gracias a los aportes de varios compañeros😊

vale me queda mas claro el manejo de las ramas, y entiendo que pull request es como un permiso para poder fusionar o hacer merge

Si estan trabajando en otra pc y quieren traer lo que tienen de su repositorio remoto a su repositorio local deben usar
git fetch
asi traen los cambios y los dejan en otro branch
en cambio con
git pull
traemos los cambios y hacemos el merge con la rama actual

Excelente

git pull origin master
git branch fix-typo
git checkout fix-typo
git status
git diff
git push origin fix-typo
git status
git commit -am "Se corrige la ortografia."
git push origin fix-typo
git pull origin fix-typo
git commit -am "Se corrige la ortografia con ACUTE"  
git push origin fix-typo
git checkout master

Si usan VSCODE
y quieren cambiar todas las tildes por entidades HTML
pongan CTRL+F en Buscar pongan "á"
y en reemplazar pongan á ahora le dan clic en replace all y listo, asi con todas las vocales.

R.I.P Anita! =’(

Si necesitan cambiar o quitar la contraseña de la llave SSH pueden seguir la siguiente guía: Cambiar passphrase SSH .

Básicamente deben correr el comando ssh-keygen -p y seguir los pasos.
Si tienen una clave es más seguro, pero con cada pull y push deben ingresarla.

Sinceramente trabajar con GitHub puede cambiarte mucho la vida!!

Pasos para crear un pull request si eres colaborador

Si eres colaborador solo debes de seguir los siguientes pasos:

  1. Crea una nueva rama (branch) donde vayas a realizar los cambios (también puede ser en la que estas, pero debe ser diferente a master)
  2. Realiza los cambios requeridos
  3. Subelo a GitHub
  4. Ir a pull request
  5. New pull request
  6. Elige que branch proviene el cambio y a donde se hara el pull si se aprueba
  7. En el apartado de la derecha le puedes agregar configuraciones a tu pull request
  8. Cuando estes listo haces click en create pull request (no olvides comentar acerca de los cambios realizados)
  9. Una vez hecho si estableciste a alguien para que lo revisará debe de aprovar el pull request o rechazarla (normalmente se le agrega un comentario)
  10. Una vez aprovado el DevOps (administrador de proyecto) hace el merge

Muy buena clase, me tardé como una hora pero ya aprendí bien el proceso, ando cambiando entre users de git y puedo ver a la perfección lo que dice freddy

La implementación del archivo CODEOWNERS en el repositorio para automatizar los Code Reviewers y exigir su aprobación para que los cambios se apliquen a la rama principal: https://help.github.com/en/articles/about-code-owners

Duda, en el caso de los archivos binarios como lo son imágenes como deberia resolverse el problema entonces?? si la mejor practica es no meterlos , como debería ser entonces??

🐱‍💻 Usar Pull Request nos da la posibilidad de hacer la revisión de código que permite hacer control de calidad interno donde el equipo tiene la oportunidad de detectar bugs o código que no sigue lineamientos, convenciones y/o buenas prácticas.

es bueno practicar estos conceptos con dos computadores o un amigo colaborador

git checkout -b <new-branch> nos crea la rama y nos cambia a esa rama.
Nos ahorra hacer git branch <new-branch>

![](

actualmente en GitHub para crear un pull request debes dar click en la parte de arriba

Practicando me di cuenta que al hacer las cosas como no se deben (sin un Pull requests) no es es tan fácil borrar la branch remota, para lo cual sirve el siguiente comando:
git push origin :[nombre_branch] (Elimina rama remota)

Con el editor de texto en consola Nano(Corrigenme si me equivoco xd) de Ubuntu, se puede mandar el mensaje presionando ctrl + x(Es el homologo de esc + shift + z + z)

un Pull Request es una pausa antes de hacer un merge y solo existen en github

pobre anita la despidieron 😭

Todo es fácil, pero en la vida real al hacer el merge salen docenas de errores

Qué buena clase, siento que estoy desarrollando un super poder !!!
😄

Buena clase, lei el post de la explicación de DevOps, interesante. Vi que la ventaja de usar esa cultura es dar confiabilidad y velocidad a todos los cambios que se vayan haciendo en el sofware.

A nadie le paso que si se habían dado cuenta de los errores ortográficos y ya los habían corregido antes ? XD

Es decir, porqué no me aparece el punto azul al lado de la campanita, así como se ve en la pantalla del profesor. Gracias.

Pull Requests --> le pide al admin del repositorio una revisión de cierta parte del trabajo subido a GitHub.

Es emocionante todo esto!

¿Despidieron a Anita?

Team Platzi, desafortunadamente, en esta clase me perdi. La interfaz de GitHub ahora es completamente diferente a la del video. Honestamente cuesta seguir las instrucciones del video. Se comprende el mensaje. Creo que toca actualizar esa clase. Saludos

Aquí les dejo los comandos para cambiarle el nombre a una rama desde la terminal.

// primero asegúrate que estes en la rama que quieres cambiarle el nombre 
 $ git branch -m new-name

Pull request sería com su nombre lo indica la solicitud para hacer cambios en cualquiera de los branch antes de ejecutar el merge

Supongamos que somos 5 personas en el equipo, sería buena práctica cada uno tener una rama con el nombre de la persona y a su vez cada uno sus sub-ramas para desarrollo?

DevOps (Developer Operations) es una disciplina, carrera u ocupación. La gran mayoría coinciden en que es una cultura que promueve la comunicación e integración entre desarrolladores de software y los equipos encargados de la infraestructura de los servidores.

Rama master: La que eventualmente será enviada al servidor de producción

Rama Staging Develop: Se envía a un servidor de pruebas, rama de desarollo

Siempre las dos ramas deben estar actualizadas con la última versión del proyecto

Pull Requests, son el corazón de la colaboración en GitHub. Cuando abre una solicitud de extracción, está proponiendo sus cambios y solicitando que alguien revise y extraiga su contribución y los combine en su rama. Las solicitudes de extracción muestran diferencias, o diferencias, del contenido de ambas ramas.

Es similar a hacer un merge, solo que en GitHub. Cuando uno ya esta trabajando en equipos.

Ese llamado pull request de git hub funciona como un filtro para antes de enviar nuestros cambios a master, muy útil.

*Pull Request Es como un staging del lado del servidor que permite agregar cambios entre las ramas, y hacer un code review del proyecto.

Para eliminar la rama en el repositorio local se usa git branch -d <nombrerama>

Así fue como Anita perdió su trabajo… Fin.

no despidas annita 😕 no es su culpa tener un jefe opresor

el el minuto 1:51: no hay que hacer add y commit antes de hacer el push a origin?

buen video

![](

Excelente vídeo, se tocan temas claves en el flujo de trabajo profesional.

Estaría bien un video intermedio explicando como configurar varias cuentas git en un config dentro de la carpeta /.ssh y como usar eso para luego hacer push o pull desde esas cuentas…

el pull request es una muy buena practica

Que intensidad …

code review es parte de las buenas prácticas!

  • Recordar siempre traer la última versión del servidor. : git pull origin master

<meta charset=“utf-8”> por favor y gracias 😉

que curioso acabo de mirar trabajos en fronted en Bogotá y hay muchisimo y el salario esta bien, lo malo es que piden de 2 años min de experiencia en fronted

Una clase importante. Sin duda me ayudará mucho en mi día con día.

He aprendido bastante!

Intente hacer todo desde una sola cuenta sin crearme la cuenta de Anita y todo fue muy confuso

En el siguiente Link, describen que es un DevOps.
https://www.youtube.com/watch?v=JtZudJcFcFQ

Grande Anita!

Muy interesante, ahora me queda claro que es un pull request

Super… No estaba claro del uso de pull request… veo que es una supermega muy buena práctica👌

Excelente 😃

Una pena por Anita :_(

respeto tu opinion haciendo los cambios pero reafirmo mi autoridad como jefe haciendo el merge de todos modos.jpg

El curso dice 6 horas de contenido y 16 de practica, la verdad no lleegue a contabilizar pero muchas veces (y en especial en esta clase) me pase mas de una hora leyendo y aprendiendo terminos sobre los DevOps, AWS, kubernetes, Docker y mucho mas, es increible como cada que entras a un blog y hay un termino no conicido hay otro bolg quelo explica 10/10

Pensar que cuando inicié este curso, no sabia mucho (conocimiento básico), la verdad le tenia pereza a aprender Git/GitHub y trate de posponerlo por mucho tiempo, incluso en la universidad siempre le sacaba alguna excusa para no aprender.

Luego veo este curso en Platzi, me animé a tomarlo y ahora no puedo dejar de aprender, incluso me animé a ayudar a otros en este camino 😀💚

Buena explicación de un DevOps
https://aws.amazon.com/es/devops/what-is-devops/

Me parecio bastante interesante . De hecho he aprendido mucho.

Antes me enseñaron lo basico de Git y cuando trabajaba con los compañeros no sabia quien hizo que cambio y ahi si jodidos jajaja

Utilizando Pull Requests en GitHub
Los pull Request son una característica especial de github que permite hacer una pausa justo antes de fusionar dos ramas en la que se nos permite agregar o eliminar cambios.
Al hacer un pull Request se abre una conversación en github en la cual otros colaboradores pueden revisar el pull Request y dar feedback y una vez que el pull Request este aprobado entonces si se procede a hacer la fusión confirmando el pull Request

Los pull requests son la forma de contribuir a un proyecto grupal o de código abierto. Por ejemplo, un usuario llamado Harry realiza un fork de un repositorio de ThanoshanMV y le efectúa algunos cambios. Ahora Harry puede hacer un pull request a ThanoshanMV, pero dependerá de ThanoshanMV aceptar o declinarlo.

A lo que le debo hacer push es a los cambios que ya están listos para producción.

Odio lo debil que es el personaje y ahora anita resulta que manda, pesima serie le falta profundidad a los personajes y pesimo el arco de las entidades de html
les recomiendo el juego del calamar mas o menos es lo mismo pero mejor 😄

F por Anita

Excelente clase para resolver errores y colaborar en el repositorio remoto.

Hasta ahora de lo que voy del curso he aprendido muchísimo en pocos días… Gracias Platzi!!

Si alguien no está como Code Reviewer, ¿puede hacer el merge, o solo los usuarios involucrados?

Que nivel de detalle y que arte para enseñar Freddy! muchas gracias!!!

Que buena clase, super utíl para tener buenas practicas ❤️

SIgamos con la siguiente clase 😄

Interesante el tema de los pull request

Excelente clase, el camino hacia el profesionalismo.

**_pull request: _**una herramienta de github, podemos hacer una pull request entre dos ramas y ver los cambios que se haran, en ese proceso podemos pedir la revbision de otro colaborador y la aprovacion de otros colaborador desde github.

genial explicacion

Crear un pull request

Belleza!

magistral!

El pull request no ejecuta el merge como tal simplemente describe lo que está pasando

😊

😃