Before each tournament, create a branch. During the event, all changes go on it. After the event, pull-request it back to main as your team's post-comp retrospective. Three phases, one rhythm, every event.
This guide is the workflow Spartan Design uses for tournaments. Read the Git + VS Code Basics guide first if you haven't — that one teaches what branches and PRs are; this guide teaches when to use them.
mainmain. Push at the end of each session. No branches, no PRs — the simplicity is the point.main with a name like comp/2026-fall-league-1. Push it to GitHub. From this moment, main is frozen until the comp is over.main stays clean. If a fix turns out to be wrong, only the comp branch is affected.main. Review the diff with your mentor: what changes are worth keeping, what was just panic, what taught you something. Merge what stays. The PR description becomes your engineering retrospective.main Is Always SafeIf your tournament-day "fix" actually broke autonomous, only the comp branch carries it. Re-cloning main on another laptop gets you back to known-good code in 30 seconds.
"What did we change at this event?" is a question every good team asks after a tournament. The comp branch's diff against main answers it exactly — line by line.
Not every comp-day change is worth keeping. The PR review is your chance to cherry-pick what worked and revert what didn't, before any of it touches main.
Don't delete the branch after merging. comp/2026-fall-league-1 is forever — a cite-able record of exactly what your robot ran at that specific event.
main. If multiple people commit to the same code, you'll want the feature-branch + pull-request model from Git & GitHub Workflow Deep Dive — the comp-branch idea still applies, but day-to-day work goes on per-feature branches instead of straight onto main.The format: comp/<year>-<season>-<event>. Examples:
| Event | Branch name |
|---|---|
| Fall League Match #1 | comp/2026-fall-league-1 |
| Spring State Championship | comp/2026-spring-state |
| VEX Worlds | comp/2026-worlds |
| Off-season scrimmage at school | comp/2026-fall-scrimmage-1 |
Lowercase, hyphens between words, no spaces or special characters. Use the year so end-of-season branches sort chronologically when listed in git branch.
Run these in your project folder. (Or use VS Code's branch picker in the bottom-left status bar — click the current branch name, then "Create new branch from..." and follow the prompts.)
The -u on the last command is important — it tells Git "future pushes from this branch go to the same place." Without it, you have to specify the remote every time.
mainFrom this moment until the PR is merged after the event, nobody pushes to main. No exceptions:
The reason: if anything you do during the comp is wrong, you want one clean revert path — just delete the comp branch. If even one push went to main during the event, that path is gone.
comp/2026-fall-league-1, not main. Half of all "I committed to the wrong branch" disasters happen because the programmer was on main and didn't notice.main is in a known-working state — auton runs, opcontrol works, robot drives.main and pushed to GitHub.main.Even tiny changes between matches get committed to the comp branch with a real message. The reason isn't ceremony — it's that the commit history is your event log:
Look at that history six weeks later and you have a tournament timeline. Match 4: kP increased. Match 5: auton distance reduced. Match 7: kP reverted. "Did the kP change actually help?" — the commit history will answer.
If you have wifi at the event, push to GitHub between matches. Push the comp branch only. Never push to main during a comp:
If wifi is bad — common at competitions — commit locally and push when you get back. The commits aren't lost, they just haven't been mirrored to GitHub yet.
You made a change between matches and now nothing works. Three responses, ranked by how reversible they are:
git reset --hard HEAD~1 — throws away the most recent commit and resets your working files. Use when you know exactly which commit broke things.git stash saves them, git reset --hard HEAD goes back to the latest committed state. git stash pop brings them back later.git reset --hard is destructive. Files in your working directory are wiped. Make sure you've actually committed everything you want to keep before running it. If unsure, git stash first — that's the non-destructive way to "set aside" changes.Don't create sub-branches off the comp branch during a tournament. Resist the urge to do comp/2026-fall-league-1/auton-experiment. The whole point of the comp-branch pattern is one branch per event — multiple branches multiplies confusion at the worst possible time.
If an experiment fails, just commit "experiment" then commit "revert experiment" right after. The history shows what you tried and what you went back to. That's a feature, not a bug.
maingit push.main, compare to your comp branch.Don't accept GitHub's auto-generated description. Replace it with something like:
Sit with your mentor (or have a video call). Open the PR's Files changed tab. Walk through every change line by line:
If the diff looks good as-is, click Merge pull request. Pick Create a merge commit rather than squash — you want every individual comp-day commit preserved in main's history.
If you want to keep some changes and revert others, do that on the comp branch before merging:
Then merge the PR. The merged result is "everything from the comp branch except the parts we reverted."
Don't delete the branch. GitHub asks if you want to delete the merged branch — click No. Keep the comp branch around forever. It's the historical record of what your robot ran at that specific event, and you may want to point a judge or a future teammate at it.
git tag -a 2026-fall-league-1 -m "Fall League #1 merged" from main, then git push --tags. This makes the merge commit easy to find later via the GitHub Releases page. Lightweight version of "what code did we run at each event."This page is intended to be linked directly when assigning a mentor reviewer. Mentors can copy the checklist into the PR comments and tick boxes as they go.
SCORE_STOP_MM = 280 not just 280)master.print calls left over from troubleshooting)?distance > 0 && distance <= target not just distance <= target)?Sometimes a PR isn't ready. Common reasons to pause:
git revert on the specific commits before merging (see Section 4).None of these are reasons to be harsh. The student made decisions under pressure at a tournament — the PR review is the calm follow-up, not a critique. The framing that works: "Now that we have time, here's what I'm noticing — want to fix any of these before merge?"
You're at the event, you make a fix, and you realize you've been committing to main the whole time. Don't panic. The recovery is two commands:
This puts your event-day commits on the comp branch where they belong. main on your laptop is now ahead of main on GitHub by those same commits — which is fine, because you're not going to push it.
If you've already pushed to main on GitHub, that's a bigger problem — the wrong commits are now on everyone's main. Ask your mentor for help; the fix is a force-push to revert main to where it was before, but force-pushing affects everyone with a clone, so it has to be coordinated.
main While I Was at the Comp"The comp-branch policy says "main is frozen during a comp" but life happens. A teammate or mentor pushed something to main while you were at the event. Now your comp branch is "behind" main by their changes.
The fix when you PR: GitHub will warn that the branch can't be auto-merged. Pull main into the comp branch, resolve any conflicts, push, then merge:
Long tournaments produce long histories. If the PR description has 30 bullet points, group them by category in the description:
That makes the review tractable. The mentor can focus attention on the chassis tuning section if that's the most important, skim the others.
Your laptop dies. You grab a borrowed laptop. You need the latest comp-branch code on it in five minutes. The recovery:
The -b flag puts you straight on the comp branch. --single-branch avoids downloading main and any other branches you don't need at the event — faster on slow tournament wifi.
You'll need to sign in to GitHub on the borrowed laptop (Section 3 of GitHub Getting Started). If the laptop doesn't have Git installed at all, install via the PROS USB drive your mentor brought (or worst case, fall back to the brain's own program memory and don't touch Git until you get home).
.git folder is a complete backup. Worst case, you can restore the project from those when you get home.Three guides done. You have the local-Git basics, you're on GitHub with the team, and you know the comp-branch workflow. The next time you're at a tournament, you'll have a clean event log, a safe fallback, and a built-in retrospective when you get home.