This section describes the general procedures involved in the development process. 

Prerequisites

This section assumes that a developer has:

• Gotten ONOS source, as described in Getting Started
• Set up their development environment, as described in Development Environment Setup
• Set up their test environment, as described inTest Environment Setup

A developer should also be relatively comfortable with the shell. 

Git

The version control system used by the project is git. Using git provides a developer with a way to cleanly keep track of and organize their changes, in addition to the ability (among many others) to view and reapply changes made to the code at various points in time. Importantly, git meshes in a way conducive to the ONOS code submission/review process; therefore, it is important for a potential contributor to be fairly comfortable with using it. Those interested in familiarizing themselves with git may find many resources online, including a fully online book. 

As git is extremely rich in features, only the relevant functions will be mentioned where they are needed.

The Walkthrough

1. Create and switch to a new branch. A branch is a divergence point from the existing code base. Any changes made in a branch are restricted to the branch.

   $ cd $ONOS_ROOT $ git checkout -b myBranch Switched to a new branch 'myBranch'

   this creates a new branch named 'myBranch', off of the previous branch that we were in. This command will fail if there was already a branch of the same name. The command git branch can be used to list all of the branches to check that the name isn't already used. If a branch with the desired name is no longer needed, it may be deleted and the above commands repeated to re-create a new branch. 

   $ git branch -D myBranch Deleted branch myBranch (was 60a190b). $ git checkout -b myBranch Switched to a new branch 'myBranch'

2. Make changes to the code. This can be done in any way - IDE, text editor, whatnot.
3. Commit the changes. Any changes made to the code aren't finalized until they are committed. Committing creates a snapshot of the code that may be revisited later, but only in the branch where the code was committed. 
4. Pull upstream changes.
5. Sync the branch with updated master.
6. Submit code for review.