Flujo de trabajo profesional con Pull requests

Clase 27 de 43 • Curso Profesional de Git y GitHub

Resumen

En un entorno profesional normalmente se bloquea la rama master, y para enviar código a dicha rama pasa por un code review y luego de su aprobación se unen códigos con los llamados merge request.

Para realizar pruebas enviamos el código a servidores que normalmente los llamamos staging develop (servidores de pruebas) luego de que se realizan las pruebas pertinentes tanto de código como de la aplicación estos pasan al servidor de producción con el ya antes mencionado merge request.

Los PR (pull requests) son la base de la colaboración a proyectos Open Source, si tienen pensando colaborar en alguno es muy importante entender esto y ver cómo se hace en las próximas clases. Por lo general es forkear el proyecto, implementar el cambio en una nueva rama, hacer el PR y esperar que los administradores del proyecto hagan el merge o pidan algún cambio en el código o commits que hiciste.

Proceso de un pull request para trabajo en producción:

Un pull request es un estado intermedio antes de enviar el merge.
El pull request permite que otros miembros del equipo revisen el código y así aprobar el merge a la rama.
Permite a las personas que no forman el equipo, trabajar y colaborar con una rama.
La persona que tiene la responsabilidad de aceptar los pull request y hacer los merge tienen un perfil especial y son llamados DevOps

Aporte creado por: Kevin Morales.

Kevin Morales

student•

Los PR son la base de la colaboración a proyectos Open Source, si tienen pensando colaborar en alguno es muy importante entender esto y ver cómo se hace en las próximas clases. Por lo general es forkear el proyecto, implementar el cambio en una nueva rama, hacer el PR y esperar que los administradores del proyecto hagan el merge o pidan algún cambio en el código o commits que hiciste.

iVICH Dev

student•

Muchas gracias!

Ian Mande

student•

Haz realizado algún PR a algun proyectos Open Source Ikenshu?

Como es ? cuéntanos tu experiencia

Angelo Paul Yenque Tume

student•

Apuntes!

Bernardo Aguayo Ortega

student•

bro me encantan tus aportes, gracias

Marcos Caceres

student•

deberías hacer un tutorial de apuntes, están brutales, muchas gracias

Wilson Fernando Antury Torres

student•

Un pull request es un estado intermedio antes de enviar el merge.
El pull request permite que otros miembros del equipo revisen el código y así aprobar el merge a la rama.
Permite a las personas que no forman el equipo , trabajar y colaborar con una rama.
La persona que tiene la responsabilidad de aceptar los pull request y hacer los merge tienen un perfil especial y son llamados DevOps

Arturo Mauricio Terceros Beltrán

student•

Buen resumen!!!

Joseph Michael Ciriaco Bermúdez

student•

muchas gracias por el resumen

Nestor Quiroga Suárez 🧑🏼‍🚀

student•

Hace un par de clases no entendía muy bien la diferencia entre Merge y Pull Request, ahora todo me queda mucho más claro; a continuación realice una pequeña descripción de la clase, espero les sirva. .

Carlos Celemín

student•

Gracias por compartir la imagen

Juan Pablo Cuenca Ludeña

student•

Excelente, esa imagen está super clara (de entener) jeje

Uriel Alberto Arevalo Franco

student•

Julio Paredes

student•

Gracias !

Nelson Cadenas

student•

Gracias!!!!

Daniel Felipe Merchan Fuquen

student•

Kevin Hernandez

student•

Se ven geniales tu apuntes.

Oriana Suljeis Posada Molina

student•

Pull requests: Es una característica de GitHub no de Git

Alejandro Cortes

student•

git init // Inicio mi carpeta en la que estoy parada como mi nuevo repositorio git git add biografia.txt // Añado en Stage mi archivo "biografia.txt" git add . // Añado todos mis archivos con cambios hechos en esa carpeta a Stage git commit -m "versión 1" // Hago entrada o commit de mis archivos a mi repositorio en mi disco duro git commit -am "descripción" // Este comando es un add y un commit junto, y funciona simepre y cuando los archivos que este haciendo commit ya hayan sido anteriormente adheridos al repositorio o mejor dicho que no sean nuevos git status // Estado de mi rama git show // Muestra todos mis cambios hechos git log biografia.txt // Ver el historial de mi archivo git push // Enviar a mi repositorio remoto todos mis archivos git pull // Traer a mi repositorio local todos mis archivos git rm --cached biografia.txt // Revierte el add cuando este se encuentra en Stage. Elimina los archivos del área de Staging y del próximo commit pero los mantiene en nuestro disco duro. git rm --force // Elimina los archivos de Git y del disco duro. Git siempre guarda todo, por lo que podemos acceder al registro de la existencia de los archivos, de modo que podremos recuperarlos si es necesario (pero debemos usar comandos más avanzados). git config --list // Me muestra las configuraciones del Git git config --list --show -origin // Me muestra donde estan ubicadas las configuraciones de Git git config --global user.name "Alejandro" // Setea de forma global el usuario Git git config --global user.email "mail@gmail.co" // Setea el correo del usuario Git git diff // Podemos ver los cambios incluso cuando tengamos archivos en Stage y hayamos hecho cambios nuevos cuando estos archivos estan en Stage git diff [Hash del commit] [Hash del commit] // Cuando sacamos un log de algun archivo podemos tomar sus hash para mirar las diferencias de sus cambios

/** Volviendo al pasado **/ git reset [Hash del commit] --hard // Cuando si o si queremos volver a un commit anterior en el tiempo git reset [Hash del commit] --soft // Lo mismo que el anterior con la diferencia de que no va a afectar lo que tengamos en stage git reset HEAD // Este es el comando para sacar archivos del área de Staging. No para borrarlos ni nada de eso, solo para que los últimos cambios de estos archivos no se envíen al último commit, a menos que cambiemos de opinión y los incluyamos de nuevo en staging con git add, por supuesto. git restore biografia.txt // Cuando un archivo es modificado pero no se encuentra en Stage o mucho menos en Commit puede devolverse a su estado inicial con este comando. git log --stat // Miro los cambios en Bytes que se hicieron en cada Commit y los archivos que se modificaron git checkout [Hash del commit] biografia.txt // Podemos darle al checkout un hash especifico para mirar un commit en especifico

/Jugando con ramas remotas/ git clone [url_del_servidor_remoto] // Nos permite descargar los archivos de la última versión de la rama principal y todo el historial de cambios en la carpeta .git.
git push // Luego de hacer git add y git commit debemos ejecutar este comando para mandar los cambios al servidor remoto. git fetch: Lo usamos para traer actualizaciones del servidor remoto y guardarlas en nuestro repositorio local (en caso de que hayan, por supuesto). git merge: También usamos el comando git fetch con servidores remotos. Lo necesitamos para combinar los últimos cambios del servidor remoto y nuestro directorio de trabajo. git pull: Básicamente, git fetch y git merge al mismo tiempo. git remote add origin [Direccion de repositorio en git] // Conectamos git local con github git remote // ramas remotas git remote -v // ramas remotas pero verbal git push origin master // Estamos enviando a GitHub nuestros archivos de la rama master que hay local git pull origin master // Estamos trayendo a Git local nuestros archivos de la rama master que hay en GitHub git pull origin master --allow-unrelated-histories //En caso de que se reuse a hacer merge por la diferencia de historias o commits gir remote set-url origin [Direccion de repositorio en git HTTPS o SSH] // Cuando ya tenemos creada una rama remota podemos cambiar la direccion o tipo de conexion con esta sentencia

/Graficando ramas en el terminal/ git log --all -graph --decorate --oneline

/Puedes guardar comandos de git con alias/ alias [Como quieres tu llamar tu alias ej: arbolito] = "[Comando de git que quieres guardar en el alias]"

/TAGS/ --Es recomendado que cuando hagas cambios de tags y se vayan a subir a tu rama remota en GitHub, hagas primero un "git pull origin [rama remota]" para mantenerte actualizado BUENA PRACTICA git tag // Te muestra la lista de todos los TAGS git tag -a [Nombre del tag ej: v0.1] -m "Soy un comentario de commit" [Y el hash de la rama ej: 1b56158] git show-ref --tags git push origin --tags // Vamos a enviar a origin nuestros tags creados localmente git tag -d [Nombre del tag a eliminar] // Se usa para eliminar de forma local tus tags --Como acabamos de hacer un cambio de los tags a manera local, tienes que hacer pull de la rama remota y luego push de tus cambios locales de los tags eliminados git push origin :refs/tags/[Nombre del tag que quieres borrar] // Para borrar de manera remota, previamente ya que has borrado el tag de forma local

git ls-remote --tags repository-name // Mostramos las tags que tenemos en nuestro repositorio remoto. git push repository-name --delete tagname // Otra forma de borrar los tags de repositorio remoto

--Notas sobre TAGS de Platzi Crear un nuevo tag y asignarlo a un commit: git tag -a nombre-del-tag id-del-commit. Borrar un tag en el repositorio local: git tag -d nombre-del-tag. Listar los tags de nuestro repositorio local: git tag o git show-ref --tags. Publicar un tag en el repositorio remoto: git push origin --tags. Borrar un tag del repositorio remoto: git tag -d nombre-del-tag y git push origin :refs/tags/nombre-del-tag.

/Ramas o Branches/ git branch // Muestro mis ramas locales git show-branch // Muestra las ramas y algo de informacion de sus commits git show-branch --all // Muestra lo mismo que el comando anterior pero con algunos detalles mas: Con las ramas remotas tambien gitk // Nos muestra una ayuda visual historicamente de las ramas de git git branch [Nombre de la rama que quieres crear]// Creando ramas locales, es recomendable que crees tu nueva rama parandote desde la rama de la cual te vas a basar o recomendable puede ser desde la ultima rama mas actualizada

Fernando Villalobos Escalante

student•

Gracias!!

Marygert Cherly

student•

Excelente, gracias!!!

Henry Alexander Velásquez Rosas

student•

Apuntes 😅

Sebastian Silva

student•

Esta muy padre. Te recomiendo checar el curso de orataria de freddy sobre como realizar diapositivas y asi tu trabajo se veria incluso mejor.

Henry Alexander Velásquez Rosas

student•

Gracias :3

Ricardo Arturo Salamanca Mora

student•

resumen breve del curso: primero creamos un repositorio que queremos empezar a seguir con git con el comando:

git init

luego agregamos al área de staging los archivos que queremos que git rastree con el comando

git add [nombrearchivo] o [.] para que siga todos los archivos

finalmente cuando queremos enviar cambios y tener un historial de ellos los enviamos a la base de datos de git con el comando

git commit

si queremos ver el historial de commits ejecutados ejecutamos:

git log

si queremos verlo de una manera un poco mas grafica utilizamos:

git log --graph --oneline --all --decorate

gitk 
//nos muestra un software que nos ayudara para visualizar los cambios en un entorno mas gráfico

cuando queremos trabajar sobre otras ramas ejecutamos el comando:

git branch [nombreRama] &quot;me crea una rama nueva&quot;

O si queremos crear una rama y posicionarnos una vez creada en ella utilizamos:

git checkout -b [nombreRama]

si queremos cambiar de rama utilizamos:

git checkout [nombreRama]

cuando queremos fusionar una rama utilizamos el comando:

git merge [nombreDeRamaAFusionar]
//es importante aclarar que debemos estar posicionados en la rama a la cual queremos traer los cambios

pero también si queremos ver las ramas creadas simplemente utilizamos el comando

git branch

______________________________________________________

cuando empezamos a trabajar con varias personas es necesario subir nuestro repositorio local a un repositorio remoto existen varios servidores remotos controladores de versiones 1.gitHub 2.gitLab 3.Bitbucket lo primero que debemos hacer es crear un repositorio remoto cuando ya lo tengamos creado debemos ejecutar en nuestro repo local el siguiente comando:

git remote add origin [url]
//Puede ser https o ssh segun como lo tengamos configurado

si queremos visualizar las conexiones remotas que tenemos en nuestro repositorio local utilizamos:

git remote -v

luego debemos ejecutar el comando:

git pull origin [nombreDeRama]

si no nos permite traer los archivos desde el servidor remoto debemos utilizar el comando:

git pull origin master --allow --unrelated-histories
//con esto forzara a que me traiga los commit que hallan en el repo remoto asi no hallan concidencias de commit con mi repo local

luego si queremos enviar cambios hechos en local al repositorio remoto debemos ejecutar:

git push origin [nombreRama]

y finalmente en este momento conocemos acerca de pull requests

En un entorno profesional normalmente se bloquea la rama master, y para enviar código a dicha rama pasa por un code review y luego de su aprobación se unen códigos con los llamados merge request.

Para realizar pruebas enviamos el código a servidores que normalmente los llamamos staging develop (servidores de pruebas) luego de que se realizan las pruebas pertinentes tanto de código como de la aplicación estos pasan a el servidor de producción con el ya antes mencionado merge request.

Tomás D´Angelo

student•

Excelente aporte, gracias!

Nestor Rios Garcia

student•

¡Gracias!

Juan Carrillo

student•

Git branching model https://nvie.com/posts/a-successful-git-branching-model/

José Gregorio Block

company_admin•

#Interesante

Jared Nava

student•

Mi cerebro entro en crisis.

si git "push" es para empujar literalmente los datos y git "pull" para traerlos... por que el comando es pull request?

Jorge Joaquin Rangel Lagardera

student•

Porque es como si la rama que recibe el cambio estuviese ejecutando pull hacia tu computador, es como si tu fueses el origin y ellos hacen pull. Estás pidiendo (request) que ellos hagan pull.

Patricio Villarroel Durán

student•

No eres el único que piensa así. Es más, en GitLab el comando es "merge request"

Gerardo Alvarado Garcia

student•

Pull requests para GitHub

Merge requests para GitLab

Brandon Díaz

student•

Pull request, también para BitBucket

Angel Enrique Barrios

student•

push requests tiene mas sentido

Manuel Alejandro Aguilar Téllez Girón

student•

Jajaja, estoy súper de acuerdo contigo, no recuerdo muy bien si es en éste video donde explica el porqué se llama así, si lo descubro en algún momento no dudaré en escribirlo aquí. :D

JUAN SEBASTIAN RODRIGUEZ JIMENEZ

student•

Totalmente de acuerdo, creería que se llama así para diferenciarse de los otros servicios de trabajo colaborativo.

Mauro Ferrín

student•

Pull requests: Sirve para que los demás colaboradores del proyecto observen y aprueben los cambios que se han hecho antes de hacer una fusión (merge) en una rama específica.

Usuario anónimo

user•

✨ Pull request permite realizar una petición para integrar nuestras propuestas o cambios de código a un proyecto de software.

Andrés Soret Chacin

student•

Muchas gracias 😁👍

Oriana Suljeis Posada Molina

student•

++Pull requests:++ En un entorno profesional se bloquea la rama master para que no todos puedan hacerle un merge master porque así lo quieran, es un estado intermediario antes de enviar el merge.

José Vinicio Flores Arias

student•

**Pull Request: ** Es un estado intermedio antes de enviar el merge.

Erik Elyager

student•

Sólo para complementar Pull Request es la forma en la tú le haces saber al dueño del repositorio que tienes cambios que quieres sean integrados. Él/Ella se hará cargo de hacer el merge una vez aprueba tu trabajo.

Maria Camila Pulido Muñoz

student•

En esta clase puedes ver todo lo relacionado con Pull requests

Usuario anónimo

user•

Les voy a contar todo el proceso que hacemos en la empresa para la cual trabajo, pues en mi empresa obviamente también hacemos PR, así nosotros estemos agregados al proyecto.

Lo primero que debemos hacer es crear una nueva rama copiandonos de la última versión de la rama develop, en esa nueva rama hacemos los cambios que debemos hacer y esos cambios deben estar asociados a una tarea de Azure, cuando terminamos, probamos y si todo está OK, hacemos el push a la rama remota para que se suba al repositorio remoto (Los Commit y PR deben cumplir con una estructura estipulada en un documento interno llamado lineamientos git).

Una vez arriba, hacemos el PR donde se verifica que no existan conflictos, después nuestro líder de célula lo aprueba y publica en desarrollo.

Después de eso, lo prueban los analistas funcionales, si ellos certifican, se pasa a main o master. Una vez está todo ok, eliminamos la nueva rama creada y volvemos a hacer el proceso con otra tarea de Azure.

Ese es el proceso que hacemos, se ve un poco burocrático, pero creanme que es lo mejor para evitar conflictos, pisar cambios de compañeros, etc.

JUAN SEBASTIAN RODRIGUEZ JIMENEZ

student•

La persona encargada de coordinar todo lo que sucede con el proyecto es comúnmente denominada DevOps, un administrador del entorno de desarrollo que hace más fácil la vida del programador y crea el ambiente para que los equipos de trabajo hagan su labor de manera más efectiva.

Jonathan Fernando Santana Quispillo

student•

Y los DevOps tengo entendido que son herramientas, que te ayuda a tu proceso de realización y administración en los proyectos de software. Y no una denominación a una persona que que sea el admin en el proyecto a elaborar.

Kevin Morales

student•

Puede conocer mucho más sobre DevOps en el este curso https://platzi.com/clases/devops/