Product Lifecycle Management in Git. Parts, BOMs, and releases live in plain text files next to your design, with the full history and review workflow you already use for code.
Every product comes down to the same handful of facts: which parts go into it, where those parts come from, and what changed between one revision and the next. Most teams keep those facts in spreadsheets, shared drives, and email threads, where they drift apart. The alternative has usually been a PLM system that costs more to run than the products it tracks.
GitPLM takes a third path. A partmaster in CSV, a BOM per assembly, a short YAML script that says how a release is built, all committed to Git. Your tools do the tedious work from there: merging manufacturer data into BOMs, expanding sub-assemblies, gathering everything manufacturing needs into one directory.
Hardware, firmware, and mechanical design then share one source of truth, with a complete record of who changed what and why.
| Repository | What it is |
|---|---|
| gitplm | The tool. A single Go binary that generates release BOMs, expands assemblies, runs release scripts, and serves parts to KiCad. |
| parts | A shared, verifiable parts database with the KiCad libraries to match, plus a detailed guide to part numbering. |
| 3d-models | 3D models for use in KiCad. |
Download a release for your platform. The binary is self-contained, so there is nothing else to install.
gitplm # browse and edit the parts database in the terminal
gitplm release ASY-023-0004 # build a release directory for an assembly
gitplm http # serve the parts database to KiCadThe gitplm README walks through part numbers, the partmaster, release scripts, and the KiCad HTTP library support.
- Do it once. Anything tedious enough to repeat is work a program should do.
- Text files hold up. CSV and YAML can be edited by hand, opened in a spreadsheet, generated by a script, and reviewed line by line in a pull request.
- History matters. Knowing what changed, and being able to talk about it before it ships, is most of what a PLM system is for.
- Versions are cheap. Increment them freely, and keep every one.
- Stay tool independent. A parts database should outlive any single CAD package.
- Small teams first. The parts a company uses fit comfortably in memory, so a design that suits a small team can stay simple.
Issues and pull requests are welcome in any of the repositories above. If you are working out how GitPLM fits your process, open an issue or a discussion. We are glad to help think it through.
GitPLM is developed by BEC Systems. The tool is released under the Apache 2.0 license and the parts database under the MIT license.