The Arm Mbed Online Compiler offers collaboration and version control functions to help the community benefit from and improve individual work.
Remote repository: A library or program published on
Local repository: A library or program in your private workspace.
Commit: Create a checkpoint within your program's local repository. This does not publish or make it public.
Pull: Copy changes from a remote repository to a local repository in your workspace.
Push: Copy changes from a local repository to a remote one.
Fork: Create a remote repository on
mbed.org from an imported local repository (that may also contain local changes and modifications). The fork is created under your profile.
Publish: Copy changes from a local repository to an existing remote one (push) or create a new one (fork).
Update: Pull from a remote repository and switch your local repository to the latest revision.
The most basic (and the most popular) usage of the collaboration system is the traditional workflow in which one author develops a project, then multiple users import and use it.
Many developers can use code that one author wrote
When you import a repository, you are making a clone of a public repository in your private workspace. An imported repository can either be a whole program or a library for a program, and can contain dependencies to other repositories. For example, a library may need another library in order to work. All dependencies will be imported for you automatically when you import a repository.
Once imported, the local repository in your workspace will be
linked to the remote repository by URL to let you check its status, receive new changes and even contribute code to it.
To import a repository, simply click the Import link on the repository's page on the Arm Mbed website, or use the Import button within the Mbed Online Compiler.
While browsing a program or a library, you will receive notifications of new versions in the Browser panel under the Summary tab:
Viewing the program description
It is also possible to view detailed information about the new changes in the Revisions panel. The top list represents the local repository revisions, where revision numbers marked in green are outgoing revisions, currently not present in the remote repository:
The Revisions panel highlights local changes that are not yet in the remote repository
The bottom list represents the remote repository revisions currently not present in your local repository. Just like with local revisions, you can click on revisions in the remote list to see change sets and individual changes per file.
Viewing remote revisions not yet in your local repository
To get the latest version of the code, simply click the Update button.
A pull request lets you tell others about changes you've added to a fork of their (or ancestor) repository, effectively granting them permission to include and use your code in their codebase. Once the pull request is created, the other party can review, accept or reject the set of changes, discuss further modifications and even add follow-up changes or merges.
Think of pull requests as a simplified fork and update workflow, where the repository author(s) moderate the changes nonrepository developers contribute.
Day to day usage
An important thing to know about pull requests is that they can only exist between related repositories. The term "related repositories" means that either repository is ancestor or sibling to the other through direct or indirect relationship (like a fork of the fork of the fork). Pull requests usually originate from a forked repository to ancestor repository, though the functionality is flexible and allows pull requests from ancestor repository to a forked repository (for cases where the original author wants to contribute later added code to a fork).
For more information about using pull requests on the Online Compiler, please see our tutorial, which covers creating and editing a pull request, viewing a pull request and accepting or rejecting a pull request.