1. Git & Version Control#

Why it matters#

Picture build season: five programmers, one robot project, a competition in two weeks. Without a system, someone copies an old version over a new one, a working autonomous gets lost, and nobody knows what changed when the robot suddenly stops driving straight.

Git fixes all of that. It:

• saves a snapshot every time you commit, so you can always go back
• shows exactly what changed between any two versions, and who changed it
• lets several people work at the same time without overwriting each other

Every FRC team that's serious about software uses Git, usually with GitHub to share the code. This course website is stored in Git too.

Read this#

• Git Version Control Introduction (WPILib)
• GitHub Skills: short, free, interactive courses. Do "Introduction to GitHub."

Walkthrough#

Git vs. GitHub#

These get mixed up constantly:

You can use Git without GitHub, but teams use both: Git on each laptop, GitHub as the copy everyone syncs with.

The words you need#

The three places your changes live#

This is the idea that makes Git click:

Editing a file changes only your working folder. Nothing is saved in Git until you add and commit, and nobody else sees it until you push.

One-time setup#

Tell Git who you are. Your name goes on every commit you make:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Use the same email as your GitHub account so GitHub links commits to you.

Your first commit#

Open a terminal in your my-first-robot folder. In VS Code: Terminal → New Terminal.

git init                         # start tracking this folder
git status                       # see what Git notices
git add .                        # stage every changed file
git commit -m "Initial robot project"
git log --oneline                # see your history

Reading git status#

You'll run this more than any other Git command. It tells you exactly where your changes are:

On branch main
Changes to be committed:            ← staged; will go in the next commit
        modified:   src/main/java/frc/robot/RobotContainer.java

Changes not staged for commit:      ← edited but not staged yet
        modified:   src/main/java/frc/robot/Constants.java

Untracked files:                    ← new files Git isn't tracking yet
        src/main/java/frc/robot/subsystems/Intake.java

Writing good commit messages#

Future you, at 11 PM before a competition, will read these. Make them useful:

A good message says what changed and, if it isn't obvious, why. Keep each commit to one idea. Small commits are easy to understand and easy to undo.

Push to GitHub#

1. Make a free account at github.com if you don't have one.
2. Click New repository, name it my-first-robot, and leave every box unchecked (no README, no .gitignore). You already have files.
3. GitHub shows commands under "…or push an existing repository from the command line." They look like this:

   git remote add origin https://github.com/YOUR-NAME/my-first-robot.git
   git branch -M main
   git push -u origin main
   

4. Refresh the GitHub page. Your code is there.

The first push may open a browser window to sign in. That's normal.

Getting the team's code: clone#

To work on a repo that already exists, like the team's robot code, you clone it instead of using git init:

git clone https://github.com/Robojacks/REPO-NAME.git

That creates a folder with the full project and all its history, already connected to GitHub.

The daily loop#

git pull                         # 1. get everyone's latest work
# ...edit code, build, test...
git status                       # 2. see what you changed
git diff                         # 3. read your own changes before saving them
git add .                        # 4. stage
git commit -m "Describe the change"
git push                         # 5. share

Undoing things#

Merge conflicts#

When two people change the same lines of the same file, Git can't pick a winner, so it asks you. After a git pull, the file will contain markers like this:

<<<<<<< HEAD
private final double kP = 0.05;     // your version
=======
private final double kP = 0.08;     // the version you pulled
>>>>>>> origin/main

To fix it:

1. Decide what the line should be. Sometimes it's one version, sometimes a mix. Ask whoever wrote the other one.
2. Delete the marker lines (<<<<<<<, =======, >>>>>>>).
3. Build to make sure it compiles.
4. git add the file and git commit.

VS Code highlights conflicts and gives you Accept Current / Accept Incoming / Accept Both buttons above each one.

Using Git inside VS Code#

You don't have to type everything. The Source Control panel (the branch icon on the left side) lets you stage files with +, type a message, commit, and sync. It's the same Git underneath. Learn the commands first so you know what the buttons do.

Try it#

• Set your user.name and user.email
• Make three commits to your project, each with a clear message
• Push them to GitHub and find them on the website
• Change a line, run git diff, then git restore the file to throw the change away
• With a partner: both clone the same repo, both change the same line, both push. Whoever pushes second resolves the conflict.

Check yourself#

We'll cover branches and pull requests in Lesson 15.