When you work with another user's public Bitbucket repo, typically you have read access to the code but not write access. This means that you can use a clone command to copy the repo but you cannot push changes to it. Instead, you use the Bitbucket interface to fork a repo. Bitbucket hosts private or public repos. Anyone can fork a public repo. You can fork a private repo where you have permissions.

Forking a repository creates a new repository under your account. This new repository is a copy of the original repo and is called a fork. Even though you have a fork, you can still get a change into the original repository, to do this you:

• clone the forked repo from Bitbucket to your local system
• make changes to the local repo
• push the changes to your fork on Bitbucket
• issue a pull request against the hosted repo you forked from
• wait for the repo owner to accept or reject your pull request

If a repo owner accepts a pull request, Bitbucket pulls your code changes into the original repo and merges them. Bitbucket recommends you work with forks and pull requests even if the repo owner gives you write access to a public repository. While a pull is a DVCS concept, "pull requests" and forks are concepts used only by repository hosting services - like Bitbucket and GitHub. You won't find fork and pull requests in any Git or Mercurial workflow that doesn't involve a repository hosting service.