Team 5171 Git & GitHub Guide

Team 5171 Git & GitHub Guide

Hello everyone! To keep our robot code organized, stop losing changes, and avoid the chaos, we’re standardizing our Git workflow this season.

---

1. Commits

Don’t wait until cleanup to make one giant commit that says “updated intake, fixed drive, stuff works”.

• Commit as soon as you finish a single name-able change.
• It’s totally fine if your code doesn’t build yet on your feature branch. Commits are your personal undo buttons. If an idea doesn’t pan out, granular commits let you roll back 15 minutes instead of starting over.

Commit Messages (Conventional Commits)

We use Conventional Commits: <type>: <short summary in present tense>.

Types

• feat: A new feature (ex., feat: add photonvision target tracking)
• fix: A bug fix (ex., fix: invert right elevator motor direction)
• chore: Repo/code maintenance or vendordep updates (ex., chore: update revlib to 2026.1.1)
• refactor: Rewriting code without changing functionality (ex., refactor: clean up swerve kinematics math)
• test: Adding autonomous routines or unit tests (ex., test: add 3-piece auto path)
• docs: Updating readmes or comments (ex., docs: add wiring diagram for can bus)

Tip: You can also add a specific descriptor to a type, like “chore(vendordeps)” or fix(intake).

Driver Laptop Rule (@yorkrobotics account):

If you’re on a shared team laptop signed into yorkrobotics, put your github username with an @ in the commit message or description so we know who wrote what:

feat(intake): tune beam break sensor threshold [@coder11v]

---

2. Branches

Branches are

1. main (Protected)
   • Rule: Must always build and be battle-tested. This is what gets deployed to the robot on the field at competitions and during driver practice.
   • Direct pushes are blocked; code only enters via Pull Requests.
2. develop
   • Rule: Must build, but can include experimental code actively being integrated.
   • This is where feature branches merge together before competition testing.
3. feat/ (Feature Branches)
   • Rule: Your sandbox. It can be broken, messy, and mid-experiment.
   • Name your branch after what you’re working on: feat/intake-indexer, fix/gyro-drift, test/auto-dock.

---

3. Daily Workflow

Starting something new:

  git checkout develop
  git pull origin develop
  git checkout -b feat/shooter-pid

While working:

  git add .
  git commit -m "feat: add velocity pid controller for flywheel"
  git push -u origin feat/shooter-pid

When your feature is done and working:

1. Open a Pull Request (PR) on GitHub targeting develop.
2. (optional but recommended) Have another programmer or mentor review the code.
3. Once CI passes (it builds!) and it’s approved, merge it into develop.

---

4. Releases & Tags

For milestone builds we will tag official releases on main (like v1.0.0, v1.1.0). If something goes wrong during a match, we can roll back to a known winning build in seconds. This uses Semantic Versioning, which is = MAJOR.MINOR.PATCH.

Questions:

ask anyone