Flujo de trabajo profesional con Pull requests

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.

Apuntes!

• 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

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.
.

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 "[email protected]” // 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

![](

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

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.

Pull requests para GitHub

Merge requests para GitLab

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?

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

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.

push requests tiene mas sentido

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.

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

Apuntes 😅

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.

Según entendí el pull request es una forma de evitar cambios inmediatos a una rama principal o importante. Entonces el lider encargado revisa el cambio y lo aprueba o lo niega para que se complete.

Sin duda este curso es de lo mejor que tiene Platzi, no es solo comandos en Git, sino cultura de desarrollo a nivel profesional, por lo que no basta con hacerlo solo una vez, sino que vale la pena repasar estos conceptos continuamente.

DevOps

El término “DevOps” es una combinación de las palabras “development” (desarrollo) y “operations” (operaciones), DevOps incluye sistemas de seguridad, maneras de trabajar en colaboración, análisis de datos, entre otras características.

DevOps describe los enfoques para agilizar los procesos con los que una idea (como una nueva función de software, una solicitud de mejora o una corrección de errores) pasa del desarrollo a la implementación, en un entorno de producción en que puede generar valor para el usuario.

Es una estupenda idea tener una rama actualizada destinada para hacer las pruebas, así se evitan que los errores más comunes ocurran en la rama master y me agrada esa revisión por parte de los miembros del equipo antes de que se fusionen las ramas, de esta manera se verifica el cumplimiento de los requisitos y si se encuentra algún problema corregirlo antes de la fusión.

Servidor de producción: el lugar (servidor) donde se aloja nuestra página web, la aplicación que le hicimos al cliente, etc.

NADIE que sea colaborador debe hacer push a master, para hacer reflejar los cambios, se debe hacer Pull request y un colaborador o el mismo propietario del proyecto, hará code review y posteriormente autorizará hacer el merge, lo usual y lo más profesional es que haya un perfil denominado DevOps, que será encargado de hacer estas revisiones y hacer la vida del programador más fácil. El pull request es un estado intermedio antes de hacer el merge.
Como buena práctica, se debería tener una rama de staging o development para probar todas las funcionalidades que se estén evaluando, una vez aprobados estos cambios y se está conforme con el producto final, se realiza un merge con la rama master, nuevamente, lo ideal NUNCA es trabajar sobre master, sino sobre las ramas.

Pull request: permiten comentarle a otros acerca de los cambios que has subido a una rama en un repositorio en GitHub. Una vez que se abre un pull request, puedes debatir y revisar los posibles cambios con los colaboradores y agregar confirmaciones de seguimientos antes de que tus cambios se fusionen en la rama base.
GitHub - Pull request

No es un curso únicamente de Git & GitHub. Es un curso de cultura general para poder trabajar en el desarrollo de tecnología. Se enseña cultura de trabajo. Cada vez disfruto más de este curso.

Pull Requests: es un intermedio antes de enviar el merge. Permite que otros miembros del equipo puedan ver los cambios que se hicieron y si les gusta aprobarlos y al aprobarlos se auto ejecuta el merge en staging.

Otro dato importante es que Pull requests:** le permite a otras personas que no sean colaboradores trabajar y apoyar en una rama, esto lo hacen los lideres de equipo o un administrador de desarrollo Dev Ops.

Pull request: es un estado intermedio antes de enviar el merge. Permite que otros miembros vean los cambios hechos en el código y aprobar esos cambios (o no) para luego realizar la fusión de ramas.

En master solo se envia codigo probado, si queremos hacer pruevas usamos una rama llamada staging develop, pero para envair codigo nuevo hay que hacer un pull request para que alguin aga un code review antes de enviarlo a staging y despues master.

FLUJO DE TRABAJO PROFESIONAL CON PULL REQUESTS
(Ayuda de memoria de mi paso por la clase 25 del Curso profesional de_ Git_ y Github)
**
En un entorno profesional normalmente se bloquea la rama_ master_. La idea es que nadie pueda hacer un merge a master simplemente porque si y sin que se ha haga una revisión al código (code review). La rama master es la que finalmente se sube al servidor real, al servidor de producción, como suele llamarse el lugar donde se aloja la versión final del proyecto (www.nuestrositioweb.com**, por ejemplo).

Es necesario hacer pruebas en un entorno parecido al de producción sin que afecte a los usuarios. Si se tiene un repositorio, digamos, hyperblog.com, al tiempo se puede tener un hyperblogtext.com o un sub-dominio tal como texthyperblog.com, a manera de servidores de desarrollo o staging develop (no tiene nada que ver con staging de**_ gi_**t). En los servidores de desarrollo están las ramas. Estos deben parecerse, tanto como sea posible, al servidor real.

Funciona de la siguiente manera: se trabaja la rama (el**_ feature_, la característica) en el entorno local, normalmente. Luego se envía la última versión de la rama a_ staging develop_** para hacerle un**_ merge_** a la última versión de este. En teoría**_ staging develop_** y master siempre deben estar actualizados, trabajo que corresponde al líder del equipo de trabajo.

Pero ¡ojo!, antes del merge hay que revisar el código, que es lo acostumbrado en un entorno profesional. La rama entonces va primero a un estado o punto intermedio llamado**_ pull request_. Un pull request es básicamente un estado intermedio antes de hacer merge. Ello permite que otros miembros del equipo de trabajo puedan ver los cambios que se están gestionando y si les gusta, aprobarlos. Al aprobarlos se auto-ejecuta el merge en staging develop. Igualmente, una vez se prueba en staging develop y se verifica que todo está bien, se fusionan los cambios de la rama (feature**) con master, gestión que también se hace con pull request.

El**_ pull reques_t no es una característica de_ git_**, es de github. Github es el sitio web que permite trabajar en equipo con otros programadores del mundo. El **pull reques**t permite a otras personas que no son colaboradoras trabajar y apoyar en una rama. 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.

justo estaba empezando a trabajar con una rama developer para hacer front end a una app web design, me sirvió mucho muy buen curso, no se si lo vayamos a llevar mas adelante pero
Me gustaria saber como bloquear la rama master para que solo el jefe pueda realizar los merge…???
Saludos 😃

https://help.github.com/es/github/administering-a-repository/enabling-branch-restrictions

Mis apuntes
branch main -> solo lo maneja una persona.
staging develop -> es una rama lo mas parecida posible a main en la cual se trabaja antes de enviar a la rama main.
Pull requests -> no es una caracteristica de Git, sino de Github. En el entorno profesional es la forma de revisar el codigo, para posteriomente realizar un ‘git merge’ tanto como para la rama staging develop y main.
DevOps -> perfil especial, que es un administrador del entorno de desarrollo.

Clase 27. Flujo de trabajo profesional con 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.
• La forma de trabajar en el entorno profesional es tener una rama principal, la rama master. Esta rama es la que eventualmente se subirá al servidor real de producción, donde corre tu aplicación. Antes de hacer eso se tiene que hacer pruebas en un entorno que se parezca al de producción, para que no se afecte a los usuarios. Estas pruebas y cambios se guardan en ramas de desarrollo o staging (este staging no tiene que ver con Git). Estas ramas están antes de master y cuentan con servidores de pruebas, que se parecen en todo lo posible al servidor real.
• Supongamos que en la rama master creamos otra rama de algún feature que se este desarrollando, una vez terminado el feature no lo mandaremos a la rama master, sino a la de staging. Normalmente el envió lo haríamos con un merge, pero resulta que esa no es la forma correcta de hacerlo. Porque en un entorno profesional hay que revisar el código, entonces antes de hacer el merge esos cambios se van a un lugar intermedio conocido como pull request, que permite que otros miembros del equipo revisen los cambios que tu hiciste y en caso de aprobarlos se ejecuta el merge en staging. Y una vez que pruebas esos cambios en staging también haces un pull request para fusionar esos cambios con la rama maestra.
• El pull request es una característica de GitHub en GitLab se llama merge request

Notes

• It is recommended to have a second branch before main where you will simulate an environment such as the deployment server, this way you may test all the changes you have to release and make sure everything works perfectly.
• You should never do a direct merge. First, you should make a request for someone to review your code before directly merging the changes. In GitHub, we can use a pull request
• This work of reviewing every detail of the pull request towards the main branch, should be done for a DevOps engineer.

Staging Development

• A pre-production environment is an environment for testing that exactly resembles a production environment. It seeks to mirror an actual production environment as closely as possible and may connect to other production services and data, such as databases.

  https://en.wikipedia.org/wiki/Deployment_environment

Pull Request

• A pull request is an event in Git where a contributor asks a maintainer of a Git repository to review code they want to merge into a project.

  https://www.gitkraken.com/learn/git/tutorials/what-is-a-pull-request-in-git

DevOps

• DevOps is a set of practices that combines software development and IT operations. It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.

  https://en.wikipedia.org/wiki/DevOps

/* Entendi esto , talves algunos terminos medio que confundi pero ahi dejos mis apuntes , si pueden corregirme muchas gracias */

1. En un entorno de desarrollo profesional la rama master se bloquea

2. Antes de subir nuestro codigo a un servidor de produccion se utiliza un servidor de pruebas

3. Existe como una copia de la rama master que se llama staging develop(servidores de prueba)

4. Si tenemos una rama a la que queremos hacer un merge , antes de hacerlo, git hub o la plataforma que estes utilizando otorga una opcion llamada pull request

5. En pull request , los demas desarrolladores pueden aprobar o desaprobar ese codigo .

6. Finalmente Pasa a el servidor de produccion con el merge request ya conocido y termina el proceso

Resumiendo:
En equipos profesionales de desarrollo cuando se trabaja en alguna caracteristica nueva se utiliza una rama especial para probar esas caracteristicas antes de mandarlo a la rama principal de producción. Cuando se manda los cambios de la nueva caracteristica a la rama “staging develop” se realiza un “pull request” que no es más que un estado intermedio en el merge que permite a los administradores de desarrollo darle un visto bueno al codigo. Al aprobar el codigo se ejecuta automaticamente el merge a la rama staging develop.

El pull request debe ser considerado como el estado intermedio entre una rama de desarrolloy un merge, es el llamado code review en donde se observa si aceptar o no este merge. Es de utilidad ya que permite a no colaboradores a ayudar con las features.

Pull Request
Es el estado intermedio antes de enviar el merge (sirve para que los demás colaboradores del proyecto observen y aprueben los cambios que se han hecho antes de hacer una fusión a cualquier rama), son la base de colaboracion de proyectos, no es una característica de git, sino de github.

el pull request es la herramienta que permite que personas ajenas al proyecto, puedan ayudar en una rama.

• Los pull request son funciones específicamente de GitHub y no del propio Git.
• En un entorno de trabajo profesional hay siempre una persona encargada de revisar y efectuar los cambios en la rama master.
• Pull request es una forma de hacer un code review para ser aprobado por el encargado del repositorio
• Dentro de la página de GitHub se pide un pull request indicando la rama a fusionar con master
• Se puede especificar a una persona que haga el review para después decidir si se requieren más cambios en el trabajo o aceptarlos y hacer el merge.

Pull request: Un paso previo a hacer el merge entre la rama feature y la rama de stagging develop
para que otros miembros del equipo revisen los cambios y si estan aprovados ahi se hace ek merge a staggin!

la rama feature tambien tendra un pull request para fusionarse a master

Resumen del flujo de trabajo:

Participantes:

Dev1 <- Rama feature 1
Dev2 <- Rama feature 2
Administrador <- DevOp

Ramas:
master
staging
feature 1
feature 2

1.- Dev 1 finaliza su trabajo, ¡El no puede tocar master!
2.- Dev 1 hace su pull request a la rama staging
3.- Administrador hace el code review
4.- Administrador aprueba el cambio
5… Dev 2 termina su trabajo
6.- Dev 2 hace su pull request a master
7.- Administrador aprueba el pull request de Dev 1 y hace la fusión con la rama staging
8.- Administrador recibe un pull request de Dev 2 en… ¡¿Master?! Usted está loco, esa rama no se toca
9.- Administrador rechaza el pull request de Dev 2 y pide que lo mande a staging
10.- Dev 2 manda su pull request a staging
11.- Administrador lo recibe y revisa el codigo
12.- Administrador aprueba los cambios y hace el merge con staging
13.- Administrador considera que todo está listo y hace su pull request a master
14.- Todo el equipo de DevOps hace sus pruebas en la rama staging viendo que todo funcione correctamente
15.- Todo funciona correctamente, DevOps aprueba el pull request y lo manda a master
16.- Se actualiza la rama master en el servidor de producción y los cambios quedan implementados

Así es como yo entiendo el flujo de trabajo, por favor si me equivoco corrijanme jaja

Cada vez que hago un push o pull me pide la contraseña. Si la conozco pero es algo molesto. ¿Hay alguna forma de que ya no la pida?

Se hace para solicitar el permiso para poder añadir dicha versión del proyecto a la rama master, esto permite que los miembros del equipo encargados de revisar el código apueben o no los cambios que se hicieron. El pull request es una característica de GitHub más no de Git, también otros servicios como GitLab o Bitbucket. Esto permite que personas que no pertenecen al equipo de un proyecto puedan realizar cambios al código y aportar algo. Esta es la base de los proyectos Open Source en el que cualquier persona puede colaborar en el código y así mejorar ese proyecto.

Flujo de trabajo profesional con Pull requests
En un entorno profesional normalmente se bloquea la rama master, la idea es que nadie pueda hacer merge a master solo porque si y que en el proceso antes haya un coach review.

A veces tenemos que hacer pruebas en un entorno que se parezca al de producción a veces tenemos que hacer pruebas en un entorno que sea tan similar como sea posible al entorno de producción sin que afecte a los usuarios. Este tipo de entornos normalmente se llama servidores de desarrollo o servidores de staging (no confundir con staging de git, este es un staging para el desarrollo) Staging en los servidores de desarrollo son ramas que están justo antes de master este tiene su propio servidor de pruebas y se parece en todo lo posible al servidor real.

Como funciona es de la siguiente manera, creamos una rama donde vamos a tener lo que estemos desarrollando y luego enviamos la ultima versión de esta rama a staging para hacerle un merge a la ultima versión de staging (en teoria staging y master siempre deberían estas actualizados) pero el merge no es la forma correcta de hacer lo antes mencionado, en un entorno profesional se debe revisar el codigo por ende no se hacer el merge sino que va a un lugar intermedio llamado Pull Request (P.R) esto es un estado intermedio antes de enviar el merge, lo que este permite es que otros miembros del equipo puedan ver los cambios que yo hice y si les gustan aprobarlos y al aprobarlos se autoejecuta el merge en staging.

Una vez pruebas con staging y luego quieres fusionar con la rama master debes hacer un Pull Request a master.

El pullrequest no es una característica de Git es una característica de Github (Git es la base de datos local pero Github es el sitio web que me permite trabajar en conjunto con otros trabajadores de cualquier lugar)

En entornos de trabajo profesional es poco común que se pueda hacer merge directamente a master. Lo normal es que la rama master este bloqueada y se tenga que hacer un pull request para hacer un merge con master. Esto se debe a que master es la rama que se manda a producción.

Algo que también es común en entornos profesionales es tener un entorno de pruebas que sea lo más similar posible al entorno de producción. Por ejemplo si se tiene un website llamado https://hyperblog.com lo normal es que ese entorno de desarrollo se encuentre en un subdominio como https://test.hyperblog.com. A ese enrorno se le conoce como develop server o staging server.

Staging/develop seria una rama de desarrollo conectada al servidor de Staging. Dicha rama siempre deber estar actualizada con master. Cada desarrollador trabaja en su entorno local y manda sus cambios a la rama de desarrollo pero no hace merge directamente con esa rama sino que hace un pull request que es un estado intermedio antes de hacer el merge en el que otro miembro del equipo revisa los cambios hechos y si toda esta bien permite el merge con la rama de desarrollo. Una vez se prueban los cambios en el servidor de staging se hace otro pull request para agregar esos cambios a master.

Los pull request no son una característica de Git, son una característica de GitHub.

21. Mis apuntes sobre: “Flujo de trabajo profesional con Pull requests”

En entornos profesionales, la rama master estará bloqueada y no permitirá hacerle push.
Lo que está en la rama master es lo que se subirá al servidor de producción,

Se crea una rama nueva llamada “feature”, luego se envía la última versión de esa rama a
staging.

Los servidores de desarrollo/staging son donde se hacen pruebas, es lo más parecido posible
a la rama master.

Antes de hacer el merge ede [staging develop] con el [feature], esto va a un estado intermedio
llamado [pull request], que hasta que no sea aprobado no se realiza.

Quien normalmente aprueba esto es el Devops.

Flujo de trabajo profesional con Pull Requests
Trabajar en diferentes ramas y luego hacer merge a Master es una forma de trabajar, pero en un ambiente profesional por lo general la rama Master está bloqueada y se revisa el código antes de enviar cualquier cosa a esa rama.

Se le llama versión de produccion a la versión final de un proyecto que está en un servidor y disponible en internet.

A veces es necesario hacer pruebas en un ambiente lo más parecido al de producción, los servidores donde se hacen estas pruebas suelen llamarse servidores de desarrollo o servidores de Staging (no es lo mismo que el Staging en Git).

En caso de querer agregar una caracteristica nueva a la aplicación (feature) se crea una nueva rama para trabajar en ella, una vez terminada se envia la ultima version al servidor de Staging para probarla. En teoria, Staging y Master siempre deberian tener la misma versión de la pagina/aplicación.

Normalmente para enviar la caracteristica nueva al servidor de Staging se haria un merge, pero resulta que es no es la forma correcta de hacerlo, porque en un entorno profesional hay que revisar el código. Entonces existe un lugar intermedio conocido como Pull Request, donde se envian los cambios que se quieren hacer. Lo que permite el Pull Request es que otros miembros del equipo puedan ver los cambios que se hicieron, si se aprueban los cambios automaticamente se hace el merge al servidor de Staging.

Una vez se hayan probado los cambios en el servidor de Staging y esten listos para produccion, se hace otro Pull Request para enviar los cambios a producción. La persona que hace este proceso suele ser el líder del equipo o alguien con el perfil de DevOps, que es un administrador del entorno de desarrollo y hace la vida del programador más fácil y efectiva.

Pull Request es una caracteristica de GitHub, no de Git.

El Pull Request también permite a otras personas que no son colaboradores de un repositorio trabajar en una rama.

Algo que lei, es que es pull request y no push request por que tu no haces la peticion de enviar los cambios. Si no, haces la peticion de que revisen tu codigo, y desde la rama principal hacer el pull de la otra.

• La rama master es la que se va a subir al servidor real (servidor de producción).
• Siempre se deben de hacer pruebas en un entorno similar a producción.
• Estos servidores son llamados staging develop (No confundir staging de GIT con staging develop)
  -Staging y master siempre deben de estar actualizados.
  -Pull Request es un estado intermedio antes de enviar el merge.
  -PR permite ver los cambios por otros miembros del equipo y si les gusta, aprobarlos.
• Pull Request no es una característica de GIT si no de GITHUB

Apuntes clases 22-27

DevOps = Administrador del entorno de desarolllo

El Pull Request no es una característica de Git, es una característica de GitHub.

muy interesante conocer las maneras en las que podemos trabajar en un proyecto, gracias !

Veamos un flujo de trabajo con Git para gestionar y aprobar un Pull Request (PR) en un repositorio remoto compartido. El flujo de trabajo se ha comprobado que funciona correctamente en repositorios remotos gestionados en Bitbucket.

Suponemos un equipo formado por 3 desarrolladores (Ana, Lucía y Carlos) que están trabajando sobre un repositorio compartido utilizando el flujo de trabajo denominado Gitflow (ver el post de Vicent Driessen). En la rama develop se integran las features que se van desarrollando en ramas independientes.

Se ha definido la política de que antes de integrar una rama de característica se debe realizar un Pull Request en Bitbucket y algún otro miembro del equipo debe comprobar su funcionamiento y dar el visto bueno. La integración la realizará el mismo desarrollador que ha creado el Pull Request. Aunque Bitbucket proporciona la opción de cerrar el PR desde la interfaz web, utilizaremos comandos Git en el repositorio local para hacerlo.

Un ejemplo del flujo de trabajo:

Ana abre una feature creando la rama feature10, la sube a Bitbucket, realiza commits y cuando termina la característica comprueba que la rama se mezcla bien en develop y crea un PR en Bitbucket.

Lucía revisa el PR, se da cuenta de que faltan un par de cambios y pide a Ana que los termine.

Ana realiza los cambios en la rama, realiza la integración en develop y cierra el PR.

Lucía y Carlos actualizan sus repositorios locales.

Comandos Git para implementar este flujo de trabajo:

1. Ana abre la feature y crea el PR en Bitbucket

$ git checkout -b feature10
$ git push -u origin feature10

$ git add .
$ git commit -m “Cambio”
$ git push

$ git checkout develop
$ git pull
$ git merge feature10

<Se crea el PR en Bitbucket>

$ git reset --merge ORIG_HEAD

$ git checkout feature10
Si el merge en develop genera un conflicto (o bien ficheros en conflicto, o tests que no pasan), se deshace el merge, se añaden cambios en la rama feature10 para evitar los conflictos y se vuelve a probar el merge con develop. La idea es asegurarse de que en el momento de hacer el PR no existe ningún conflicto entre la rama y develop.

$ git reset --merge ORIG_HEAD
$ git checkout feature10

$ git add .
$ git commit -m “Arreglados conflictos con develop”

$ git push

$ git checkout develop
$ git merge feature10

<Se crea el PR en Bitbucket>

$ git reset --merge ORIG_HEAD

$ git checkout feature10

2. Lucía revisa el PR y pide cambios

$ git pull
$ git checkout feature10
$ git checkout develop
$ git merge feature10

$ git reset --merge ORIG_HEAD

3. Ana añade los cambios en la rama y cierra el PR

$ git checkout feature10

$ git add .
$ git commit -m “Cambios añadidos”
$ git push

$ git checkout develop
$ git merge --no-ff -m “Integrado PR (pull request #21)” feature10

$ git push

$ git push --delete origin feature10
$ git branch -d feature10

4. Lucía y Carlos actualizan sus repositorios

$ git checkout develop
$ git pull

$ git branch -d feature10
$ git remote prune origin

Hay dos ramas que siempre debe estar actualizada y en la misma secuencia que son :

Master: esta rama se ejecuta en el servidor de producción
Staging Develop : esta rama se ejecuta en el servidor de pruebas .

Siempre cuando se va realizar un cambio en cualquiera de estas dos ramas. primero debe haber una revisión y queda en un estado de pull request , es un estado intermedio antes de enviar el merge, este estado es para que hagan la revision de código antes de hacer el merge

La mayoria del tiempo esto lo hace lideres de equipos o el cargo devop

IMPORTANTE Pull request solamente se hace cuando es una persona ajena al proyecto, en el caso de que esta mandando una peticion al proyecto de GitHub. Otro caso que tambien se puede ver es cuando tenemos la rama master bloqueada esto se hace para verificar el codigo que estas mandando para no dañar el codigo principal de la rama master y de esta forma 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.

Me interesa mucho colaborar a proyectos open source, es ganancia para todos.
Para mi gano experiencia y portafolio
Ellos ganan trabajo y mejoras.

Y creo que un reclutador ve a un junior que tiene contribuciones a un open source y es muy significativo

Entonces estoy asumiendo que la forma en la que se trabajó la clase pasada no es la correcta, sino que es a través de pull request. Un miembro destacado del equipo debe supervisar y hacer merge de las ramas que los diferentes desarrolladores van trabajando

Un pull request es un estado intermedio antes de realizar el merge.
El merge request en gitlab
Permiten 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.

Esta bastante interesante ese pull request. Y se va entendiendo quien tiene ciertas responsabilidades en hacer el merge, aprobar cambios y demas 😃

Buena clase

Siempre pense que los DevOps eran grupos de programadores privados que los contrataban para ir en equipamiento tactico a desarrollar una App en el Centro.

**Mis apuntes **

pull request

Master

Es la rama donde guardamos nuestra versión estable que podemos darla a conocer al público ya sea en un servidor si es una página web, una app en playstore, una versión del kernel distinta…
Stagin develop

Entornos creados lo más parecido al entorno en el que va vivir nuestro programa para asegurarnos que todo está en orden. Está también deberá de ser una ram en github por que ¿De dónde consigues el software que vas a probar? ¿De master? No, por qué el software que está ahí es el que está listo para darlo a conocer, no para hacer pruebas
Pull request

Para entenderlo primero hay que recordar que era un pull el cuál era un fetch y un merge combinados. El fetch te traía la última información de tu proyecto a tu repositorio (en git) pero no lo actualizaba a los archivos de tú maquina para eso necesitabas hacer un merge de está última versión traida al repositorio con la versión de tu maquina.
Entonce el pull request es cómo solo hacer un fetch para que los administradores del proyecto vean los cambios que se han hecho y ellos deciden si lo aceptan o no (hacer un merge)
Nota: Está analogía la deduje yo, no estoy muy seguro de si funciona así, pero de está manera lo comprendo. Si estoy mal por favor corrigeme me ayudaría a aprender más y a no compartir información erronea

En mi caso el que hace esto en el equipo de DevOps es el Release Manager(yo). Ahora se ha vuelto bastante complicado porque hay 6 equipos, cada uno con 5 desarrolladores trabajando en cosas distintitas. Ya varias veces los desarrollos de unos se han pisado con los de otros devs, hay alguna forma de mejorar este flujo? Como un flujo de versiona miento creado para muchos equipos de trabaja o algo así ?

Cuando entras a trabajar a una empresa, lo mas seguro es que tengas que hacer PR para todo, asi le envias los cambios a tu jefe para que los cheque, a veces como dice Freddy te dan chance de subirlos tu solo pero, si aun no estas seguro de lo que haces, te sugeriría que no lo hicieras, pide primero revisión aunque tengas permiso para hacer merge con master, o bien, pon un tag en donde esta la ultima version estable para que no la vayas a regar y no te cueste el trabajo.

-Digamos que Staging o Servidor de Desarrollo o Servidor de Pruebas también tiene su rama master que debe estar actualizada con o la tiene el servidor de producción; esta es tarea del líder de equipo o DevOps

Entonces se crea una rama feature y se crea un indirectamente un merge con master de staging(Servidor desarrollo) esto en realidad se llama Pull Request, que es un estado intermedio en el merge de una rama diferente a master con master en GitHub
Lo que se hace con el Pull Request es que se permite una revisión por parte de los que autorice el líder de equipo(En esta caso de quien maneje el Repositorio en staging) para que aprueben o escriban sus apreciaciones en cuanto a los cambios.

staging servers, son los servidores, donde hacemos todos los test necesarios, para la mejora de nuestras apliaciones, por lo que tenemos allí, todos nuestro desarrollos.

Nuestro server de staging tiene que ser super parecido al de producción, a lo que también tenemos que añadir, que master junto con staging develop, son dos ramas que tienen que ir casi o a la par.

Flujo de trabajo profesional con Pull requests

En un entorno profesional normalmente se bloquea la rama master, se desarrolla para enviar código a dicha rama pasa por un code review y luego de su aprobación se unen códigos.
Este code review es lo que conocemos como P.R. (Característica de Github, no de git)
Para realizar pruebas enviamos el código a un “staging server” (servidor de prueba), una vez pasadas las pruebas tanto del código como de la aplicación, se pasan al servidor de producción mediante un pull request (GitHub y Bitbucket) o merge request (GitLab).
Los pull request pueden compararse con un control de calidad interno donde el equipo tiene la oportunidad de detectar bugs o código que no sigue lineamientos, convenciones o buenas prácticas. Incluso puede presentar ahorros a la empresa*. Github nos permite llevar un control e implementar un proceso para la atención y revisión de estas solicitudes.
La persona que hace todo esto, normalmente son los lideres de equipo o un perfil muy especial llamado DevOps.
*De acuerdo a estudios, resulta mas barato encontrar y corregir incidencias en etapas tempranas del desarrollo que encontrarlas y corregirlas en producción.

El Pull Request es un estado intermedio antes de enviar el merge. Lo que lo hace importante es que nuestros compañeros pueden revisar el cambio antes de ser enviado, dicho cambio puede ser aprobado o rechazado

DevOps había escuchado el término varias veces pero no sabia que era o en que se enfocaba.

El DevOps debe conocer la metodologìa de producción de software asì còmo tambien tener pleno conocimiento de los cambios realizados

Normalmente los ambientes son:

• Local
• Desarrollo
• Calidad
• Staging
• Producción

Las clases son mucho mas sencillas, que cuando estudiaba sistemas

Clarisimo!!!

Interesante!

gracias por la explicación.

• Pull Request para GitHub

-Merge Request para GitLab

4:43 DevOps: Administrador de un entorno de desarrollo

Honestamente, en este momento puedo entender que es DevOps y parte de su trabajo.

Osea que el pull request es una característica de gitHub no del propio GIT.

Pull Request es un estado intermedio antes de enviar un Merge.

No conocía cuales eran las funciones de un DevOps, creo que me gustaría aprender mas sobre eso.

Solo para cometar que en dev.azure, que es el entorno de control de cambios de Microsoft también se llaman Pull Request

Por qué se llama pull request y no push request?, el segundo nombre tiene más sentido por lo que hace.

Lo más importante de la rama principal master, o main, es que esa es la rama que eventualmente se va a subir al servidor real, al servidor de producción.

Hey muchas gracias por este curso!!

Merge Request tiene más sentido 🤔

Notas 📒

✏️ Flujo profesional para los cambios en main

Para fusionar una rama con main y subirla al repositorio remoto se hizo primero un git merge en el repositorio local entre main y la rama que se desea fusionar, después se actualizo en el repositorio remoto con git push. Sin embargo en un entorno profesional es distinto.

En proyectos profesionales la rama main esta bloqueada para evitar que cualquiera haga actualizaciones en ella. Para poder hacer actualizaciones se debe de hacer primero un pull request.

Un pull request es una funcionalidad que ofrece GitHub y no Git, y es una acción para validar los cambios que se quieren fusionar a la rama main (en este caso). Los demás colaboradores revisan esos cambios y después se decide si se hace merge o no.

Tener en cuenta también que en un entorno profesional se tienen dos servidores, el de producción y el de pruebas.

revisar

¡Apuntes!
Se repasó sobre:

1. Ramas de trabajo
2. Pull Request.

Esta clase se trató, en general, de como se trabaja en GitHub en ambientes profesionales.

1. Ramas de trabajo: en principio se tiene una rama principal que es la rama que posteriormente será la aplicación/página oficial. Esta es la main y cuenta con su propio servidor.
   Otra rama es la de “staging develop”. Esta rama pretende ser el espacio de pruebas de la principal.
   Las otras ramas son los lugares donde se van a hacer las modificaciones necesarias.

2. Pull Request(PR): cuando han finalizado los cambios realizados en alguna rama secundaria, estas deben subirse (o hacer merge) en las principales. Sin embargo, buscando evitar que todos puedan modificar la rama principal, se crea un paso intermedio en el cual alguien revisa los cambios realizados para decidir si se debe o no subir definitivamente a la rama principal. El Pull Request es este proceso.

ok entendido en la teoria , ahora lo veremos en la practica