Git integration lets CopperPilot reason about firmware alongside your hardware artifacts. That matters because bring-up bugs are often cross-domain: a pin mapping in code does not match the schematic, or a driver assumes a regulator comes up in the wrong order.
Connect the repository you use for firmware—PlatformIO, bare-metal, or a monorepo with hardware docs. CopperPilot uses the integration to answer questions about recent commits, module boundaries, and likely regression points when a board revision lands.
Start with a narrow scope: one repo, one board, one branch. Ask the copilot to summarize initialization order, peripheral mappings, and test entry points. That map becomes the backbone for later debugging sessions.
Use the video below as a supporting walkthrough for connecting GitHub and navigating the first successful sync.
Once connected, make Git part of your review ritual. Before approving a board spin, ask what firmware assumptions still depend on the old pinout. Before merging a driver refactor, ask which schematic nets are implicitly coupled to the changed code.
The integration is most valuable when the team agrees on naming and checkpoint discipline. Good commit messages and tagged releases give the copilot anchors that survive personnel changes.
If you hit permission issues, verify the repo scope and try a read-only integration first. You can broaden access after the workflow proves useful on a single project.