-
Notifications
You must be signed in to change notification settings - Fork 8
Git Standards
This document contains the standards for Git that all software members, across all teams are expected to follow.
This section encompasses standards around branches, including naming, creation, and more.
If you are on a team that doesn’t have its own repository (all teams except Mission Control and Motherboard), then you should almost never branch directly off main/master. Instead, branch from your team’s branch, which is usually named the same as your team. For example, if you’re on autonomous, you’ll be branching off the branch calledautonomous-nav.
In rare cases, you may branch off main/master, but it will require express permission from the software lead.
Branch names should be formatted as all one word, lowercase, with the name of the branch you branched from prepended with a hyphen (-).
So, let’s say you’re on the autonomous team and branching from the autonomous-nav branch, and you’re adding a feature called makeeverythingwork. Your branches name would be:
autonomousnav-makeeverythingwork.
Additionally, if someone were to branch off your branch, they would call their branch:
autonomousnav-makeeverythingwork-part1.
This standard is different than what we’ve had in the past!
This section encompasses commit messages and pushing.
Commits should be named prefixed with your team and feature, wrapped in brackets. So following the example from before, an example commit message could be [autonomousnav][makeeverythingwork] add starter files. If things end up too verbose, your team can agree to abbreviate things.
You should push to your feature branches often. Ideally every time you make a change, no matter how small. This is to ensure that your team members are always looking at an up-to-date version of your branches. This helps speed things along significantly, and means less asking around has to happen.
This section encompasses pull requests and what method you should use to merge.
Every pull request should be reviewed by at least one other person on your team, preferably more. You can request someone to review in the pull request UI on GitHub.
GitHub provides 3 options to integrate changes from one branch into another branch,:
- Merge
- Rebase and merge
- Squash and merge
Never use “Rebase and merge” or “Squash and merge”.
In rare cases, you may use "Squash and merge" — but only if you're certain about what you're doing and confident that no one will branch from your branch.
99.9% of the time you should just use “Merge”.