[{"data":1,"prerenderedAt":167},["ShallowReactive",2],{"blog:en:git-for-field-data":3},{"id":4,"title":5,"author":6,"body":7,"date":153,"description":154,"extension":155,"meta":156,"navigation":157,"path":158,"seo":159,"stem":160,"tags":161,"__hash__":166},"blog_en/blog/git-for-field-data/en.md","Git for Field Data","Aptli",{"type":8,"value":9,"toc":143},"minimark",[10,15,19,22,26,29,36,42,48,52,55,61,67,73,79,85,89,92,95,98,101,104,108,111,114,117,121],[11,12,14],"h2",{"id":13},"the-concurrency-problem","The Concurrency Problem",[16,17,18],"p",{},"Software developers have been editing the same files at the same time since the 1970s. Two people change the same function. One pushes first. The other gets a merge conflict. This problem was solved so thoroughly that every developer alive today uses the solution without thinking about it: version control. Stage your changes. Commit when ready. If someone else changed the same thing, the system flags it and you resolve the conflict before anything goes live.",[16,20,21],{},"Field data has the same problem. Two crews edit features in the same area. One is underground with no connectivity. The other is across town on a spotty cell signal. Both come back online and submit their changes. If the system does not detect the overlap, one crew's work silently overwrites the other's. If the system locks records to prevent conflict, nobody can work offline at all. These are the same tradeoffs software teams faced before version control — and most field software is still stuck there.",[11,23,25],{"id":24},"how-most-field-software-handles-this","How Most Field Software Handles This",[16,27,28],{},"There are three common approaches, and each has a cost.",[16,30,31,35],{},[32,33,34],"strong",{},"Last write wins."," The simplest and most dangerous. Both users edit. Both submit. The second submission overwrites the first with no warning. The first user's work is gone. This approach is disturbingly common in field software that was designed for single-user operation and later bolted on multi-user support. It works right up until it does not, and when it fails, the failure is silent.",[16,37,38,41],{},[32,39,40],{},"Record locking."," The system locks a feature when someone opens it for editing. Nobody else can edit until the lock is released. This prevents conflicts by preventing concurrency — which also prevents offline work entirely. If a field worker locks a feature and then enters a subway tunnel for four hours, that feature is frozen for the entire team. Record locking trades data integrity for operational paralysis.",[16,43,44,47],{},[32,45,46],{},"Conflict avoidance through territory."," Assign each crew a geographic zone and trust that they stay in it. This works if the zones never overlap, the boundaries are always respected, and no feature spans a boundary. In practice, zones overlap at every intersection, boundary, and shared infrastructure corridor. The approach works in theory and fails at edges — which is where most of the interesting work happens.",[11,49,51],{"id":50},"the-version-control-model","The Version Control Model",[16,53,54],{},"Our approach borrows directly from how software teams work. The concepts map one to one.",[16,56,57,60],{},[32,58,59],{},"Drafting is local."," When a field worker edits a feature — moves a point, reshapes a line, updates properties — the change is stored in their browser. It is not visible to anyone else. This is the equivalent of editing a file on your local branch. The worker can undo, redo, and continue editing without affecting the shared dataset. An uncommitted changes badge tracks how many edits are pending, the same way a developer tracks unstaged changes.",[16,62,63,66],{},[32,64,65],{},"Submitting is committing."," When the worker is ready, they click Submit. All pending changes are pushed to the server as a single version — a coherent set of changes with a timestamp and the submitter's identity. This is a commit. It is atomic: either all changes go through or none do.",[16,68,69,72],{},[32,70,71],{},"Admin review is code review."," For non-admin field workers, Submit does not publish directly. It creates a version flagged for review. An administrator opens the review queue, sees the diff — what changed, where, and how it compares to the current state — and either approves or rejects. This is a pull request. The shared dataset does not change until someone with authority says it should.",[16,74,75,78],{},[32,76,77],{},"Conflict detection is merge checking."," When a version is submitted, the server checks whether anyone else has edited the same features or the same geographic area since the submitter last synced. If there is overlap, the conflict is flagged. Both versions are visible — the submitter's changes in blue, the other user's in orange — and the team resolves the conflict explicitly. No silent overwrites. No data loss.",[16,80,81,84],{},[32,82,83],{},"Version history is the commit log."," Every committed version is preserved — who submitted it, when, what changed, and who approved it. Versions are compressed over time but never deleted. You can reconstruct the state of any feature at any point in its history. The version log is the audit trail, the undo mechanism, and the institutional memory, all in one.",[11,86,88],{"id":87},"what-this-looks-like-in-practice","What This Looks Like in Practice",[16,90,91],{},"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.",[16,93,94],{},"Crew A finishes and comes back online. They submit their version. The server accepts it — no conflicts, because nobody else has changed those features since Crew A last synced. The admin reviews the diff, confirms the cable route changes make sense, and approves. The changes go live.",[16,96,97],{},"Crew B surfaces an hour later and submits. The server detects that two of their splice point edits overlap with features that Crew A already modified. A conflict warning appears. Crew B opens the conflict view and sees both versions — their edits in blue, Crew A's committed state in orange. They adjust their splice points to account for Crew A's cable route changes, resubmit, and the admin approves the resolved version.",[16,99,100],{},"Total data lost: zero. Total time spent on manual reconciliation: minutes. Total features silently overwritten: zero.",[16,102,103],{},"Compare this to the alternatives. With last-write-wins, Crew B's submission would have quietly overwritten Crew A's cable route changes. With record locking, one crew would have been unable to edit while the other was underground. With territory-based avoidance, the overlapping section would have been a coordination nightmare handled over phone calls and spreadsheets.",[11,105,107],{"id":106},"offline-first-not-offline-tolerated","Offline First, Not Offline Tolerated",[16,109,110],{},"A common misconception is that offline support means gracefully degrading when the network drops. That framing assumes online is normal and offline is an exception to be handled. In field operations, the opposite is true. Connectivity is intermittent by default — basements, tunnels, rural areas, construction sites with no signal. A system that treats offline as an exception will spend most of its time in exception mode.",[16,112,113],{},"Version control inverts this. Offline is the default working state. Every edit is local until you decide to submit. The network is needed only for two things: pushing your changes to the server, and pulling the latest state from others. Between those two events, you work independently with full editing capability. When connectivity returns, you sync — and the system handles the rest.",[16,115,116],{},"This is why the model works. It was not designed to handle offline as a special case. It was designed around the assumption that users are usually offline and occasionally connected — which is exactly how field work operates.",[11,118,120],{"id":119},"summary","Summary",[122,123,124,128,131,134,137,140],"ul",{},[125,126,127],"li",{},"Field data management has the same concurrency problem that software development solved decades ago: multiple people editing the same thing, often without connectivity, with the risk of silent overwrites.",[125,129,130],{},"Last-write-wins causes silent data loss. Record locking prevents offline work. Territory-based avoidance fails at every boundary and overlap.",[125,132,133],{},"The version control model — local drafts, atomic commits, admin review, conflict detection, permanent history — maps directly from software development to field operations.",[125,135,136],{},"Field edits are stored locally until the worker submits. Non-admin submissions go through a review queue. Conflicts are detected on the server and surfaced for explicit resolution — no silent overwrites, no data loss.",[125,138,139],{},"Every committed version is preserved with submitter, timestamp, and approver. Version history is compressed but never deleted. Any feature's state can be reconstructed at any point in time.",[125,141,142],{},"Offline is the default working state, not an exception to be handled. The system assumes users are usually disconnected and occasionally sync — which matches how field work actually operates.",{"title":144,"searchDepth":145,"depth":145,"links":146},"",2,[147,148,149,150,151,152],{"id":13,"depth":145,"text":14},{"id":24,"depth":145,"text":25},{"id":50,"depth":145,"text":51},{"id":87,"depth":145,"text":88},{"id":106,"depth":145,"text":107},{"id":119,"depth":145,"text":120},"2026-05-07","Software development solved concurrent editing decades ago — staging, committing, conflict detection, code review. Field data has the same problems. We applied the same solution.","md",{},true,"/blog/git-for-field-data/en",{"title":5,"description":154},"blog/git-for-field-data/en",[162,163,164,165],"version-control","offline","conflict-detection","field-operations","dQpu40re3HwRyEIeRblmceHniHKYQ-9H0-HBx-dXgVg",1780338684971]