You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
65 lines
2.7 KiB
65 lines
2.7 KiB
.. _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.
|
|
|