Lesson 2 of 5 · 20 min
Git in ten commands
Git is a tool that remembers every version of your project and lets many people change it at once without overwriting each other. Robotics makes this more valuable than usual: when the robot suddenly drifts left, the ability to ask "what changed since it last drove straight?" can save a week. Git has hundreds of commands, but a beginner can do real work with ten, and understanding why each exists is more useful than memorising flags.
The mental model
Three places matter. The working tree is the files you see and edit. The staging area is a waiting room where you choose which changes go into the next snapshot. The repository is the history of snapshots, called commits. Each commit records what the files looked like, who made it, when, and a message explaining why.
The staging area is the part beginners find odd. It exists so that you can make five unrelated edits and still record them as two clean, separate commits. One commit should do one thing.
A branch is just a movable label pointing at a commit. Creating one costs nothing, which is why Git encourages you to make a branch for every experiment and keep main working.
The ten commands
| Command | What it does | Why you need it |
|---|---|---|
git init | Starts a new repository in the current folder | Begin tracking your own project |
git clone | Copies an existing repository, with its full history | Get a project someone else published |
git status | Shows what changed and what is staged | Your compass; run it constantly |
git add | Moves changes to the staging area | Choose what goes into the next commit |
git commit | Records the staged changes as a snapshot | Create a point you can return to |
git branch | Lists, creates or deletes branches | Keep experiments apart |
git switch | Moves you to another branch | Change which line of work you are on |
git merge | Combines another branch into the current one | Bring finished work together |
git pull | Fetches new commits from a remote and merges them | Stay up to date with others |
git push | Uploads your commits to a remote | Share your work |
A small worked session
Imagine a line-following robot. First, create the project and record a starting point.
mkdir line-follower
cd line-follower
git init -b main
git config user.name "Your Name"
git config user.email "you@example.com"
echo "# Line follower" > README.md
git status
git add README.md
git commit -m "Add README with project goal"
git status before git add shows README.md as untracked. After git add it is staged. After git commit the working tree is clean. Now start an experiment on its own branch, so main stays safe.
git switch -c tune-motor-speed
echo "const int BASE_SPEED = 120;" > config.h
git add config.h
git commit -m "Add base motor speed constant"
git switch main
git merge tune-motor-speed
git branch -d tune-motor-speed
git switch -c creates the branch and moves to it in one step. Merging brings the commit into main, and the branch label is no longer needed. Here main had no new commits of its own, so Git simply moves the label forward, which is called a fast-forward. If both branches had changed, Git would create a merge commit joining them.
Working with a remote on GitHub or similar looks like this.
git clone https://github.com/your-name/line-follower.git
cd line-follower
git pull
git push
pull is a fetch followed by a merge, so your branch gets everyone else's new commits. push publishes yours. If someone pushed first, Git will refuse your push, and the fix is to pull, resolve any conflicts, then push again.
Undoing mistakes safely
Fear of breaking things stops many beginners from experimenting. Git has safe ways out, as long as you choose the right one for the situation.
You edited a file and want the old version back:
git restore config.h
This throws away your uncommitted changes in that file, so use it only when you mean it. Uncommitted work has no history to recover from.
You staged a file by accident and want to unstage it, keeping your edits:
git restore --staged config.h
You committed something wrong and it is already shared:
git log --oneline
git revert a1b2c3d
git revert makes a new commit that undoes the old one. History stays honest and nobody who already pulled the bad commit is broken. This is the safe choice for anything that has left your machine.
Commit messages that read well
A commit message is a note to a future reader, quite possibly you in six months, debugging a robot at a competition. The history is only useful if the messages are.
A widely used shape is a short summary line, a blank line, then a body explaining the reason:
Limit motor PWM to 200 to avoid driver overheating
The driver's thermal shutdown triggered after about a minute at
full duty cycle. Capping at 200 keeps it under the shutdown
threshold in bench tests and costs little top speed.
Some habits that make this work:
- Write the summary in the imperative mood, as if completing the sentence "This commit will...": "Add", "Fix", "Remove".
- Keep the summary line short, around 50 characters, so it fits in one-line logs.
- Explain why in the body. The diff already shows what changed; only you know the reason.
- One logical change per commit. If you need the word "and" in the summary, consider two commits.
- Never write "fix stuff" or "update". They are noise that you will resent later.
Different projects have their own conventions on message format, so check the CONTRIBUTING file before sending changes upstream.
Check yourself
You committed a bad change and already pushed it to a shared branch. Which command is the safest way to undo its effect?
Check yourself
What is the main purpose of the staging area?