Don't understand forking

We just set up a project with bitbucket. We put our ‘production'[P] code on a repo, and then i created a fork[m] of it, and then my co-worker[C] also created a fork of it.

   /   \
 [M]   [C]

I made some changes, and created a pull request and accepted it, so [P] now has my code, [M].

  • Bitbucket fails to authenticate on git pull
  • Libcurl.dll error with Git push
  • Download a Git repo from BitBucket
  • Complex setup for GIT: fork from Github to Bitbucket, PUSH to Bitbucket only
  • Can I hg clone a git repository from BitBucket?
  • Advantages of GitHub over Bitbucket for Git Repositories
  • Here is where I am confused. How does [C], my coworkers repo get the updated code?


  • Git commit against tag with no branch
  • Using Git to track mysql schema - some questions
  • What's the difference between “squash” and “fixup” in Git/Git Extension?
  • Bonobo Git Server - HTTP Error 500.19 - Code: 0x80070021
  • No such file: ‘pom.xml’ error in jenkins
  • Does Git Bash determine identify by ssh key?
  • 2 Solutions collect form web for “Don't understand forking”

    Your coworker needs to pull from P.

    If you’re working on the master branch in P, then the command would be…

    git pull origin master

    Note: if we are actually talking about forking (which is the act of cloning a repo on the server side) and not simple cloning, then the schema is:

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

    In other words, M and C are on the BitBucket servers, not on Muser and Cuser local workstations.
    origin‘ would be their respective upstream repo of MLocal and CLocal, that is M or C, not P.
    (See “What is the difference between origin and upstream”, for GitHub, but applies also for BitBucket)

    This is useful for Muser because:

    • Muser might not want to push directly to P (he could though, he is the owner of P on BitBucket), so here, repo M acts as his “buffer”
    • Cuser has no right to push on P, so he must to fork as well

    In that case, for Cuser to see any updates on P, he needs to add P as a remote to CLocal repo (ie his cloned local repo of his fork)

    git remote add P
    git pull P master

    Once those new changes are integrated and tested locally (on CLocal), they can be pushed back to C, along with new evolutions introduced by Cuser. Only those new modifications will be part of a pull request, for Muser (and P owner) to examine and add to P.

    Similarly, Muser would need to add P as a remote to MLocal, in order to get back any modifications from C that were accepted into P.

    Git Baby is a git and github fan, let's start git clone.