Firmware Git Standards

Owned by Nick DePatie
Last updated: Sep 03, 2024 by Dylan Donahue
2 min read

Everyone joining the team might not be super well versed with Git, so feel free to ask leadership what these mean or if you need help. Also refer to the Git 101 presentation on this page, or on this page for some basic setup

Overview

These rules are all voided if there is a feature blocking getting the car running or we are in crisis

These are a list of Git guidelines that team members should be held to when contributing to a codebase. Some are just general Git hygiene and others are specific good practices to follow for this team.

Resources

If you are new to git, the following may be helpful to have on you while you learn.

 

Commits

Commits will only contain relevant files/changes

  • There should be no build files, lingering Mac files, VSCode configuration files, etc

  • If you accidentally modified another file, make sure you verify that it was intentional before adding that change to the staging area

Commit descriptions will be descriptive of what was actually done

  • Please don’t make super short commit messages like fix

Commits will be made on the correct branches

  • Run git branch before you commit/push to verify you are working on the right branch

  • This avoids having to cherry-pick commits and such

  • If this mistake is made, try and correct it before it is pushed to remote

Branches

Develop will be treated as current, tested

  • The develop branch should be locked and only able to be changed by leadership

  • Commits on this branch will be linear

  • Please use develop instead of “master”, “main”, etc for naming the base branch

  • Releases, representing the latest stable and verified on-car code, and made from this branch

Branches will be dynamically made with feature/ or bug/ prefix

  • Categorize a single ticket into one of the two categories above, and follow the prefix with a short description

    • ie feature/lsm6dso-driver or bug/malloc-patch

  • These branches should be merged into develop branches via squash

    • Should be verified at least in software before merge

Releases will be made every time a pr is merged into develop (roughly)

  • Release naming conventions should follow major.minor.patch

    • i.e. 1.2.4

  • Releases should be fully working and contain an executable or a zip file of good, buildable source code

Pull Requests

Pull requests should be made whenever work for an issue/ticket is complete

They should follow the template provided upon creation

1 ticket == 1 branch == 1 PR

If relevant changes have been pushed into develop since the branch was made, the user should merge develop into their own PR