GitHub keeps your code safe, organized, and shareable. One mistake won’t wipe your autonomous. One teammate won’t overwrite another’s work. And when competition day arrives, you know exactly which version is on the robot.
● Why It Matters
What GitHub Helps Us Do
Five problems GitHub solves for every VRC team — before you even write your first autonomous.
⚙️
Save Every Version
Every time you commit, GitHub saves a snapshot. If something breaks, you can roll back to any working version in seconds — not hours.
👥
Organize Team Code
Multiple engineers can work without overwriting each other. Branches keep experimental code separate from the stable competition build.
🔗
Share Templates
Clone the Spartan starter repo and you have a working EZ Template project immediately — no manual setup, no missing files.
📊
Track What Changed
The commit log shows who changed what and when. When the robot suddenly drives differently, you can trace it to an exact edit.
🏆
Prepare for Competition
Tag a tested, verified build as your competition release. Everyone on the team downloads the same code from the same place — no USB confusion.
📚
New to Git? Start with the Git & Version Control guide first. It covers the four commands you actually need and how to set up VS Code with GitHub in one session.
1 of 4
💾 Official Resource
Spartan Starter Repo
A ready-to-upload PROS + EZ Template project. Clone it once, use it all season.
★ Spartan Design — Official Template
Spartan Competition Template
PROS 4 · EZ Template · Competition-ready structure
What’s Inside
📡
Brain Download Setup
Pre-wired auton selector, match-phase hooks, and competition switch handling.
⚙️
EZ Template Config
Drive and turn PID defaults, motor port map, and IMU setup ready to edit.
📄
Organized File Structure
Subsystem files separated from main.cpp. Easy to find, easy to hand off.
📝
README + Port Map
Document motor assignments, sensor ports, and config decisions as you go.
🏁
Match-Safe Defaults
Disabled state, autonomous state, and driver control are all separate and clean.
👤
Who It’s For
Any engineer starting a season build or rebuilding after a major mechanism change.
✎
GitHub link goes here. Replace this notice with the actual repo URL when it is published. Example: github.com/spartandesign/competition-template
# In a terminal — replace URL with the real repo link when publishedgitclonehttps://github.com/spartandesign/competition-template.gitcd competition-template
# Open in VS Codecode .
✅
First time? If you have never used Git before, complete the Git & Version Control guide first. It walks through installing Git, authenticating with GitHub, and cloning a repo step by step.
2 of 4
▶ Step by Step
Student Workflows
What you actually do — at practice, and on competition day.
Practice Session Workflow
Follow this sequence every time you sit down to code. Takes under two minutes and prevents most common problems.
1
Pull the latest code
Run git pull before you touch anything. You want the most recent working version, not what was on your laptop last week.
2
Open in VS Code — check the port map
Open the project folder. Verify motor ports match the robot in front of you before uploading anything.
3
Test controller mapping Verify
Upload to the Brain. Drive the robot with no field elements nearby. Confirm all buttons do what you expect.
4
Test the autonomous
Select an auton on the Brain screen and run it. Does it match what the code says it should do? If not, fix it before moving on.
5
Make your changes
Edit the code. One thing at a time. Test after each change — don’t stack three edits and then wonder which one broke it.
6
Commit and push when it works Log
Once the robot behaves correctly, commit with a clear message: git commit -m "tuned turn PID kP 0.8 → 0.9, auton more consistent" then git push.
Competition Day Workflow
The morning of an event is not the time to experiment. This sequence keeps the robot predictable and the team calm.
1
Confirm you are on the tested version Critical
Run git log --oneline -5. Is the commit at the top the one you tested last practice? If not, check out the right tag: git checkout competition-v1.
2
Verify motor and sensor ports Verify
Open robot-config.cpp and check every port number against the physical robot. One wrong port and your auton won’t run.
3
Upload and test drive control
Upload. Drive around. Does it feel like it did at practice? Any changes to the robot since last test should be noted and re-verified.
4
Test the auton selector Verify
Cycle through every auton option on the Brain screen. Confirm the names match what you planned to run and the routines fire correctly.
5
Run the pre-check protocol
Complete the Robot Pre-Check before queuing. Every item on that list exists because a team learned it the hard way.
6
Log what changed after each match Log
If the engineer makes any fix between matches, commit it immediately with a time-stamped message. You need to know exactly what was on the robot for each match.
⚠️
No untested code at events. If you make a change at an event, you must test it before queuing — even if it feels like a small fix. “It’ll probably be fine” is how teams miss the auton phase.
3 of 4
🚫 Safe Code Rules
Rules & What’s Coming
Six rules that keep the team’s code stable and predictable. Breaking these is how robots stop working the morning of a competition.
🚫
No untested changes before a match
If you haven’t run it on the robot and confirmed it works, it doesn’t go on the competition build. Period.
🏷️
Name versions clearly
Use meaningful commit messages and tags. competition-v2-tested is useful. final_FINAL3 is not.
📝
Document every change
In your commit message: what you changed, why you changed it, and what result you expected. Future-you will be grateful.
🎮
Keep controls consistent
Don’t remap driver buttons without telling the driver and getting practice time. Muscle memory matters at competition.
⚡
Confirm ports before every upload
Motor and sensor port numbers must match the physical robot. A wrong port silently breaks the auton — you won’t know until it matters most.
🔄
Re-test after every change
A change that “only touches the intake” can still break PID behavior, timing, or auton selector logic. Test the whole robot, not just the part you edited.
📚
For coaches: These rules are most useful when your team treats them as a checklist, not a suggestion. Consider printing them and posting them above the pit laptop for the first few competitions.
What Is Coming to This Repo
These example branches and utilities are planned for the Spartan GitHub. Check back as the season progresses.
Annotated route examples for Push Back. Start here, copy, adapt.
Coming Soon
🔬
Debug Tools
Brain screen telemetry, live PID output display, motor temp logger.
Coming Soon
⛳
Practice Utilities
Skills timer, driver session tracker, match simulation scaffold.
Coming Soon
✎
Coach note: Update this section as each branch is published. Replace the “Coming Soon” badges with actual GitHub links. Search for coming-badge in this file to find them quickly.
Ready to set up Git?
The Version Control guide walks through the full setup in one session.
⚙ STEM HighlightComputer Science: Distributed Version Control & Branch Models
Git applies distributed version control — a system where every team member has a complete copy of the project history. The branch model creates isolated development environments: each feature or fix lives on its own branch. The main branch is protected as the always-deployable state. This mirrors the software engineering workflow used at every professional development organization.
🎤 Interview line: “We follow a professional Git workflow: feature branches, code review before merging to main, and competition tags that freeze the tested codebase. When a teammate broke auton the night before a competition, we reverted to the last tagged release in 30 seconds. Without version control, that failure would have cost us the entire event.”
You commit directly to main the night before a competition and accidentally break the autonomous. What workflow would have prevented this?
⬛ Using git stash to save uncommitted changes before testing
⬛ Working on a feature branch and only merging to main after testing — main should always hold tested competition-ready code
⬛ Committing more frequently so individual commits are smaller