Git Basics: init, add, commit, log

Embedded → Dev Tools & Version Control

This full-course video starts mid-way, at the "How Git Works?" chapter — it runs through "Hands-on Git" and "Git Scenario 1: Single User Setup", which is the exact init/add/commit/log walkthrough this lesson covers. Branching, merging, and PRs (the video's later chapters) are covered in the next lesson instead.

A repo is a history of snapshots, not a backup folder

git init creates a hidden .gitdirectory — the entire database of every commit, branch, and file version. Every commit is a full snapshot linked to the one before it; that chain is the "history" git log reads.

$ mkdir stm32-blink && cd stm32-blink
$ git init
Initialized empty Git repository in .../stm32-blink/.git/

The staging area: choosing exactly what goes into the next commit

A change lives in one of three places: the working directory (files on disk), the staging area (a draft of the next commit), or the repository (committed history). git add copies working → staging; git commit seals everything staged into a new snapshot.

The staging area is what lets you split unrelated edits into separate, clean commits — fix a bug in uart.c and add a new function to gpio.c in the same editing session, then git add uart.c and commit just that fix before staging and committing gpio.cseparately. Without a staging area, every commit would have to be "everything I've changed since last time," whether or not it belongs together.

$ git status
  modified:   uart.c
  modified:   gpio.c

$ git add uart.c
$ git commit -m "Fix UART baud-rate rounding"

$ git add gpio.c
$ git commit -m "Add gpio_toggle() helper"

Reading history with git log

git log walks the commit chain newest-first — each entry shows hash, author, date, and message. A good commit message is the difference between a useful map of whythe code changed and a wall of "wip"/"fix2" that tells you nothing months later.

$ git log --oneline
a3f9c21 Add gpio_toggle() helper
e14b8d0 Fix UART baud-rate rounding
9c02f77 Initial blink example

.gitignore — telling Git what not to track

A firmware build produces files that should never be committed — compiled .o/.elf/.bin, IDE settings, a build/ directory. .gitignore lists patterns Git silently skips.

# .gitignore
build/
*.o
*.elf
*.bin
*.map
.vscode/

Try it — move a change through working → staged → committed

Click through the same three-stage flow every commit goes through in a real repo.

Working directory → staging area → repository

Working directory

uart.c

gpio.c

Staging area

Repository

uart.c

gpio.c

Practice

Copy GitHub's "Introduction to GitHub" exercise to your own account and work through the guided commit steps — then, in a scratch folder of your own, run git init, create a two-file firmware stub, and commit each file separately with its own staging step, exactly like the demo above.

Completion saves automatically after you read through to the end.

Next lesson →

← Back to learning path