Git 用于现场数据

并发问题

自20世纪70年代以来，软件开发人员就一直同时编辑相同的文件。当两人修改同一个函数时，先提交的一方会导致另一方遇到合并冲突。版本控制系统彻底解决了这个问题，以至于每位开发人员都已习以为常：将更改暂存，准备就绪后提交，并在代码发布前解决任何冲突。

现场数据也具有同样的结构。两支工作组在同一区域编辑要素。其中一支在地下作业，无法联网；另一支则在城另一端，信号时断时续。两支工作组重新连接网络后，分别提交了各自的修改。系统必须保留两支工作组的工作成果，并显示它们的重叠部分。

字段编辑需要什么

字段编辑需要同时满足三个条件。

无需信号即可工作。 摄制组可在地下或信号覆盖范围外进行剪辑，剪辑内容会保存在设备中，待网络连接恢复后再同步。

所有编辑内容均被保留。 两个团队在同一区域进行编辑时，双方的工作都会被保留，且在任何内容最终确定之前，重叠部分会先显示出来。

共享区域始终保持共享。 团队在需要施工的地方开展工作，而交叉口、通道和共享基础设施则始终可供所有有需要的人进行编辑。

版本控制模型

Aptli借鉴了软件团队的工作方式，这些概念与之完全对应。

保存操作是本地化的。 现场工作人员的编辑操作（移动点、调整线段形状、更新属性）会保存到设备上的工作版本中，就像在本地分支上进行编辑一样。撤销和重做操作在整个会话中生效，且会有一个计数器显示待处理的更改数量。

上传即推送。 当工作者准备就绪时，Upload 会将工作版本作为一组更改发送至服务器，其中包含时间戳和工作者的名称。

审批即代码审查。 提交操作会发送该版本并请求审批。审批人查看了哪些地方发生了变更，然后将其提交，或者附上备注后退回。当审批人提交后，共享地图就会随之更新。

**冲突检查即合并检查。**在某个版本合并之前，Aptli 会检查是否有人对相同的功能进行了修改。一旦发现冲突，系统会标记出来，同时显示两组修改内容，由团队明确解决该冲突。

版本历史即提交日志。 每个已提交的版本都会记录提交者、提交时间、修改内容以及审批人。已提交的版本可以恢复，且恢复操作需像其他任何变更一样经过审批。

实际应用中的表现

有两支施工队正在同一光纤网络上作业。A组正在现场编辑北部区域的电缆路线。B组正在地下编辑中部区域的熔接点。两组均处于离线状态。

A组完成工作，重新连接后提交了他们的版本。其他人都没有修改过这些功能。审批人审查了线缆路径的变更，并将其提交。

一小时后，B组重新连接并提交了修改。其中两个接头点的修改与A组已修改的内容重叠，Aptli因此标记了冲突。B组查看了两组修改内容，将接头点调整为与A组的电缆路线一致，然后再次提交。审批人将已解决的版本提交到代码库。

两支团队都保住了工作。数据核对只需几分钟，而且每次数据重叠都在落地前就被发现了。

专为离线工作而设计

在实地工作中，网络连接时有时无：地下室、隧道、乡村道路、建筑工地。一个实地系统每天有很长一段时间处于离线状态。

版本控制机制使这种状态成为常态。每次编辑都会保存在设备上，直到后台进程上传为止。网络连接仅需两次：一次用于发送更改，一次用于从其他用户处获取最新数据。在这两次操作之间，后台进程拥有完全的编辑权限；当网络连接恢复时，同步操作随即运行。

该模型从实地工作的实际运作方式出发：主要在离线状态下进行，偶尔连接网络。

摘要

• 现场数据存在软件开发领域几十年前就已解决的并发问题：多人同时编辑同一内容，且通常处于离线状态。
• 现场编辑需要在无信号的情况下进行，每次编辑的内容都会被保存，并保持共享状态。
• 版本模型（本地保存、上传、审批、冲突检查、持久化历史记录）直接将软件开发中的模式映射到了现场作业中。
• 编辑内容保存在设备上，直到工作人员上传。提交时需要审批，审批人可直接确认或附注后退回。冲突会显式提示以便解决。
• 每个已提交的版本都会记录提交者、时间及审批人，且已提交的版本可通过审批流程恢复。
• 该模型基于实地工作的实际运作方式：主要在离线状态下进行，仅偶尔连接网络。