Git & Version Control

// Section 01

Why Your Team Needs Git

Git tracks every change to your code over time. If something breaks, you can see exactly what changed and roll back to any previous version. It also lets multiple team members work on code without overwriting each other.

🚫

Real scenario — happens every season: two days before a major qualifier, a teammate is “cleaning up” the autonomous code and accidentally deletes the working AWP routine. They save. They close VS Code. They go home. The next day, no one can remember what the working code looked like. Without git, that autonomous is gone. With git, it is recovered in 30 seconds.

Three Things Git Does for a VRC Team

Complete history — every time you commit, git saves a snapshot of your entire project. You can go back to any previous state, instantly.
Safe experimentation — create a branch to try risky changes (new PID values, new autonomous, new mechanism code). If it breaks, delete the branch. Main code is untouched.
Backup and sharing — push to GitHub and your code is safe on the cloud. Any teammate can pull the latest version. No more emailing zip files or copying to a USB drive.

★

Git is a real engineering skill. Every software company in the world uses git or a similar version control system. Learning it during VRC puts students years ahead when they reach college computer science courses and internships.

1 / 4

// Section 02

Setting Up Git for Your PROS Project

One-time setup per project. Takes about 10 minutes. After this, version control is part of your normal workflow.

Step 1 — Install Git and Create a GitHub Account

Download Git from git-scm.com (free, all platforms)
Create a free account at github.com
In VS Code, sign in to GitHub via the Accounts menu (bottom-left)

Step 2 — Initialize a Repository in Your PROS Project

Open the VS Code terminal (Ctrl+`) inside your PROS project folder:

git init # create a new repo in this folder git add . # stage all current files git commit -m "Initial commit" # save the first snapshot

Step 3 — Push to GitHub

Create a new repository on github.com (click the + button, name it something like team2822-2025), then connect and push:

git remote add origin https://github.com/YOURNAME/team2822-2025.git git push -u origin main

Your code is now on GitHub. Any team member can clone it to their laptop.

Step 4 — Add a .gitignore

PROS projects generate compiled binary files that should not be tracked. Create a file named .gitignore in your project root:

# .gitignore for PROS projects bin/ .cache/ *.pros firmware/ # add any other generated folders your project creates

✅

VS Code has a built-in git interface. Click the branch icon in the left sidebar (the one that looks like a fork). You can stage, commit, and push without using the terminal once you are set up. Useful for teammates who are not comfortable with command line.

2 / 4

// Section 03

Daily Workflow — The Four Commands You Need

You do not need to know every git feature. These four commands cover 95% of what a VRC team uses.

The Four Essential Commands

# 1. See what has changed since your last commit git status # 2. Stage all changed files for the next commit git add . # 3. Save a snapshot with a description git commit -m "Fix intake reverse direction, tune PID kP to 4.2" # 4. Push to GitHub (backup + share with teammates) git push

The VRC Commit Rhythm

After every practice session — commit what changed. Message should be specific: "Tune drive PID, add AWP routine for left side" not "update".
Before every competition — commit the version going to the event. Tag it: git tag qualifier-1. Now you can always return to exactly what you ran at that event.
Before trying risky changes — commit the working version first. If the risky change breaks things, git checkout . discards all changes and returns you to the last commit.

⚠️

Write useful commit messages. “Fix bug” tells you nothing six weeks later. “Fix intake reversing on startup — was missing motor brake mode init” tells you exactly what happened and why. Good commit messages are also notebook documentation evidence.

Emergency Recovery — Undoing Changes

# Discard ALL unsaved changes since last commit (nuclear option) git checkout . # See the history of commits git log --oneline a3f2b1c Fix intake reverse direction 8d9e4a2 Add AWP routine left side f2c7b3e Initial competition code # Go back to a specific commit (by its hash) # Creates a new branch at that point — safe, does not delete history git checkout f2c7b3e # Pull teammate's changes from GitHub git pull

3 / 4

// Section 04

Branches — Safe Experimentation

A branch is an isolated copy of your code where you can experiment freely. If it works, merge it in. If it breaks, delete it. Main is always safe.

The VRC Branch Strategy

Keep it simple: two branch types are enough for most VRC teams.

main — the competition-ready code. Only merge into main when something is tested and working. This is what gets uploaded the morning of a competition.
feature branches — created for any risky experiment. Named after what you are trying: new-auton-right, arm-pid-tuning, cheesy-drive-test.

# Create a branch for a risky experiment git checkout -b arm-pid-tuning # Now you are on branch "arm-pid-tuning" # Make all your changes — main is completely unaffected # See all branches git branch * arm-pid-tuning main # Switch back to main (your working code) git checkout main # If the experiment worked — merge it into main git merge arm-pid-tuning # If the experiment failed — delete the branch, nothing changed on main git branch -d arm-pid-tuning

Pre-Competition Branch Protocol

Create a competition branch the day before: git checkout -b qualifier-2-feb15
Lock it down — no experimental changes on this branch. Only the code that is going to the field.
Tag the commit before leaving for the event: git tag -a q2 -m "Qualifier 2 competition code"
Push everything: git push --tags
At competition, if you need to make a quick fix, commit it on the competition branch and note what changed in the message.

🏆

GitHub Desktop is a free app that gives you a visual interface for all of this — no terminal required. Recommended for teammates who are newer to git. Download at desktop.github.com. All the same operations work, just with buttons instead of commands.

Quick Reference

Situation	Command
Save progress after practice	`git add . && git commit -m "..." && git push`
Undo all unsaved changes	`git checkout .`
Try something risky	`git checkout -b experiment-name`
Get teammate's latest changes	`git pull`
See commit history	`git log --oneline`
Mark competition code	`git tag qualifier-1 && git push --tags`

⚙ STEM Highlight Technology: Distributed Version Control & Graph Theory

Git models code history as a directed acyclic graph (DAG) where each commit is a node and edges point from child to parent. A branch is a named pointer to a node in this graph. Merging two branches finds their lowest common ancestor (merge base) and applies both sets of changes. This graph structure means you can never truly lose work — every state is permanently stored as a node. The SHA-1 hash identifying each commit is a content-addressable identifier — the same content always produces the same hash, enabling integrity verification.

🎤 Interview line: “Git models code history as a directed acyclic graph. Every commit is a node with a unique SHA-1 hash. Branches are pointers to graph nodes. When we create a branch for risky autonomous experiments, we are creating an alternate path in the graph — both paths persist until we decide which to merge or discard.”

🔬 Check for Understanding

You made 3 commits while testing a new autonomous, but it broke your working code. The most efficient way to recover in Git is:

Delete the repository and re-download your last working version

Manually undo every change in each of the 3 commits

git revert to create new commits that undo the 3 changes, or git reset to move the branch pointer back to the last working commit

Create a new branch and start over from scratch

4 / 4