Github Standards - Team537/RobotCode2025 GitHub Wiki

Github Commit Standards

Commit Naming Conventions

We will be using the Semantic Commit Message naming convention. This standard involves writing commit messages in the following format:

<type> (optional scope): <description> 

[optional body]

[optional footers]

Commit Type

This portion of the commit messages broadly explain what the commit accomplished. Below is a list of all of the commit types that we will be using:

  • feat: Used for commits that add a new feature to the code.
  • fix: Used for commits that patch a bug.
  • docs: Changes to documentation or comments.
  • style: Used for commits that change how the code is formatted.
  • chore: Commits that solely change Gradle or GitHub specific files.
  • refactor: Used for commits that rework preexisting features.
  • pref: Refactors done specifically for the purpose of improving code performance.

Commit Scope (Optional)

This indicates what portion of the code is being changed. This may look something like the following example: feat(vision): add object tracking

Description

This part of the commit message should provide a brief summery of what the commit does. The description should be written in the present tense. This should look something like the following example:

feat: implement autonomous pathfinding

Breaking Changes

In the event that a commit contains breaking changes (changes that may break pre-existing code), you MUST place a exclamation mark after the commit type or, if included, the scope. This would look something like the following:

feat!: add new drivetrain object
An optional footer titled BREAKING CHANGE may be included. Including this would look something like this:
feat!: add new drivetrain object

BREAKING CHANGES: removed old drivetrain object

Further Reading

If you still have questions regarding our commit naming standards, please refer the this site for more information. Alternatively, you may message Cameron with any questions that you may have.

Branch Naming Conventions

To maintain consistency and clarity in our development process, we will adhere to the following branch naming conventions. These conventions help in easily identifying the purpose and status of a branch at a glance.

Branch Types

Each branch name should start with a type that indicates the nature of the work being done. Here are the types we will use: -feature/: For new features or enhancements. -bugfix/: For bug fixes. -hotfix/: For critical fixes that need to be addressed immediately. -docs/: For commits focusing primarily on writing or adjusting documentation. -text/: For commits that focus on testing code. These branches are non-permanent, and will be deleted at some point. -github/: For commits related specifically to GitHub workflows, actions, or repository-level integrations. -release/: Used solely for our weekly code release. For more information, see .

Branch Naming Format

The branch name should follow the format:

<type>/<short-description>

The branch name should be all lowercase, hyphen separated, and use only alphanumeric characters.

Examples

Here are some examples of branch names: -feature/object-detection-pipeline -bugfix/rotation-rounding-error -hotfix/driver-station-crash -docs/arm-stabalization -release/v1.0.0 By following these conventions, we ensure a more organized and efficient workflow, making it easier for team members to collaborate and manage the codebase effectively.

Further Reading

If you still have questions regarding our branch naming standards, please refer the this site for more information. Alternatively, you may message Cameron with any questions that you may have.

Versioning System

Our versioning system follows the Semantic Versioning specification, which helps in maintaining a clear and predictable release process. This system uses a three-part version number format: MAJOR.MINOR.PATCH. This system will be used whenever something is merged into the main branch.

Version Numbering

MAJOR: Incremented when there are incompatible API changes or significant updates that may break backward compatibility. MINOR: Incremented when functionality is added in a backward-compatible manner. PATCH: Incremented for backward-compatible bug fixes.

Versioning Format

The version number should be formatted as follows: v..

Examples

Here are some examples of version numbers: v2.0.0: Indicates a major release with breaking changes. v1.3.5: Represents a minor update with new features and some bug fixes. v1.2.1: A patch release addressing specific bugs without adding new features. By adhering to these versioning guidelines, we ensure that our releases are consistent and easy to track, facilitating smoother updates and maintenance.

Further Reading

If you still have questions regarding Semantic Versioning, please refer the this site for more information. Alternatively, you may message Cameron with any questions that you may have.

⚠️ **GitHub.com Fallback** ⚠️