Low-code in Git

Low-code platforms solve a real problem: building line-of-business apps faster, without starting every form from scratch. The problem they trade for it is rarely mentioned — version control.

The core problem

Servoy stores UI, data model and part of the logic in a mix of JSON and proprietary files per form. Technically, that’s text-based and therefore git-friendly. Practically, a diff between two form versions is often a wall of reordered properties, where the one actual content change gets lost in the noise.

The real goal isn’t “somehow get this into Git” — that part is trivial. The goal is a diff a second developer can actually read during review, without re-rendering the entire file in their head first.

What actually helps

A few things that make a real difference:

• Deterministic serialisation. Property order and formatting must be identical on every save — otherwise every diff is a noise diff, even without a content change.
• One element per line, where possible. Getting closer to “one object, one line” gets you closer to a genuinely readable textual diff.
• Pre-commit normalisation. A small script that brings solution files into a consistent format before every commit saves endless review discussions about formatting diffs.
• Ownership per form, not per solution. Smaller, clearly owned units of change significantly reduce merge conflicts in a low-code environment.

None of this turns Servoy into a classic code repository. But it’s the difference between “code review as a ritual” and “code review that actually catches bugs”.