Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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 linked in the #s_data-controls channel, or on this page for some basic setup

Overview

Note these will take effect for any 22A development

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

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.

Commits

Only add the files you meant to change to the staging area

  • 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

Try group commits by logical groups of changes

  • 1 commit, 1 purpose

  • Try to avoid single-line commits or overly small commits

  • Also try to avoid overly large commits that encompass a large amount of changes

  • Commits can be squashed together and renamed via an interactive rebase, but only in develop branches

Make commit descriptions actually descriptive of what was actually done

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

Make sure you commit to the correct branch

  • 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

Branches

main should be treated like a final failsafe

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

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

develop/* should be treated as “main”s for respective development efforts

  • The name given to the develop branch should be indicative of the effort

  • Commits on develop branches should not be squashed, but should be rebased onto main

Branches should be dynamically made per ticket/fix

  • Please prefix the branch with the ticket number followed by a very brief descriptor of what it is

    • i.e. 99-charger-leds, not making-charging-leds-change-based-on-soc

  • Commits on smaller branches for tickets/fixes should be squashed as much as is needed

  • Any formatting commits should be squashed into a feature commit unless that is the point of the ticket

  • These branches should be merged into develop branches

  • These branches should NOT be merged directly into main unless we are undergoing a crisis

  • No labels