Conscious Source Control – A Simple Team Version Control Model for Three Equal Developers
We are currently three equal developers working on a larger legacy/FiveWin-based codebase. Our main challenge was not tooling, but team coordination: how to manage version control in a small team where everyone can modify source code and integrate changes.
Instead of introducing a full Git workflow, we designed a lightweight, controlled process that fits our environment and responsibilities. We call it Conscious Source Control (CSC).
The core idea is simple.
There is one single Source of Truth (S:). This is the only accepted and valid state of the system. It is never modified casually. Updates happen deliberately, after verification, and during a short integration lock.
Each developer has a personal baseline (G:). This is not a shared repository, but an individual comparison and integration level. Development itself happens in a separate working copy — never directly on the Source of Truth.
The workflow looks like this:
Before starting work, a developer audits their personal baseline against the Source of Truth and updates it if necessary. Development then takes place in the working copy. When finished, changes are moved to the personal baseline and verified (file comparison, optional line-by-line review). Only after that, and with a short lock, the baseline is integrated back into the Source of Truth.
An important detail in our case is that the complete development environment (FiveWin, Harbour, compiler, libraries, tools) is part of the source tree. All three developers use exactly the same setup to avoid “works on my machine” situations.
For verification, we use a PowerShell-based audit script that compares source and target recursively. It checks file existence, size, timestamp (with tolerance), and calculates hashes only where meaningful (recent source files). Temporary build artifacts are removed before comparison.
The goal is not automation, but control. No silent merges, no implicit overwrites, no hidden state changes. Every integration step is deliberate and verifiable.
For a small team working on legacy systems with a shared toolchain, this model has proven stable, understandable, and predictable.
It may not replace Git in larger environments, but for our scenario it provides exactly what we need: controlled team version management without unnecessary process overhead.
