The Problem
Let’s imagine a device in the field that’s been running stable for five years. One bug appears—and yes, it’s fixed in your latest library version. But that version also bundles numerous new features and breaking changes your product can’t absorb.
With traditional Git, your only option is a full-library upgrade—solving one bug but risking ten more.
You’re trying to fix one issue—and you end up juggling everything else.
Two Simple Rule Changes
GitTrim introduces a paradigm shift—small technical changes with big impact:
- 📄 Each file gets its own version inside Git.
- 🔗 When you bump a file’s version, dependent files auto-bump too.
This means you can patch legacy systems surgically—without dragging in features you don’t need.
Project Package
Instead of updating an entire library, generate a project package by cherry-picking only the function versions you need. Legacy support remains untouched while new development continues freely.
How it Works
git trim bump src/encoder.py
# → encoder.py bumped to 1.2.0
# → image_pipeline.py auto-bumped to 3.5.0
Traditional vs GitTrim File-Level Versioning (Flow Diagram)
Initial (before update)
Each file at previous working versionV1 | V2 | V3 | V4 | |
---|---|---|---|---|
File A | ||||
File B | ||||
File C |
Conventional (after update)
Full version bump of the entire libraryV1 | V2 | V3 | V4 | |
---|---|---|---|---|
File A | ||||
File B | ||||
File C |
GitTrim (after update)
Only changed file and its version is bumpedV1 | V2 | V3 | V4 | |
---|---|---|---|---|
File A | ||||
File B | ||||
File C |
Automated Service Features
- 🔍 Call-site analysis: scan your repo for changed signatures and dependencies.
- 🚩 Git hook integration: trigger on commit or in CI to enforce version rules.
- 📦 Extraction by version or project theme for tailored packages.
- 🛠️ Work-in-progress toggle to disable checks during rapid iteration.
Built For…
- 🏭 Industrial & factory automation
- 🧬 Medical & embedded devices
- 💼 Shared internal frameworks
- 🔧 Legacy support teams