Midu, me hice un fork de tu proyecto. Mira, este está interesante porque creo que así podemos aprender todos
de cómo hacer un fetch de AppStream. Dice Edwin Berrones,
dice, Midu, me hice un fork de tu proyecto
de Kodilink, ¿cómo hago para que baje los cambios para tener mi repo
con lo último que agregaste? Esto es súper típico y os voy a enseñar
dos formas, bueno, voy a enseñar una, que es la más fácil,
porque hay otra forma, pero es que ni siquiera lo vais a necesitar. Pero hay dos
formas de hacerlo, que una sería configurar el AppStream en el
repositorio local que tenéis para descargar lo que sería del
AppStream, y hay otra forma que es mucho más fácil, ¿vale? Entonces,
a ver, voy a ver si tengo por aquí algún
alguno...
Debo tener algún fork por ahí.
No sé por qué Spotify se me para solo
y me quedo sin música. Bueno, total,
os voy a enseñar, ¿vale? Esto, si tenéis un fork,
por ejemplo, vámonos aquí a Git, si vais a un fork mismo,
yo tengo aquí, por ejemplo, developergoogle.com,
este lo forqué yo el otro día para hacer una traducción.
Developergoogle.com es, ¿no? ¿O no?
A ver, voy a mirar mis repositorios, a ver si está.
Developer... Aquí, developer.chrome.com.
Developer.chrome.com.
Developer.chrome.com.
Vale. El tema, si yo hago aquí un fork,
yo ya he hecho un fork de este repositorio.
Voy a darle al fork y me va a decir, oye, ya tienes un fork.
Vale, perfecto. Pues voy a ir a mi fork.
Si te vas a tu fork en GitHub,
tienes una forma súper, súper sencilla de hacerlo.
Fíjate que aquí me dice que mi rama está dos commits por detrás
de la de Google Chrome Main.
¿Vale? ¿Qué significa esto?
Significa que lo que yo tengo aquí en este repositorio,
que yo me he hecho el fork, estoy por detrás.
Y por lo tanto, si yo intento...
Es lo que me dice Edwin en este caso, ¿no?
Que se hizo un fork del proyecto de Codilink,
que si no lo conoces, deberías,
porque se va a convertir en el playground
de código más usado del mundo, ¿vale?
Que es esta maravilla.
Hola, mundo.
Uy, vale.
Esta cosa tan chula.
Bueno, pues se hizo un fork de este proyecto
y el problema...
Aquí tenemos cuatro PRs que tenemos que mirar.
Mañana las vamos a mirar aquí en directo.
Bueno, se hizo un fork y el problema es...
Vale, pero...
Claro, yo me hice un fork,
pero tú aquí has seguido trabajando.
¿Cómo me puedo traer estos commits?
La forma más sencilla es que vayas a tu fork
y cuando ves que te pone esto...
Aquí tienes un botón que pone Fetch Upstream.
Lo que quiere decir Upstream,
lo que quiere decir es como el stream de más arriba,
o sea, de dónde hiciste el fork.
Esto es para recuperar de dónde hiciste el fork
y, por lo tanto, lo que puedes hacer es un Fetch and Merge.
Así que si tienes cambios que rompan,
seguramente tendrías conflictos,
pero si le das...
Le puedo dar a Compare
y entonces va a comparar un poco los cambios.
¿Ves?
Tengo aquí los dos commits que iba por detrás
y estos son los cambios que me voy a traer
y estos me los voy a traer a mi fork.
Es importante que esto lo hagas desde tu fork.
Fíjate que yo estoy en mi fork, en mi repositorio.
Aquí te pongo a fork, no sé qué, no sé cuánto.
Pues le das aquí Fetch Upstream,
le das Fetch and Merge
y esto lo que va a hacer es traerte los cambios
de mi repositorio.
Ya está.
Ahora ya está.
Dice esta rama está even,
o sea, que está igual que de la que está haciendo fork.
O sea, esta rama main está igual que el main de Google Chrome.
De forma que si tengo que hacer una PR,
ahora ya puedo trabajar con esto.
Ahora lo que necesitarías, además,
obviamente, en tu proyecto local,
sería developer.google,
entrar, no, developer,
a developer.chrome.com, ¿vale?
Y aquí, bueno, sería,
bueno, yo porque estaba aquí en una rama,
me voy a main y tendría que hacer un pull de los cambios.
O, bueno, he hecho un pull,
pero sea git pull origin main, ¿vale?
Ahora ya me los he traído.
Fíjate que cuando me los he traído
son justamente los cambios que no tenía,
que son los que he sincronizado ahora, ¿vale?
Esto es una forma de hacerlo.
Otra forma que lo podrías hacer sería añadiendo el upstream, ¿vale?
El upstream en tu repositorio local.
De hecho, lo podemos hacer en un momento, ¿vale?
Esta sería la forma,
la que vamos a ver ahora es la forma avanzada.
Os he enseñado la forma fácil,
que yo es la que os recomiendo
porque así no os tenéis que liar y es mucho más fácil.
Pero os voy a enseñar la forma pro,
la forma donde la gente que realmente sabe
pierdes tus cambios.
No, no tiene por qué.
O sea, si haces un fetch y haces un merge
y tus cambios que tienes en tu rama por algún motivo
no entran en conflicto,
no pierdes tus cambios, ¿vale?
Otra cosa es que pierdan el conflicto.
Un placer, Joche.
Un abrazo muy grande, crack.
No pierdes tus cambios siempre y cuando no entren en conflicto.
Si tú tienes unos cambios, lo que te pondrá aquí,
¿sabes qué pondrá aquí?
Pondrá tu rama, está tres commits por delante, ¿vale?
Aquí verás que a veces te dice,
estás cuatro commits por detrás y diez commits por delante.
Eso puede ocurrir porque, claro,
tú cuando hiciste el fork,
puede haber ocurrido que el otro repositorio
pues siga trabajando,
pero tú también sigas trabajando.
Por lo tanto, puedes quedarte atrás
respecto al otro repositorio,
pero tu repositorio estar por delante
respecto al otro repositorio a la vez, ¿vale?
O sea, un poco para que lo entendamos.
Esto, a ver, es bastante interesante
porque esto es algo del mundo real.
Esto es cómo se trabaja en el mundo real.
Esto es mucho de código abierto.
O sea, que creo que os puede servir.
Os voy a enseñar también,
hemos visto la forma fácil,
la forma más sencilla,
pero voy a enseñar también la forma,
digamos, la más pura
o la que se basa solo en Git.
Porque esto es GitHub
y GitHub te lo facilita por esto, ¿no?
Con el fetch upstream este y ya está.
Pero la forma,
cómo lo harías con Git,
imagínate que no existe GitHub, ¿no?
Entonces, como...
Pero se utiliza otra cosa
que no es GitHub
y no está ese botón
o no existe ese botón.
¿Cómo podemos crear nuestro propio botón?
Lo que deberíamos hacer,
primero,
es un Git.
Voy a hacer esto un poco más grande.
Madre mía,
¿veis por qué he escrito un libro de Git?
Porque tiene estas cosas que son...
Pondríais Git Remote menos...
Bueno, podéis poner Git Remote y ya está.
Pero Git Remote es un poco rollo.
Git Remote lo que te dice
son los repositorios remotos
a los que está conectado
tu repositorio local, ¿vale?
Entonces, ahora me dice
que solo está en Origin,
que en mi caso es este de aquí.
Este fork que tengo aquí
en el repositorio remoto
es este que ves aquí.
Y este sería mi repositorio local
que el remoto es este Origin.
Para ver dónde está,
porque claro,
si ves Origin te quedas un poco igual.
Dices, Origin, ¿qué?
Pues pones menos V
y esto es verboso
y aquí sí que lo entienden mejor.
Los repositorios remotos que tengo,
tengo uno con el alias Origin
que va a esta dirección de aquí.
git arroba github.com
barra dos puntos
midudev barra developer.com
que esta dirección
corresponde con esta de aquí.
Como puedes ver,
hay dos direcciones de Origin.
Una para hacer el fetch y el push.
Lo más normal,
y esto es...
Yo creo que no lo he encontrado jamás.
Nunca he encontrado, ¿vale?
Pero lo más normal
es que coincida,
pero podría ser
por no sé qué oscura magia
digna del doctor extraño,
doctor strange,
puedan ser diferentes,
pero es muy raro, ¿vale?
Entonces,
esto es como se suele trabajar,
con solo un repositorio remoto.
¿Qué quiere decir?
Que tu repositorio local
solo está conectado
a un repositorio remoto
en la nube.
El repositorio remoto
sería este que tenemos aquí
en GitHub
y el local
sería el que tenemos aquí
en nuestro ordenador.
Ahora,
imagínate
que es lo más normal,
esto sí que puede ser normal,
que podamos tener
otro repositorio remoto
del que queramos recuperar cambios.
Esto sí que puede...
En las universidades
esto se ve bastante.
Entonces,
¿qué es lo que podemos hacer?
Pues le podemos añadir
otro remote.
Podemos decirle
git remote add
y ahora le decimos el alias.
¿Cuál es el alias
que tengamos
en nuestro nuevo repositorio remoto?
Pues le vamos a decir
upstream.
¿Por qué upstream?
Le podríamos llamar
from original,
le puedes llamar
como te dé la gana,
pero upstream
es como se le suele llamar
porque es como
la fuente de datos
de más arriba,
la fuente de la verdad
de tu fork.
¿De dónde has hecho el fork?
Pues del upstream.
Es como lo que hay más arriba.
Pondríamos el upstream
y ahora le tenemos que decir
cuál es la dirección
del upstream
del que queremos
recuperar los datos.
Para ello,
nos vamos al repositorio
de Google Chrome
y aquí
tenemos este git
arroba no sé quién
o cuánto.
Pues nos copiamos este ssh
y lo ponemos aquí.
Le damos al enter
y ahora
si hacemos un git remote
menos v
podemos ver
que me he añadido
por un lado
tengo ahora
origin
y tengo también
upstream.
¿Ahora qué puedo hacer?
Pues es que
ahora puedo hacer
un montón de cosas
porque no solo puedo hacer
el tema del
git
fetch
de
origin
¿vale?
Puedo hacer un git
fetch de origin
sino que puedo hacer
un git fetch
también de upstream
y esto lo que va a hacer
es que me va a traer
también los cambios
¿ves?
Todas las ramas
que se han hecho
en el upstream.
Ahora soy capaz
de ver los dos repositorios
a la vez
así que una vez
que tienes esto
lo que puedes hacer
igual que puedes hacer
git pull origin
que el origin
es el repositorio remoto
al que nos referimos
podríamos hacer
un git pull upstream
de main
y con esto
nos podríamos traer
los cambios de main
en este caso
ya claro
lo he sincronizado antes
y por eso
no me traigo los cambios
pero haciendo esto
justo los pasos
que he hecho
ahora
cuando tú tengas
un fork
de una forma
tan sencilla
como esta
podrías estar
constantemente
sincronizando
el repositorio
que has forkado
con el original
que es justamente
lo que quieres
no sé si tengo
otro ejemplo
bueno
es que este sería
el ideal
pero bueno
esto es básicamente
lo que hay que hacer
y con esto
ya tendrías una forma
de sincronizar
los cambios
os he hecho aquí
un tutorial
de cómo
sincronizar
los cambios
en un momento
que espero
que os haya gustado
eso lo tenemos
en tu libro
pues claro
que sí
gebo beta
por eso me lo sabía
de memoria
porque lo había escrito
en el libro
¿qué es un fork?
decían
un fork
básicamente
es una bifurcación
de un repositorio
completo
¿vale?
no es una rama
es más allá
es básicamente
que hemos
un repositorio
remoto
lo hemos clonado
y hemos hecho
una bifurcación
completa
el libro sale
el lunes que viene
no nos llega
al preestreno
sí que llega
hombre
la terminal
se llama
item 2
oye
a ver
que esto
ha suena un montón
muchas gracias
gracias
gracias
gracias