Flujo de trabajo profesional con Pull requests
Contenido del curso
Kevin Morales
iVICH Dev
Ian Mande
Angelo Paul Yenque Tume
Bernardo Aguayo Ortega
Marcos Caceres
Wilson Fernando Antury Torres
Arturo Mauricio Terceros Beltrán
Joseph Michael Ciriaco Bermudez
Nestor Quiroga Suárez 🧑🏼🚀
Carlos Celemín
Juan Pablo Cuenca Ludeña
Uriel Alberto Arevalo Franco
Julio Paredes
Nelson Cadenas
Daniel Felipe Merchan Fuquen
Kevin Hernandez
Oriana Suljeis Posada Molina
Alejandro Cortes
Fernando Villalobos Escalante
Marygert Cherly
Henry Alexander Velásquez Rosas
Sebastian Silva
Henry Alexander Velásquez Rosas
Ricardo Arturo Salamanca Mora
Tomás D´Angelo
Nestor Rios Garcia
Juan Carrillo
José Gregorio Block
Company_admin
Jared Nava
Jorge Joaquin Rangel Lagardera
Pat Villarroel
Gerardo Alvarado Garcia
Brandon Díaz
Angel Enrique Barrios
Manuel Alejandro Aguilar Téllez Girón
JUAN SEBASTIAN RODRIGUEZ JIMENEZ
Mauro Ferrín
Usuario anónimo
User
Andrés Soret Chacin
Oriana Suljeis Posada Molina
José Vinicio Flores Arias
Erik Elyager
Maria Camila Pulido Muñoz
Usuario anónimo
UserJUAN SEBASTIAN RODRIGUEZ JIMENEZ
Jonathan Fernando Santana Quispillo
Kevin Morales
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.
Muchas gracias!
Haz realizado algún PR a algun proyectos Open Source Ikenshu?
Como es ? cuéntanos tu experiencia
Apuntes!
bro me encantan tus aportes, gracias
deberías hacer un tutorial de apuntes, están brutales, muchas gracias
Buen resumen!!!
muchas gracias por el resumen
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. .
Gracias por compartir la imagen
Excelente, esa imagen está super clara (de entener) jeje
Gracias !
Gracias!!!!
Se ven geniales tu apuntes.
Pull requests: Es una característica de GitHub no de Git
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
Gracias!!
Excelente, gracias!!!
Apuntes 😅
Esta muy padre. Te recomiendo checar el curso de orataria de freddy sobre como realizar diapositivas y asi tu trabajo se veria incluso mejor.
Gracias :3
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
o
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] "me crea una rama nueva"
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.
Excelente aporte, gracias!
¡Gracias!
Git branching model https://nvie.com/posts/a-successful-git-branching-model/
#Interesante
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?
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.
No eres el único que piensa así. Es más, en GitLab el comando es "merge request"
Pull requests para GitHub
Merge requests para GitLab
Pull request, también para BitBucket
push requests tiene mas sentido
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
Totalmente de acuerdo, creería que se llama así para diferenciarse de los otros servicios de trabajo colaborativo.
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.
✨ Pull request permite realizar una petición para integrar nuestras propuestas o cambios de código a un proyecto de software.
Muchas gracias 😁👍
++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.
**Pull Request: ** Es un estado intermedio antes de enviar el merge.
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.
En esta clase puedes ver todo lo relacionado con Pull requests
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.
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.
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.
Puede conocer mucho más sobre DevOps en el este curso https://platzi.com/clases/devops/
