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

Flujo de trabajo profesional con Pull requests

27/43
Recursos

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.

Aportes 217

Preguntas 26

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

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 鈥渂iografia.txt"
git add . // A帽ado todos mis archivos con cambios hechos en esa carpeta a Stage
git commit -m 鈥渧ersi贸n 1鈥 // Hago entrada o commit de mis archivos a mi repositorio en mi disco duro
git commit -am 鈥渄escripci贸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 鈥淎lejandro鈥 // 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/
鈥揈s recomendado que cuando hagas cambios de tags y se vayan a subir a tu rama remota en GitHub, hagas primero un 鈥済it 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 鈥淪oy 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
鈥揅omo 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

鈥揘otas 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?

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 鈥淒evOps鈥 es una combinaci贸n de las palabras 鈥渄evelopment鈥 (desarrollo) y 鈥渙perations鈥 (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 馃槂

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 鈥榞it 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

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 鈥渟taging develop鈥 se realiza un 鈥減ull 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?

<h3>Pull requests</h3>

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)

<h3>Flujo de trabajo profesional con Pull request</h3>

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: 鈥淔lujo 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 鈥渇eature鈥, 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

<h1>Hace cambios y commits y los sube al repositorio</h1>

$ git add .
$ git commit -m 鈥淐ambio鈥
$ git push

<h1>Comprueba que el merge con develop funciona bien</h1>

$ git checkout develop
$ git pull
$ git merge feature10

<h1>Si el merge es OK, se crea el PR en Bitbucket</h1>

<Se crea el PR en Bitbucket>

<h1>Se deshace el merge</h1>

$ git reset --merge ORIG_HEAD

<h1>Y se cambia a la rama a la espera de que un compa帽ero apruebe el PR</h1>

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

<h1>Si el merge en develop no es OK</h1> <h1>Se deshace el merge</h1>

$ git reset --merge ORIG_HEAD
$ git checkout feature10

<h1>Se hacen los cambios para arreglar los conflictos</h1>

$ git add .
$ git commit -m 鈥淎rreglados conflictos con develop鈥

<h1>Se suben los cambios</h1>

$ git push

<h1>Y se crea el PR despu茅s de comprobar que la integraci贸n con develop ser谩 OK</h1>

$ git checkout develop
$ git merge feature10

<h1>Si el merge es OK, se crea el PR en Bitbucket</h1>

<Se crea el PR en Bitbucket>

<h1>Se deshace el merge</h1>

$ git reset --merge ORIG_HEAD

<h1>Y se cambia a la rama a la espera de que un compa帽ero apruebe el PR</h1>

$ git checkout feature10

2. Luc铆a revisa el PR y pide cambios

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

<h1>Comprueba el merge y se da cuenta de que faltan</h1> <h1>un par de cambios, que pide en la interfaz de Bitbucket.</h1> <h1>Deshace el merge para volver develop al commit anterior</h1>

$ git reset --merge ORIG_HEAD

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

$ git checkout feature10

<h1>A帽ade los cambios</h1>

$ git add .
$ git commit -m 鈥淐ambios a帽adidos鈥
$ git push

<h1>El push actualiza el PR en Bitbucket, y los compa帽eros pueden ver los nuevos cambios</h1> <h1>Cuando todo est谩 OK, se cierra el PR (supongamos que es el n煤mero 21)</h1>

$ git checkout develop
$ git merge --no-ff -m 鈥淚ntegrado PR (pull request #21)鈥 feature10

<h1>La cadena pull request #21 aparecer谩 en lal web de Bitbucket como un enlace a la p谩gina del PR</h1> <h1>Sube el merge a Bitbucket y esto cierra el PR</h1>

$ git push

<h1>Se borra la rama en remoto y en local</h1>

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

4. Luc铆a y Carlos actualizan sus repositorios

$ git checkout develop
$ git pull

<h1>Si se han bajado la rama feature10 tienen que borrarla en local y borrar la referencia remota</h1>

$ 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 鈥渟taging 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 鈥渟taging 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