Branching Strategy

ZeroPilot3.5 will use a something similar to a 3 flow branching strategy. A Branching Strategy Simpler than GitFlow: Three-Flow

Open

Development

This includes features, bug fixes, etc for all system components (drivers, managers, infra, etc). For regular development, a branch will be made for each feature from the main branch. When the feature has been unit tested and manual tested as much as it can be (without a flight test), a PR will be made and reviewed. Once the reviewers give approval, the branch will squashed and merged into the main branch. Every feature should have it’s own branch. Bug fixes can be grouped up as long as they are all related to the same bug/component. Each branch should ideally update only a single component (a Manager branch should not modify a driver, for example).

Flight Tests

For flight tests and integration testing, a release candidate will be made. Each flight test/integration test should correspond with a milestone.

If the test is successful, the commit is tagged (with the milestone number) and the release candidate branch will be removed.

If the tests are not successful, bug fixes can be done in the candidate branch, and merged into main once the test is successful. The commit should then be tagged, and the candidate branch can be closed.