Back to Blog

Git for Field Data

Software development settled concurrent editing long ago with staging, committing, conflict checks and code review. Field data has the same needs, and Aptli applies the same model.

version-controlofflineconflict-detectionfield-operations

The Concurrency Problem

Software developers have edited the same files at the same time since the 1970s. Two people change the same function, one pushes first, and the other gets a merge conflict. Version control settled it so thoroughly that every developer uses it without thinking: stage changes, commit when ready, and resolve any overlap before anything goes live.

Field data has the same shape. Two crews edit features in the same area. One is underground with no connectivity, the other across town on a patchy signal. Both reconnect and send their changes. The system has to keep both crews' work and show where they overlap.

What Field Editing Needs

Field editing needs three things at once.

Work without a signal. A crew edits underground or out of range, and the edits wait on the device until the connection returns.

Every edit kept. Two crews editing the same area both keep their work, and the overlap shows before anything lands.

Shared ground stays shared. Crews work where the work is, and intersections, corridors and shared infrastructure stay editable by everyone who needs them.

The Version Control Model

Aptli borrows how software teams work, and the concepts map one to one.

Saving is local. A field worker's edits (moving a point, reshaping a line, updating properties) save into a working version on the device, like editing on a local branch. Undo and redo run across the session, and a count shows how many changes are waiting.

Uploading is pushing. When the worker is ready, Upload sends the working version to the server as one set of changes, with a timestamp and the worker's name.

Approval is code review. Submit sends the version and asks for approval. An approver sees what changed and where, then commits it or sends it back with a note. The shared map changes when the approver commits.

Conflict checks are merge checks. Before a version lands, Aptli checks whether anyone else has changed the same features. An overlap is flagged, both sets of changes show, and the team resolves it explicitly.

Version history is the commit log. Every committed version records who submitted it, when, what changed and who approved it. A committed version can be restored, and the restore goes through approval like any other change.

What This Looks Like in Practice

Two crews are working on the same fibre network. Crew A is in the field editing cable routes in the northern section. Crew B is underground editing splice points in the central section. Both are offline.

Crew A finishes, reconnects and submits its version. Nobody else has changed those features. The approver reviews the cable route changes and commits them.

Crew B reconnects an hour later and submits. Two of its splice point edits overlap features Crew A already changed, and Aptli flags the conflict. Crew B sees both sets of changes, adjusts its splice points to Crew A's cable routes and submits again. The approver commits the resolved version.

Both crews keep their work. Reconciliation takes minutes, and every overlap was seen before it landed.

Built for Working Offline

Connectivity in field work comes and goes: basements, tunnels, rural roads, construction sites. A field system spends much of its day offline.

Versions make that the normal state. Every edit stays on the device until the worker uploads. The network is needed twice: to send changes and to pull the latest from others. Between those moments the worker has full editing, and when the connection returns, the sync runs.

The model starts from how field work runs: mostly offline, connected now and then.

Summary

  • Field data has the concurrency problem software development settled decades ago: several people editing the same thing, often without connectivity.
  • Field editing needs work without a signal, every edit kept and shared ground that stays shared.
  • The version model (local saves, uploads, approval, conflict checks, lasting history) maps directly from software development to field operations.
  • Edits save on the device until the worker uploads. Submitting asks for approval, and an approver commits or sends back with a note. Conflicts surface for explicit resolution.
  • Every committed version records its submitter, time and approver, and a committed version can be restored through approval.
  • The model starts from how field work runs: mostly offline, connected now and then.