|  | .. _code-flow-and-branches: | 
|  |  | 
|  | Code Flow and Branches | 
|  | ###################### | 
|  |  | 
|  | Introduction | 
|  | ************ | 
|  |  | 
|  | The zephyr Git repository has three types of branches: | 
|  |  | 
|  | main | 
|  | Which contains the latest state of development | 
|  |  | 
|  | collab-\* | 
|  | Collaboration branches that are used for shared development | 
|  | of new features to be introduced into the main branch when ready. Creating a new | 
|  | collaboration branch requires a justification and TSC approval. Collaboration branches | 
|  | shall be based off the main branch and any changes developed in the collab | 
|  | branch shall target the main development branch. For released versions of | 
|  | Zephyr, the introduction of fixes and new features, if approved by the TSC, | 
|  | shall be done using backport pull requests. | 
|  |  | 
|  | vx.y-branch | 
|  | Branches which track maintenance releases based on a major | 
|  | release | 
|  |  | 
|  | Development in collaboration branches before features go to mainline allows teams to | 
|  | work independently on a subsystem or a feature, improves efficiency and | 
|  | turnaround time, and encourages collaboration and streamlines communication | 
|  | between developers. | 
|  |  | 
|  | Changes submitted to a collaboration branch can evolve and improve | 
|  | incrementally in a branch, before they are submitted to the mainline tree for | 
|  | final integration. | 
|  |  | 
|  | By dedicating an isolated branch to complex features, it's | 
|  | possible to initiate in-depth discussions around new additions before | 
|  | integrating them into the official project. | 
|  |  | 
|  | Collaboration branches are ephemeral and shall be removed once the collaboration work | 
|  | has been completed. When a branch is requested, the proposal should include the | 
|  | following: | 
|  |  | 
|  | * Define exit criteria for merging the collaboration branch changes back into the main branch. | 
|  | * Define a timeline for the expected life cycle of the branch. It is | 
|  | recommended to select a Zephyr release to set the timeline. Extensions to | 
|  | this timeline requires TSC approval. | 
|  |  | 
|  | Roles and Responsibilities | 
|  | ************************** | 
|  |  | 
|  | Collaboration branch owners have the following responsibilities: | 
|  |  | 
|  | - Use the infrastructure and tools provided by the project (GitHub, Git) | 
|  | - All changes to collaboration branches shall come in form of github pull requests. | 
|  | - Force pushing a collaboration branch is only allowed when rebasing against the main branch. | 
|  | - Review changes coming from team members and request review from branch owners | 
|  | when submitting changes. | 
|  | - Keep the branch in sync with upstream and update on a regular basis. | 
|  | - Push changes frequently to upstream using the following methods: | 
|  |  | 
|  | - GitHub pull requests: for example, when reviews have not been done in the local | 
|  | branch (one-man branch). | 
|  | - Merge requests: When a set of changes has been done in a local branch and | 
|  | has been reviewed and tested in a collaboration branch. |