Commands Are the Arrows

In Lesson 1 you built a mental model of four zones: working directory, staging area, local repository, and remote. Git commands are the arrows that move your changes between those zones. Every command in this lesson corresponds to one of those arrows — and knowing which zone your changes are in at any moment is how you know which command to run next.

The workflow tracer below steps through a complete FRC coding session from first clone to first push. Work through it before reading the individual command sections — the whole picture makes each piece easier to place.

A Complete FRC Session, Step by Step

The Commands in Depth

git clone — copying a remote repo to your machine

git clone downloads a repository from GitHub (or any remote) and creates a local copy with the full commit history. It also automatically sets up the remote — Git remembers the URL you cloned from as origin, so future push and pull commands know where to send and receive changes.

git status — reading the current state

git status is the most important command in your daily workflow. It tells you which files have changed in your working directory, which changes are staged for the next commit, and whether your local branch is ahead of or behind the remote. Run it constantly — before staging, before committing, before pushing. It costs nothing and tells you everything.

git add — moving changes to the staging area

Staging is a deliberate step: you choose exactly which changes belong in the next commit. This lets you make multiple unrelated edits in a session and commit them as separate, focused snapshots — "add intake motor" as one commit, "fix dashboard label typo" as another.

git commit — creating a permanent snapshot

A commit takes everything in the staging area and writes it to the local repository as a permanent, named snapshot. The -m flag attaches your message. Every commit gets a unique SHA hash — a 40-character fingerprint — that lets Git (and you) refer back to exactly this state forever.

git push — sending your commits to GitHub

git push uploads your local commits to the remote repository. Until you push, your commits exist only on your machine — a laptop that gets lost, broken, or wiped takes your unpushed commits with it. Push at the end of every session, and consider pushing after every significant commit during long sessions.

git pull — getting your teammates' changes

git pull downloads commits from the remote and merges them into your local branch. Run it at the start of every session and whenever a teammate tells you they pushed something. If you edited the same lines a teammate also changed, Git will alert you to a merge conflict — Lesson 3 covers resolving those.

git log — reading the commit history

The commit history is the most useful debugging tool you didn't know you had. When something breaks, git log shows you every change made and when. The --oneline flag gives a compact view perfect for scanning a build session's changes.

Read the log above from bottom to top — that's the actual sequence this robot's code was built in. When the swerve drive broke during testing, the team ran git diff a1b2c3d 2e9f563 to see exactly what changed between the two commits and found the FL/FR swap in under two minutes.

Commit Messages: The Difference Between a Log and a Story

A commit message is the only explanation future-you — or a teammate at competition — will have for why a change was made. The message lives in the permanent history of the repo. It costs nothing to write a good one and costs time to have written a bad one.

Team 2910 follows the Conventional Commits format, which is standard across professional software engineering and most competitive FRC teams:

The scope in parentheses is optional but strongly encouraged on a robot repo — it lets you scan the log and immediately know which mechanism each commit touches without reading the full description.

Commit Message Workshop

The messages below were pulled from real FRC repos (names changed). Select any one to see why it creates problems and what a better version looks like.

The .gitignore File: Keeping Build Artifacts Out

A .gitignore file tells Git to never track certain files or folders. In a WPILib project, the build system generates hundreds of megabytes of compiled class files, Gradle caches, and simulation outputs. None of these belong in the repository — they're regenerated automatically on every build, they change constantly, and including them buries actual code changes in noise. Every FRC repo should have a .gitignore committed before any other files.

The Daily Habit: Starting and Ending Every Session

Good Git hygiene is about consistent habit, not heroic effort. Every FRC programmer on 2910 follows the same pattern at the start and end of every coding session:

🔌 System Check

Knowledge Check

Click an answer to check your understanding.