Mistake on this page?
Report an issue in GitHub or email us

Version control

You can use the Arm Mbed Online Compiler's version control features to let you version, branch and merge code. It will show a nice representation of the state of your project history:

The Online Compiler shows the current version of your project and your project's history

The approach should be familiar to those of you with experience of distributed version control models (as used by Mercurial and Git). Each program and library has its own local repository, so you can commit and perform actions on it within your own workspace (such as switching, branching and showing changes).

The main things you can do with a local repository are:

  • Commit a version of your project, and view the revision history.
  • View changes a version contains, and compare changes between versions.
  • Switch and revert to a different version.
  • Branch and merge versions.

Tip: You can also collaborate with others using version control: fork, push, pull, send pull request. These are covered in the Collaboration page.

Video tutorial

Here is the video that shows how you get started:

Video tutorialWatch how to use the Online Compiler's version control features

Working with version control

Your program is the working copy. You can commit changes to its local repository to create new revisions.

You can choose to switch to a particular revision, which updates your working copy to that revision (for example, revert to a past state of your program). This is the way you can branch: do some commits, switch to a previous revision, do some more commits; you now have two branches of development derived from a common revision.

You can then merge a revision, often the head of one branch, into your working copy. This creates a working copy that is the combination of these two branches.

There is also the option to discard your working copy, and revert your working copy to a particular revision; unlike switch, this creates a working copy with the changes you need to get back to that previous state - more an "undo" than a branch.

You can see the changes between your current working copy and the previous revision, and changes between revisions:

The File changes section shows differences between this revision and the previous one

Subrepositories and synchronization

Programs and libraries can depend on other published code to deliver a functionality. These dependencies are stored in reference files (such as name.lib) that are present in the codebase of the repository; when you import the codebase, the Mbed Online Compiler follows these references and imports other subrepositories, including referenced sub-subrepositories.

This synchronization mechanism ensures that the imported repository and all its subrepositories will be restored to the exact state they were when the author committed the changes to the parent repository (usually a program) and published it. This also makes it easy for everyone to use the code without worrying about dependencies, imports, revisions numbers and so on.

To ensure that a repository can be imported successfully, you must:

  • Publish all subrepositories (even sub-subrepositories) on os.mbed.com.
  • Leave no uncommitted or unpublished changes in any subrepository.

Pull requests

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

Tutorial

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.

Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.