版本控制
在软件开发中，版本控制和协同工作通常基于一个名为“Git”的框架。文件在本地下载，在“暂存”之前进行修改，然后“提交”回它们产生的服务器。
该系统允许使用不同的代码库进行不同版本的分支，并且是完全可审计的——能够在分支中恢复更改。' Commits '需要有描述性的名称，以防止在没有严格的命名约定时经常遇到的问题，例如文件夹中充满' file_update 1 ' file_update 2， ' file_new version(2) '等。
虽然目前有一些项目正在尝试实现这样一个系统，用于结构模型、图纸等，但它们还不够成熟，不能用于日常使用。
在开发这些系统的过程中，工程师应该努力为版本控制维护一个合理的结构，通过前面描述的命名结构来方便区分版本。
常用的版本号后缀包括P(初步版本)、T(投标版本)、C(施工版本)，并按数字递增。P1是文件的第一个初步发布，P2是第二个，P3是第三个，以此类推。有些人可能会选择从P0开始。
版本号和后缀不应该很容易混淆，通常应该通过一些一致的文档来解释。例如，后缀P对某些专业来说可能意味着“初步”，对另一些专业来说意味着“生产”，因此后缀P1在合作时可能会无意中变得模糊。
更新日志
更改日志是一个文件(通常是纯文本)，它详细描述了文件或程序的特定版本中的更改。它们通常托管在可下载软件的网站上，或者在安装程序更新时以文本文件/消息的形式存在。
变更日志包括最新软件变更的细节，附加到先前的修改列表中，允许在模型的各个版本中跟踪变更，有效地充当了文件的修订表。
结构模型在两次修订之间可能会发生显著的变化，注意这些变化是什么，为什么会发生这些变化，以及谁做出了这些变化是一种良好的实践。
即使只有一个人在处理特定的模型，更改也常常会被遗忘，从而导致可能不准确的结果。这对于一个人在模型上工作了很长时间的情况来说尤其如此。
详细地记录版本之间的每一个变更可能是不实际的。如果50个节点被移动了一小段距离，那么模型或输出很少有显著变化。
但是，如果一个加载条件发生了变化，一个加载组合，成员或释放被移除或增加，等等，这些都应该在一个变更日志中被记录下来，以便于在一个结构方案中对结果进行简单的查询或不同选项的比较。
更新日志的方案应该是一致的，下面给出一个这样的更新日志的例子:
- 2020-02-29建筑系列图纸(日期20200226)后对几何的主要更新。许多变化。参阅指定的标记(20200229_jobno_markup -for-structural-model)，了解几何更改和成员删除/所需添加的详细信息。
- 对模型荷载进行小幅调整，增加了雨棚延伸带来的雪荷载。分析结果重新计算，力/力矩没有显著变化。
- 合并最新一套建筑图纸的变更(已收到20200229套)。几何修正;网格线L和G调整以适应新的图纸和节点调整以适应。F -3网格上的悬臂，从1000加长到1500，并重新设计。
从这些日期中可以清楚地看出模型的哪些部分发生了改变。在模型有大量更改的情况下，会引用模型文件中包含的一组扫描标记。