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].

  • BFG which repo to use after successful run
  • Why do I sometimes get `lock': deadlock detected (fatal) error?
  • Bitbucket: git push error: pack-objects died of signal 13
  • Your configuration specifies to merge with the <branch name> from the remote, but no such ref was fetched.?
  • Can I make TortoiseGit remember by password? (using multiple BitBucket accounts)
  • I need to checkout single folder from a Bitbucket Git repo
  • Here is where I am confused. How does [C], my coworkers repo get the updated code?


  • Using a post-receive hook to create a zip
  • Internal Server Error no matter what I push to heroku app (Ruby on Rails)
  • Gitignore all folders beginning with a period
  • Can I work on github with opened source code on commercial project and how?
  • Uploading new files to a git repository directly through the github web application
  • How to clone a remote git repository with Android Studio?
  • 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.