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