No entiendo horking

Question

Acabamos de configurar un proyecto con bitbucket. Colocamos nuestro código de 'producción' [P] en ​​un repositorio, y luego creamos un tenedor [m], y luego mi compañero de trabajo [C] también creó un tenedor de él.

[P] 
/ \ 
[M] [C] 

he hecho algunos cambios, y ha creado una solicitud de extracción y la ha aceptado, por lo que [P] ahora tiene mi código, [M].

Aquí es donde estoy confundido. ¿Cómo [C], mis compañeros de trabajo repo obtienen el código actualizado?

Gracias!

Answer 1

Su compañero de trabajo tiene que tirar de P.

Si está trabajando en la rama master en P, entonces el comando sería ...

git pull origin master 

Answer 2

Nota: si en realidad estamos hablando sobre forking (que es el acto de la clonación de un repo en el lado servidor) y la clonación no simple, a continuación, el esquema es:

   BitBucket 

    ------------[P]----------- 
    |   ^   | 
    |   |   | 
(forked) (pull request) (forked) 
    |      | 
    v      v 
    [M]      [C] 
    |      | 
----|------------------------|----- 
    | Local workstations | 
    |      | 
(git clone)    (git clone) 
    |      | 
    v      v 
[MLocal]     [CLocal] 

En otras palabras, M y C están en los servidores BitBucket, no en las estaciones de trabajo locales Muser y Cuser.
'origin' sería su respectivo upstream repo de MLocal y CLocal, es decir M o C, no P.
(Ver "What is the difference between origin and upstream", por GitHub, pero se aplica también para BitBucket)

Esto es útil para Muser porque:

• Muser podría no querer empujar directamente a P (que podría, sin embargo, que es el propietario de P en BitBucket), por lo que aquí, repo M actúa como su "buffer"
• Cuser no tiene derecho a seguir adelante P, por lo que debe a la mesa, así

En ese caso, por Cuser para ver las actualizaciones en P, tiene que añadir P como un control remoto para CLocal cesión temporal (es decir, su clonado repo locales de su tenedor)

git remote add P https://bitbucket.org/Puser/P 
git pull P master 

Una vez que los nuevos cambios son integrados y probado localmente (en CLocal), pueden ser devueltos a C, junto con las nuevas evoluciones introducidas por Cuser. Sólo esas nuevas modificaciones serán parte de un pull request, por Muser (y P propietario) para examinar y añadir a P.

Del mismo modo, Muser tendría que añadir P como un control remoto para MLocal, con el fin de volver cualquier modificación de C que fueron aceptados en P.