Why Revision Control Is Non-Negotiable in Medical Device Software Development
Version control is not just a best practice for medical device software — it is a regulatory requirement that directly supports your design history file, audit trail, and ability to respond to field issues.
Ask any experienced medical device engineer about the projects that went sideways, and a surprising number of the stories involve software that no one could fully account for. A firmware build that could not be reproduced. A bug fix that introduced a regression nobody caught because there was no baseline to compare against. A field complaint that took weeks to investigate because the exact code running in the device was unknown.
Revision control solves all of these problems. And in a regulated medical device context, it does something more important — it satisfies a core requirement of IEC 62304 and FDA design controls.
What IEC 62304 Actually Requires
IEC 62304 is the international standard governing medical device software lifecycle processes. Section 8 of the standard covers software configuration management, and it is unambiguous: you must identify software items under configuration control, control changes to those items, and maintain a record of the configuration of each released version of your software.
In plain terms, this means you need to know exactly what code is in every device you have ever shipped. You need to be able to reproduce any past release. And you need a documented trail of every change made to the software, who made it, when, and why.
A proper revision control system — Git being the most common today — provides all of this out of the box. A shared network drive does not.
The Design History File Connection
FDA design controls require a design history file (DHF) that documents the development history of your device. For software, the version control repository is a core part of that record. Commit messages, tags, branches, and merge history together form an auditable trail of how the software evolved from initial requirements through released product.
When an FDA investigator or notified body auditor reviews your DHF, they will want to see that changes to software were controlled and traceable to requirements. A well-maintained Git history — with meaningful commit messages tied to your change control process — provides exactly that evidence. A poorly maintained one, or worse, no version control at all, is a significant finding.
Branching Strategy for Regulated Software
For medical device firmware, we recommend a straightforward branching strategy that maps cleanly onto your change control process. Keep a protected main branch that represents released, verified software. Use feature branches for all development work. Require pull requests with at least one reviewer before merging to main. Tag every release with the version number that appears in your software version history document.
This is not bureaucracy for its own sake. The protected main branch means no unreviewed code ever makes it into a release. The pull request review is your peer review record. The release tag is the traceability link between your source code and your released device configuration.
Handling Bug Fixes in the Field
One of the clearest illustrations of why revision control matters is a field software update. A complaint comes in, you identify a defect, you need to issue a corrected firmware version. Without version control, you are starting from wherever the code happens to be today — which may include half-finished features, experimental changes, and other modifications that have nothing to do with the fix and have not been verified.
With proper revision control, you branch from the release tag of the version in the field, make the targeted fix, verify it in isolation, and release a new version with a clean and auditable history. The scope of the change is contained, the verification effort is proportional, and your regulatory documentation is straightforward.
What to Put Under Version Control
Source code is the obvious answer, but it should not stop there. Your hardware design files, PCB layout, mechanical CAD, test scripts, build system configuration, and documentation should all be under version control. When you are trying to reproduce a past hardware revision or understand why a design decision was made three years ago, having the full project history in one place is invaluable.
For firmware specifically, make sure your build system is fully scripted and committed to the repository. If reproducing a release requires tribal knowledge about which version of a compiler to use or which library path to set, that knowledge needs to be codified — in a build script, a Docker container, or at minimum a documented environment specification committed alongside the code.
Getting Started If You Are Not There Yet
If your team is not currently using revision control, starting is straightforward. Initialize a Git repository, import your current code, and begin committing every change with a meaningful message. The historical record starts from wherever you are today — it is never too late.
If you are early in a new device development program, now is the time to establish your configuration management process before the code base grows and the habits are set. The cost of setting it up correctly at the start is trivial compared to the cost of reconstructing history or responding to a regulatory finding later.
At SiGenix, configuration management is built into how we work from day one of every project. If you are starting a new medical device program or trying to bring an existing one into compliance, we are happy to help.