Version control: keeping firmware history with Git

Branches, commit granularity, release tags, and how to stamp the version into the firmware binary.

Commit granularity

One change per commit. "Change PWM frequency to 20 kHz" and "fix log format" go separately
The message says what and why: motor: PWM 16kHz→20kHz (remove audible noise)
Do not commit with the build broken

Branch strategy (small team)

The flow for a small team. main always builds and works.

Branch	Purpose
main	Always builds and is verified
feature/xxx	Feature development, merged after review
release/1.2	Release preparation, bug fixes only

RoadmapSee where this note sits in Firmware Design & Quality→

Stamping the version into the firmware

You need to know which code a unit returned from the field was running.

const char fw_version[] = "1.2.0";
const char fw_git[] = GIT_HASH;      // the build script passes -DGIT_HASH="a1b2c3d"

Make the version and hash readable in the boot log, a diagnostic command and communication responses. Keep released binaries together with their tag (v1.2.0).

What goes in the repository and what stays out

In: sources, linker script, CubeMX .ioc file, build scripts, schematic and PCB files (per version)
Out: build products (.o, .elf), personal IDE settings → .gitignore