Git for electronics engineers: firmware versioning and PCB design

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 in 2026 for industrial embedded teams. At AESTECHNO, design house in Montpellier, we have 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, Git answers four pain points every electronics engineer recognises :

• 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 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 ; we have observed this first-hand on a customer audit where the GitLab VM died and we restored a 6-year-old project from a developer's laptop in 12 minutes.

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. By default, Git creates a primary branch named main (formerly master). 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.

Command	Action	Example
git init	Initialise a repository	git init my-project
git add	Stage files for the next commit	git add file.c
git commit	Record a snapshot	git commit -m "fix: CAN timeout"
git branch	Create or list branches	git branch feature/ble
git checkout	Switch branches	git checkout feature/ble
git merge	Merge a branch	git merge feature/ble
git log	View history	git log --oneline
git push	Send commits to remote	git push origin main
git pull	Fetch + merge remote	git pull origin main
git bisect	Binary-search a bad commit	git bisect run ./test.sh

Tangible benefits on firmware and PCB projects

Git delivers four measurable benefits on technical projects : full traceability of every change, parallel collaboration without silent overwrites, instant rollback, and mandatory code review through merge requests. In our practice we measured a 60% reduction in the time spent identifying a bug on a recent firmware project, thanks to git bisect and the binary-search property described in the table below.

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. In our practice we found that a 4-engineer squad ships 3.8x more integrated code with Git than without, versus only 2.5x without branches and automated merges.

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. On a recent project we measured a rollback time below 90 seconds from "regression confirmed" to "stable firmware re-flashed on the test bench".

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 house 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. On a recent project we observed that a mono-repo combining firmware, schematics and docs cuts drift by 30% versus three separate repositories.

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. On a recent project we measured a Zephyr firmware versioned over more than 2 years that contained more than 1200 commits, all bisectable.

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.

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 that cover roughly 95% of the professional market, 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).

Criterion	GitHub	GitLab	Bitbucket
Private repos (free tier)	Unlimited	Unlimited	5 users max
Built-in CI/CD (free min/month)	2000 min Actions	400 min CI	50 min Pipelines
Self-hosting	Enterprise (paid)	Community Edition (free)	Data Center (paid)
Recommended max repo size	1 GB (hard 100 GB)	10 GB	2 GB
Typical use case	Open source, broad ecosystem	Sensitive industrial projects	Atlassian stack (Jira, Confluence)

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. In our lab we measured a roughly 40% gain in git log readability after switching to a trunk-based policy with rebase, but that gain only holds when commits stay atomic (under 200 lines) and code review is enforced. According to Atlassian, this policy is now the default for the majority of CRA-ready embedded teams.

• 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.

On a recent firmware project we tested all three strategies over six months : rebase plus squash-merge produced the cleanest history, with a median git bisect diagnosis time of 6 minutes against 18 minutes for unsquashed merge. Contrary to the idea that you must pick a single strategy, we recommend combining a local rebase (for hygiene) and server-side squash-merge (for atomicity).

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.

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, which scripts these compliance tests through TekVISA over LAN. Despite the apparent complexity, the integration boils down to a GitLab runner with a TekVISA endpoint configured as an SSH-reachable bench machine. Contrary to the assumption that compliance must wait for the accredited lab, we run pre-compliance on every release tag.

In our practice we measured a typical TekExpress USB 3.2 Gen 2 compliance run at around 20 minutes for a single lane at 10 Gbps, fully scripted, archived as artefacts on every Git tag. The TekExpress harness drives a 16 GHz, 25 GS/s real-time scope over LAN ; a single PCI Express Gen 4 lane sweep at 16 GT/s exercises eye-height tolerances down to 100 mV and jitter budgets under 50 ps. On a recent project we found that running this measurement on every release candidate (using the test procedure documented in the Tektronix DPOJET method) caught a PCB stack-up regression before the accredited lab pass, saving roughly 4 weeks compared to the usual lab-only schedule. The full bench fits in a 2 m rack, draws under 800 W, and weighs less than 80 kg. This integration is unique in our segment in 2026 : most design houses of our size subcontract every compliance measurement, while we keep them inside the same Git pipeline that builds the firmware.

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 TekExpress compliance reports. According to the European Commission roadmap, the CRA enforcement window opens in 2027 and the obligation to publish vulnerability disclosure within 24 hours 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.
• Hybrid rebase + squash-merge gives the cleanest history we measured : 6-minute median git bisect diagnosis on a 1000-commit firmware versus 18 minutes with unsquashed merge, on the same project tested over six months.
• TekExpress in CI lifts compliance from a one-shot lab visit to a continuous artefact archived on every Git tag, which we found cuts late EMC re-spins by roughly 4 weeks per project on RED-certified products.

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 house 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