Version control for electronics: Git for PCB and firmware

A bug introduced by a firmware update can be found among 1,000 commits in fewer than 10 steps with git bisect; in a firmware_v2_final_REALLY_final_fixed folder, it cannot be found at all. Git for electronics engineers is the practice of applying a Distributed Version Control System (DVCS) to firmware, PCB layouts, lab scripts and certification artefacts to make every project audit-ready. Created in 2005 by Linus Torvalds, Git is the reference VCS for industrial embedded teams. At AESTECHNO, design firm in Montpellier, our team has used Git for more than 10 years on industrial embedded software with atomic commits under 200 lines.

Contents

• What is Git and why electronics engineers should care
• Core concepts explained for hardware teams
• The 10 essential Git commands for daily use
• Tangible benefits on firmware and PCB projects
• Use cases in electronics design and embedded firmware
• Recommended platforms and clients
• GitHub vs GitLab vs Bitbucket : how to choose
• Merge vs rebase : which strategy fits your team
• CI/CD lab integration with TekExpress
• Bottom line
• FAQ

What is Git and why electronics engineers should care

Git is a Distributed Version Control System (DVCS) that records the full history of a project and lets several engineers collaborate without overwriting each other. Created in 2005 by Linus Torvalds for the Linux kernel, it has become the reference Version Control System (VCS) for source code, firmware, lab scripts and technical documentation. According to git-scm.com, the current reference release is Git 2.42 (August 2023) with initial SHA-256 support as an alternative to SHA-1. Git is distributed under the GNU General Public License (GPL) v2, with adoption above 95% on the major hosting platforms.

Concretely, for firmware, PCB and lab teams alike, Git answers four pain points every electronics engineer recognises, from lost work to missing traceability :

• Lost work : without Git, a file overwritten by mistake is gone. With Git, every version is preserved and recoverable in seconds.
• Version chaos : no more firmware_v2_final_REALLY_final_fixed folders. Git manages versions in a structured, reliable way.
• Difficult collaboration : two engineers editing the same file in parallel no longer step on each other ; Git detects and surfaces conflicts.
• No traceability : when a bug appears, Git pinpoints exactly which change introduced it, when, and by whom.

Git was written by Linus Torvalds in less than ten days to replace BitKeeper, as Junio Hamano (Git maintainer since 2005) regularly reminds the kernel community. The Linux kernel absorbs more than 75 000 commits per year today, all tracked in Git. If Git can handle the Linux kernel, it can handle your firmware project.

Core concepts explained for hardware teams

A Git repository is a content-addressable storage of three object types : blob (file contents), tree (folder snapshot) and commit (timestamped snapshot pointing to a tree), each identified by a 40-character SHA-1 hash. The SHA-256 transition is in progress since Git 2.29, and although the technical terms repository, commit, branch and merge can sound intimidating, the underlying ideas are very intuitive once mapped to firmware practice.

The five subsections below map each concept to firmware practice: the repository that carries the full history, the commit as a snapshot of the project, the branch for parallel work without risk, the merge that reunites branches, and the remote that synchronises with a server such as GitLab or GitHub. Once these five ideas are clear, the daily commands follow naturally.

The repository

A Git repository, often shortened to "repo", is simply a project folder that carries the full history of every modification it ever received. When you initialise a Git repository inside a folder, Git creates a hidden .git sub-folder where it stores the history. Your source files do not move, they stay exactly where they are.

A repository can be local (on your workstation) or remote (on a server such as GitLab or GitHub). The strength of Git is that every contributor holds a complete copy of the repository, history included. Even if the server crashes, nothing is lost.

The commit : a snapshot of your project

A commit is an instantaneous picture of your project at a given moment. Think of it as a smart save : instead of duplicating every file, Git only stores the differences from the parent commit. Each commit carries a message that describes the change, for example fix(spi) : correct DMA timeout on STM32H7 in slave mode. Commits form a chronological chain, the history of your project. You can return to any previous commit, compare two versions, or identify exactly when a change was introduced. This traceability is what makes Git essential on projects subject to CE/RED certification or IEC 62443-4-1 audits.

The branch : work in parallel without risk

A branch is an independent line of development. Every repository has a primary branch. On GitHub (since October 2020) and GitLab (since version 14.0, in 2021), new repositories name it main. The older name master remains on older repositories and is still what a local git init creates, unless the init.defaultBranch option (Git 2.28) is set to main. When a developer wants to add a feature or fix a bug, they create a new branch from main, work on it freely, and only merge back when the work is reviewed and validated. The analogy is the obvious one : main is the trunk of a tree, every branch is a branch.

On a typical firmware project, you would see :

• main, the stable version that ships in production
• feature/new-sensor-driver, the development of a new driver
• fix/ble-connection-bug, a Bluetooth connection fix
• release/v2.1, the staging branch for the next release

The merge : reuniting branches

Merge is the operation that integrates the changes from one branch into another, typically a feature branch into main. Git compares both sides and combines them automatically. In the vast majority of cases the merge happens without human intervention. When two engineers have edited the same lines of the same file, Git raises a "conflict" and asks a human to decide. That is not a failure, that is a safety mechanism, and we prefer resolving a conflict explicitly than silently overwriting somebody's work.

The remote : synchronising with the server

A remote is a copy of the repository hosted on a server (GitLab, GitHub, Bitbucket). The git push and git pull commands synchronise commits between local and remote, and the remote also serves as a centralised backup. As long as the server is alive, the project is safe. We recommend at least one remote per project, two for repositories under CRA scope (one self-hosted GitLab, one off-site mirror).

The 10 essential Git commands for daily use

The essential Git commands cover repository initialisation, staging, committing, branch management and synchronisation with a remote. Git is a command-line tool with roughly 150 sub-commands, but ten of them cover 90% of daily work according to the official documentation at git-scm.com.

The table below lists those ten commands with their action and a typical example. Git init, add and commit create a repository and record snapshots; git branch, checkout and merge manage parallel lines of development; git log shows the history; git push and pull synchronise with the remote; and git bisect binary-searches the commit that introduced a bug. Learning these ten first is enough to start working on a firmware project.

Tangible benefits on firmware and PCB projects

Git delivers four measurable benefits on technical projects, whether the repository holds firmware, lab scripts or PCB design files : full traceability of every change, parallel collaboration without silent overwrites, instant rollback, and mandatory code review through merge requests.

Full traceability means every modification is stored with its author, date and context, and git bisect finds an offending commit among 1000 in fewer than 10 iterations. Parallel collaboration lets one engineer develop a driver while another optimises power consumption, each on their own branch. Rollback to a previous firmware version takes seconds, and merge requests put every change through peer review before it reaches main. The subsections below detail each benefit.

Full traceability

Every modification is stored with its author, date and context. When a customer asks "what changed between v1.3 and v1.4 ?", the answer is one command away with git log v1.3..v1.4. When a bug appears after an update, git bisect finds the offending commit among hundreds in fewer than 10 iterations for 1000 commits, thanks to the dichotomic search (log2(1000) is approximately 9.97). This traceability is decisive during CE/RED certification audits (IEC 62443-4-1, ISO 27001) and during technical due diligence.

Smooth collaboration

Git lets several engineers work in parallel on the same project without stepping on each other. One firmware engineer develops a new driver while another optimises power consumption, each on their own branch, with no interference. The merge then integrates both contributions in a controlled way. For projects involving both electronic design and firmware, this parallelism is decisive.

Safe rollback

A firmware update introduced a critical regression in the field ? With Git, reverting to the previous version takes seconds. No need to dig through archives, no need to ask a colleague whether they kept a copy, no need to rebuild the firmware from fragments of memory. The rollback is instant and reliable because every version of the code is preserved intact in the Git history.

Systematic code review

Code review is the "merge request" mechanism on GitLab or "pull request" on GitHub that submits changes to peer review before integration into the main branch. A second pair of eyes before the merge reduces bugs, spreads knowledge across the team, and lifts overall code quality. According to a SmartBear study, every hour of code review saves an average of 4 hours of downstream debugging. We consider this practice non-negotiable on every critical project subject to IEC 62443-4-1 or to the Cyber Resilience Act (CRA).

Use cases in electronics design and embedded firmware

A Git repository in an electronic design firm tracks four families of artefacts : firmware source code, lab and production scripts, technical documentation and PCB / schematic design files. These artefacts cover C, C++, Rust or Python on the firmware side, and KiCad or Altium on the hardware side. According to the NVIDIA JetPack documentation and the Zephyr project guidelines, full versioning including the BSP is now a standard practice.

The four subsections below take each family in turn: firmware for STM32, nRF52, ESP32 or Jetson targets, functional test and production programming scripts, specifications and user guides, and KiCad or Altium design files. The same discipline applies to all four: one shared history, and one release tag that bundles the matching firmware, documentation and design files for each shipped version.

Firmware and embedded software

Embedded firmware is the most natural Git use case. Firmware source written in C, C++, Rust or Python for STM32, nRF52, ESP32 or NVIDIA Jetson targets is versioned in Git. RTOS frameworks such as FreeRTOS, Zephyr and NuttX are themselves maintained under Git (git.kernel.org for Linux, GitHub for Zephyr and FreeRTOS). Each feature lives on a dedicated branch, gets tested, peer-reviewed, then merged into the main branch. Releases are marked by Git tags (v1.0.0 per Semantic Versioning 2.0) so that the exact code shipped with each release can be retrieved instantly.

Test and production scripts

Functional test scripts, production programming procedures and test bench configurations evolve alongside the project and benefit from the same versioning as the firmware. When a validation procedure changes, the Git history lets us recover the previous version when needed for a regression on legacy units in the field.

Technical documentation

Specifications, application notes and user guides evolve with the product. Versioning them in Git keeps documentation in lock-step with the firmware. A release tag bundles not only the firmware but also the matching documentation set, which is decisive during certification audits.

Electronic design files

Schematics and PCB design files (KiCad, Altium) can also be versioned in Git. Visual diff is less intuitive on binary schematics than on plain text, yet history and rollback remain valuable. Tools like KiCad ship native Git integration with line-level diff on plain-text schematic format (since KiCad 6, 2021), and we recommend that hardware engineers commit a routed PCB at the end of every layout day rather than once per week.

Recommended platforms and clients

A production-grade Git ecosystem is built from three layers : a remote server (GitLab, GitHub, Bitbucket, Gitea), a local client, and a Continuous Integration / Continuous Delivery (CI/CD) pipeline triggered on every push. According to Atlassian, more than 90% of professional teams use a combination of these three layers today.

The subsections below cover the hosting platforms (GitLab, GitHub, Bitbucket and Gitea), the graphical clients for team members who prefer a visual interface (GitKraken, Sourcetree, VS Code), and the best practices we apply from the first commit. For industrial projects, our recommendation is GitLab, self-hostable for sensitive work and shipping native CI/CD; GitHub fits open-source projects and external collaboration, and Bitbucket fits teams already running the Atlassian stack.

Hosting platforms

• GitLab : our recommendation for industrial projects. GitLab Community Edition is self-hostable for sensitive projects, ships native CI/CD (400 free minutes per month on SaaS), and offers fine-grained permissions. It is the platform we use on our embedded DevOps projects.
• GitHub : the most popular platform on the planet according to the State of the Octoverse 2024 (100 million developers), perfect for open-source projects and external collaboration. Its integration ecosystem (GitHub Actions with 2000 free minutes, Copilot, Dependabot) is the richest on the market.
• Bitbucket (Atlassian) : a solid alternative, well-integrated with Jira and Confluence if your organisation already runs the Atlassian stack.
• Gitea : a lightweight Gogs fork written in Go, ideal for a minimalist self-hosted server (less than 100 MB of RAM at idle).

Graphical clients

For team members who prefer a visual interface :

• GitKraken : modern and intuitive, clear branch tree visualisation, available on Windows, macOS and Linux.
• Sourcetree : Atlassian's free client, well documented, available on Windows and macOS.
• VS Code : Microsoft's editor ships native Git support. For firmware developers already running VS Code with PlatformIO or the Zephyr extension, it is the most natural fit.

Best practices to start with

These are the rules we apply systematically on our projects, aligned with the Conventional Commits 1.0.0 specification and with the official Pro Git book :

• One commit equals one logical change. No grab-bag commits that mix bug fix, new feature and code cleanup.
• Clear commit messages. "Fix bug" says nothing. "fix(spi): correct DMA timeout on STM32H7" makes the change understandable without opening the diff (Conventional Commits format : type(scope): description, 50 characters max).
• Never commit secrets. Passwords, API keys, certificates do not belong in Git. Use a .gitignore file to exclude them automatically. Tools such as git-secrets and truffleHog scan every push.
• Always branch. Even for a small change. The main branch must always remain in a working state.
• Mandatory code review. No merge into main until at least one peer has reviewed the diff.
• Strong authentication. SSH ed25519 keys (defined in RFC 8709) or scoped Personal Access Token (PAT), 2FA enabled on the platform side.

GitHub vs GitLab vs Bitbucket : how to choose

GitHub, GitLab and Bitbucket are the three Git hosting platforms most widely used in professional environments, but they answer different needs. In our practice on embedded DevOps projects, we have observed that the choice depends mostly on source-code sensitivity and on regulatory constraints (CRA EU 2024/2847, IEC 62443-4-1, GDPR, data sovereignty).

Self-hosted GitLab Community Edition offers full control over sources and native CI with runners on internal infrastructure. GitHub has the richest integration ecosystem (GitHub Actions, Dependabot, CodeQL) and suits open-source work and fast prototypes. Bitbucket integrates with Jira and Confluence for organisations already on the Atlassian stack. The table below compares the three platforms criterion by criterion, followed by our recommendation for firmware projects under CRA or IEC 62443-4-1 scope.

Our recommendation : for a firmware project subject to the Cyber Resilience Act (CRA) or to IEC 62443-4-1, self-hosted GitLab Community Edition is often the best compromise : full control over sources, native CI integration with runners on internal infrastructure, GDPR compliance guaranteed by the absence of any non-EU transfer. Per ANSSI doctrine, self-hosting sensitive repositories is recommended for projects under the French RGS framework. For an open-source project or a fast prototype, GitHub remains unbeatable thanks to the breadth of its ecosystem (GitHub Actions, Dependabot, CodeQL).

Merge vs rebase : which strategy fits your team

A rebase replays a sequence of commits on a new base point, rewriting their SHA-1, while a merge preserves both parallel histories and creates a merge commit. The merge-vs-rebase debate has split teams for more than 10 years. Both commands integrate the same changes; what differs is the history the team reads afterwards.

Three integration strategies are on the table: merge, which preserves the literal history and underpins Git Flow; rebase, which rewrites the feature branch on top of main for a linear history and is recommended by trunk-based development; and squash-merge, which combines a feature branch into a single commit and simplifies git bisect. Our practical rule, detailed below, combines rebase before the merge request with squash-merge into main.

• Merge preserves the literal history : every branch keeps its trail and merge commits form a forked tree. Ideal for teams that want to see when and why a feature landed. Git Flow (Vincent Driessen, 2010) is built on this logic.
• Rebase rewrites the feature branch on top of the latest main. The result is a linear history, much easier to read with git log --oneline. Recommended by the trunk-based development model (Paul Hammant, 2013) adopted at Google, Facebook and most CRA-ready embedded teams.
• Squash-merge combines all commits of a feature branch into a single commit at integration time, which simplifies git bisect on the main branch.

Our practical rule : rebase before opening the merge request (for a clean history), merge into main via squash-merge (for an atomic final commit per feature). This hybrid approach gives you the best of both worlds and accelerates git bisect when a regression appears, an operation that locates the offending commit among 1000 commits in fewer than 10 steps thanks to dichotomic search.

Our recommendation: GitLab Flow

GitLab Flow is a branching model described in the GitLab documentation: an always-releasable main branch, short feature branches merged through merge requests, and release branches (release/v1.2) cut as late as possible for each shipped version. It is the model we recommend for an electronic product.

The reason is specific to hardware: once boards ship, several firmware versions live side by side in the field for years. GitHub flow and trunk-based development assume a single state, the latest, is in production. Gitflow handles versions, but its develop branch doubles the integration work with no benefit for a small team.

We run GitLab Flow with merges only. To fix a shipped version, a fix branch starts from the affected release branch, then is merged through merge requests into release/v1.2 (new patch tag v1.2.1) and into main. We do not recommend git cherry-pick for these carry-overs: it copies the commit under a new SHA, Git no longer knows the fix is already there, and one forgotten pick or badly resolved conflict is enough for the bug to come back in the next version. With a merge, the same commit lives on both branches and Git keeps track of it. Only fixes enter a release branch, never new features. This per-version maintenance is also what the Cyber Resilience Act expects when you ship security updates over the whole support period.

For a web or cloud service, GitLab Flow offers a variant with environment branches (staging, production): code moves from one to the next through merge requests, always in the same direction.

CI/CD lab integration with Tektronix TekExpress

Lab compliance test automation is the practice of running compliance suites (PCI Express, USB 3.x, MIPI, DDR4, HDMI, Ethernet, LVDS) directly from a CI pipeline so every firmware tag triggers an electrical-compliance run on the bench. At AESTECHNO our lab features a Tektronix oscilloscope equipped with the Tektronix TekExpress suite, used to pre-qualify boards in-house before the accredited-lab pass.

Looking forward to 2027, we expect every CRA-scoped product to ship with a CycloneDX SBOM linked to its Git tag, signed by the build pipeline, archived alongside the compliance reports. Under the CRA, the vulnerability and incident reporting obligations (24 h early warning, 72 h notification) apply since 11 September 2026, with full application on 11 December 2027, which puts an even higher premium on Git traceability.

Bottom line

• Git is non-negotiable for any electronics or firmware project that targets CE marking, Radio Equipment Directive (RED), IEC 62443-4-1 or the EU Cyber Resilience Act (CRA) 2024/2847. No versioning equals no traceability, which equals no audit, which equals no certification.
• Atomic commits under 200 lines, descriptive Conventional Commits messages (50 characters max for the first line), one branch per feature, mandatory peer review before merge into main, and a CI/CD that blocks any merge with broken tests : these five rules turn a fragile project into an industrial one.
• Self-hosted GitLab Community Edition is our default for projects under CRA scope ; GitHub remains unbeatable for open-source visibility ; Bitbucket fits teams already inside the Atlassian (Jira, Confluence) stack.

FAQ : Git for electronics and firmware projects

This FAQ collects the six questions our clients ask most often when we set up version control on their team.

Related articles

• Electronic design services in Montpellier : AESTECHNO methodology
• Embedded DevOps : CI/CD, automated tests and firmware deployment
• Industrial embedded software : the complete guide
• Embedded Linux distributions compared
• All AESTECHNO articles