Lưu ý: nếu chúng ta đang thực sự nói chuyện về forking (mà là hành vi nhân bản một repo trên máy chủ bên) và nhân bản không đơn giản, sau đó giản đồ là:
BitBucket
------------[P]-----------
| ^ |
| | |
(forked) (pull request) (forked)
| |
v v
[M] [C]
| |
----|------------------------|-----
| Local workstations |
| |
(git clone) (git clone)
| |
v v
[MLocal] [CLocal]
Nói cách khác, M và C có trên các máy chủ BitBucket, không phải trên Muser và Cuser máy trạm cục bộ.
'origin' sẽ là số upstream repo tương ứng của MLocal và CLocal, đó là M hoặc C, không P.
(Xem "What is the difference between origin and upstream", cho GitHub, mà còn áp dụng cho BitBucket)
này rất hữu ích cho Muser vì:
Muser có thể không muốn đẩy trực tiếp đến P (ông có thể, mặc dù ông là chủ sở hữu của P trên BitBucket), do đó ở đây, repo M hoạt động như ông "đệm"Cuser không có quyền để đẩy trên P, vì vậy ông phải đến ngã ba cũng
Trong trường hợp đó, cho Cuser thấy bất kỳ bản cập nhật trên P, anh ta cần phải thêm P như một điều khiển từ xa để CLocal repo (tức là nhân bản repo địa phương của mình ngã ba ông)
git remote add P https://bitbucket.org/Puser/P
git pull P master
Một khi những thay đổi mới được tích hợp và được thử nghiệm tại địa phương (trên CLocal), chúng có thể được đẩy trở lại C, cùng với các diễn biến mới được giới thiệu bởi Cuser. Chỉ những thay đổi mới sẽ là một phần của một pull request, cho Muser (và P chủ sở hữu) để kiểm tra và thêm vào P.
Tương tự, Muser sẽ cần phải thêm P như một điều khiển từ xa để MLocal, để có được trở lại bất kỳ sửa đổi từ C đã được chấp nhận vào P.