Github Standards

Owned by Christopher Chung
Last updated: yesterday at 06:58 by Derek TangVersion comment
1 min read

Intro

This document aims to outline the conventions that will be followed for creating branches and cutting releases in the ZeroPilot repository. By having a standard, both what is happening in the repository and what the current state of the project is can be better understood, especially at a quick glance.

Branch Naming Convention

Feature branches will be named in the format of <change_type>/<project_name>/<name>. See the tables below for options and when they are appropriate.

Change Types

Change Types

bug

Minor shortcomings of existing functionality is being fixed with the branch

chore

Code refactoring and cleanup is being done with the branch

feature

New functionality is being added with the branch

Project Name

Project Name

am

Branch involves work with Attitude Manager

pm

Branch involves work with Path Manager

sm

Branch involves work with System Manager

tm

Branch involves work with Telemetry Manager

driver

Branch involves work with drivers

infra

Branch involves work with development tools (readme, ci/cd, etc.)

The name field can be whatever you feel sufficiently describes your work.

Example branch names below:

  • bug/driver/rc-nullptr-deref

  • chore/tm/remove-old-vars

  • feature/sm/rc-passthrough

Release Cutting Convention

The ZeroPilot repository will have 3 different types of branches: main, release, and feature. Their interactions are displayed in the diagram below.

Release branches will be named in the format of release/m<milestone>, for example release/m1.

Certain commits on the release branches will be tagged with versions, and these tags will be named in the format of v<milestone>.<minor>.<patch>, for example v1.0.0.

The initial tag will reference a commit on main, specifically the commit where the release branch in question spawns from, and it will be of the form v<milestone>.0.0. Subsequent tags will be used when bug fixes or minor functionality improvements are cherry picked in from main.

The idea behind this branching convention is that one milestone can be tested and refined while the next is being developed in parallel.

  • releases can be cut from any commit on main

  • features, even those unrelated to the current release in testing, can be continuously merged into main

  • changes relevant to the current release in testing can be selectively added into the release branch

    • make changes on a feature or bug fix branch

    • merge said branch into the main branch

    • cherry-pick commit(s) from the main branch into the release branch

    • add new tags where necessary on cherry-picked commits