Hinweis: Wenn wir reden eigentlich etwa forking (das ist die Handlung eines Repo auf dem Server Seiten Klonen) und nicht die einfache Klonierung, dann das Schema:
BitBucket
------------[P]-----------
| ^ |
| | |
(forked) (pull request) (forked)
| |
v v
[M] [C]
| |
----|------------------------|-----
| Local workstations |
| |
(git clone) (git clone)
| |
v v
[MLocal] [CLocal]
Mit anderen Worten, M und C sind auf den BitBucket-Servern, nicht auf Muser und Cuser lokalen Arbeitsstationen.
'origin' ihre jeweiligen upstream repo von MLocal wäre und CLocal, dh M oder C, nicht P.
(Siehe "What is the difference between origin and upstream", für GitHub, sondern gilt auch für BitBucket)
Diese für Muser nützlich ist, weil:
Muser vielleicht nicht direkt an P schieben will (er allerdings konnte, ist er der Besitzer P auf BitBucket), so hier, Repo M wirkt als seine „Puffer“Cuser hat kein Recht auf P schieben, so muss er auch
Gabel
In diesem Fall für Cuser auf P keine Updates um zu sehen, muss er P als Remote zu CLocal Repo (dh seine geklonten lokalen Repo seiner Gabel)
git remote add P https://bitbucket.org/Puser/P
git pull P master
hinzufügen Sobald diese neuen Änderungen integriert sind und lokal getestet (auf CLocal), können sie zusammen mit neuen Entwicklungen, die durch Cuser eingeführt werden, zurück auf geschoben werden. Nur die neuen Änderungen Teil eines pull request sein wird, für Muser (und P Inhaber) P.
Ähnlich zu untersuchen und fügen würde Muser müssen P als Fernbedienung MLocal hinzuzufügen, um alle Änderungen zurück zu bekommen von C, die in P akzeptiert wurden.