引言
在当今快速发展的软件开发领域，低代码平台凭借其可视化界面和拖拽功能，极大地减少了手动编码的工作量，显著提高了开发效率和质量。它提供了丰富的预构建模块、组件和服务，让开发者能够根据业务需求和逻辑进行组合与配置，而无需关注底层的技术细节。同时，低代码平台还支持与其他系统和服务的集成，以及在不同的云环境或本地环境中部署和扩展应用程序。然而，在使用低代码平台开发应用程序的过程中，版本管理成为了一个至关重要的问题。版本管理不仅有助于开发者记录和保存每一个版本的变化，方便进行回溯、比较、合并和恢复，还能支持多人协作开发，避免冲突和错误，实现持续集成和持续交付的流程。
低代码平台版本管理的实现方式
模型驱动的开发方法
低代码平台的核心特征之一是采用模型驱动的开发方法。通过图形化的方式，开发者可以定义应用程序的数据模型、业务逻辑、用户界面、流程等。在这种模式下，应用程序的源代码由模型自动生成，而非开发者手动编写。这就意味着版本管理的主要对象是模型，而非代码。这种方式使得版本管理更加直观和高效，因为模型的变化更容易被追踪和理解。例如，在一个电商应用的开发中，开发者可以通过图形化界面定义商品的数据模型、订单的业务逻辑等，版本管理系统会记录这些模型的每一次修改，方便后续的回溯和比较。
基于 Git 的版本控制系
Git 作为一种分布式的版本控制系统，具有众多强大的功能，如支持分支、标签、合并、冲突解决、历史查看等，并且能够与其他开发工具和平台进行集成。低代码平台通常会提供一个基于 Git 的版本控制系统，允许开发者使用自己的 Git 仓库来管理应用程序的模型。开发者既可以使用低代码平台的图形化界面，也可以通过命令行工具来执行 Git 的操作，如提交、推送、拉取、分支、合并等。以一个团队开发的项目为例，不同的开发者可以在本地创建自己的分支进行开发，完成后将代码推送到远程仓库，通过合并操作将自己的代码集成到主分支中。这样可以有效地避免代码冲突，提高开发效率。
云端的协作和发布平台
除了使用 Git 进行版本管理，低代码平台还提供了一个云端的协作和发布平台。这个平台可以让开发者在一个统一的环境中进行项目管理、团队协作、反馈收集、测试、部署、监控等活动。它与 Git 仓库进行同步，确保应用程序的版本一致性和安全性。开发者可以使用这个平台创建、管理和切换不同的应用程序版本，如开发版、测试版、生产版等，并在不同的环境中部署和运行应用程序，包括公有云、私有云、混合云、本地环境等。例如，在一个企业级应用的开发过程中，开发者可以在云端的协作和发布平台上创建开发版进行功能开发和测试，通过测试后将其切换为生产版进行正式部署。
低代码中版本管理的必要性
在软件工程的早期，开发者管理的版本与最终用户看到的软件版本一致，这导致一个版本包含的内容过多。开发者难以针对部分内容进行回滚以快速定位问题，多人协作开发时也难以及时合并代码进行自测，存在较大风险。随着版本管理粒度的细化，从管理软件版本到管理更细化的源代码（低代码的工程文件）版本，版本管理应运而生。在低代码开发中启用 "协作工程"，引入软件工程中主流的版本管理技术，具有诸多重要意义。它可以避免硬盘文件损坏导致工程无法打开的问题，确保数据的安全性和可恢复性。同时，能够确定与线上版本一致的工程，避免修改线上 Bug 后出现预期外的结果，保证软件的稳定性和可靠性。
低代码与 Git 的对比
| 低代码的可视化操作 | Git 的概念和命令 | 说明 | 常见应用场景 |
|---|---|---|---|
| 协同工程 | 本地 repository | 低代码中的协同工程对应 Git 的本地仓库，用于存储和管理本地的应用程序版本 | 在新的电脑上打开现有的工程，开发者可以将远程仓库的文件克隆到本地，创建协同工程 |
| - 协作服务器地址 | 远程 repository（HTTPS）地址 | 协作服务器地址即远程仓库的地址，用于在低代码平台和远程仓库之间进行数据交互 | 创建一个工程后，将其上传到版本管理服务器，需要指定远程仓库的地址 |
| - 分支 | 分支 branch | 低代码和 Git 都支持分支功能，方便开发者进行并行开发和管理不同版本的代码 | 在开发新功能或修复 Bug 时，开发者可以创建新的分支进行开发，完成后再合并到主分支 |
| - 打开工程 | 克隆 clone | 将远程 repository 的文件拉取到本地，在低代码中表现为打开协同工程 | 在新的电脑上打开现有的工程，通过克隆操作将远程仓库的文件复制到本地 |
| - 创建工程 | 强制推送 push --force | 远程 repository 的文件被废弃，采用本地文件覆盖，通常用于初始化远程 repository | 创建一个新的工程并上传到远程仓库时，可能需要使用强制推送操作 |
| 工程模块与状态 | 文件状态 status | 查看变更的文件和放在缓存区（新增）的文件，低代码中可以检查哪些文件被锁定以及锁定者 | 检查哪些文件被锁定了，确认是谁锁定了这些文件，避免多人同时修改导致冲突 |
| - 签出 | N/A | 低代码自行实现的文件锁定机制，其他开发者无法签出已经标记为签出的文件，修改文件时，设计器自动设置签出状态，用户也可以在【工程模块】页面手动签出 | 修改某个文件时，先进行签出操作，确保只有自己可以修改该文件 |
| - 签入 | 提交并推送 commit + push | 将本地的修改提交到本地仓库，并推送到远程仓库 | 完成文件的修改后，进行签入操作，将修改保存到版本管理系统中 |
| 未处理的变更 | 文件状态 status | 查看未处理的变更文件 | 检查还有哪些文件的修改尚未提交到版本管理系统 |
| 提交历史 | 日志 log | 查看远程分支的所有提交记录，以及每次提交中包含的全部内容 | 了解项目的开发历史，查看每个版本的修改内容 |
| - 回滚到当前选择的版本 | 彻底回退 reset --hard | 将远程分支彻底回退到某个版本，然后将该版本的文件拉取到本地，覆盖本地文件 | 当发现某个版本出现问题时，可以回滚到之前的版本 |
| - 当前选定的版本另存为 | 克隆 clone | 将远程 repository 的文件拉取到本地，然后生成一个新的工程文件 | 需要保存某个特定版本的工程时，可以将其另存为一个新的工程文件 |
| 获取最新版本 | 拉取 pull | 获取远程文件，本地修改过的文件、放在缓存区（新增）的文件都会被保留 | 在进行开发前，获取最新的代码，确保自己使用的是最新版本 |
| - 强制同步为最新版本 | 强制拉取 pull --force | 本地文件被废弃，使用远程文件覆盖 | 当本地文件出现问题或需要与远程仓库保持完全一致时，可以使用强制拉取操作 |
建立版本管理规则
为了确保版本管理的有效性和一致性，在开发过程中建立版本管理规则是非常必要的。以下是一些推荐的规则：
- 除非是临时的实验项目或学习、练习用项目，建议所有投入使用的项目都启用版本管理。这样可以更好地管理项目的变更历史，提高项目的可维护性。
- 开发者需要为每一次提交的代码写 "签入注释"。详细的签入注释可以帮助其他开发者了解代码的修改内容和目的，方便后续的代码审查和维护。
- 在签入之前，需要先【获取最新版本】，完成自测，确保功能无误后再执行签入操作。这样可以避免将有问题的代码提交到版本管理系统中，影响其他开发者的工作。
- 在启用了多分支的项目中，除负责分支合并的开发者外，其他人都不允许签入到 master 分支。这样可以保证 master 分支的稳定性，避免因误操作导致的代码冲突和问题。
- 除非必要，不要手动签出模块或页面，尽量减少签入的范围，以免影响其他人的工作。合理控制签入范围可以降低代码冲突的风险，提高开发效率。
- 团队成员间按照功能模块或前后端的方式进行分工，可有效避免签出时发生冲突。明确的分工可以让开发者专注于自己负责的部分，减少代码冲突的可能性。
- 插件、服务端引入的编程扩展类库、前端引入的 JavaScript 文件等没有纳入设计器的版本管理，推荐在对应的开发工具（如 Visual Studio）上做好版本管理。这样可以确保这些外部资源的版本也得到有效的管理。
多分支管理实践
在项目发布上线后，团队在开发新版本的同时，可能需要对旧版本的 Bug 进行快速修复。为了避免新版本开发和旧版本维护工作之间的干扰，需要引入多分支管理。以下是一个常见的多分支管理方案：
分支定义
- Master：主分支，与线上环境同步，通常不允许开发人员直接签入。它是项目的稳定版本，代表着线上正在运行的代码。
- Develop：新版本开发的分支，从 Master 分支上创建。在这个分支上进行新功能的开发和测试，完成后将代码合并到 Master 分支。
- Hotfix：为修复重要 Bug 单独创建的分支，从 Master 分支创建。当线上出现紧急 Bug 时，在这个分支上进行修复，修复完成后将代码合并到 Master 分支和 Develop 分支。
分支操作流程
| 场景 | Master | Develop | Hotfix |
|---|---|---|---|
| 立项 | 专人创建 master 分支 | 专人从 master 创建 develop 分支 | |
| V1.0 的开发阶段 | 所有人在 develop 分支开发 | ||
| V1.0 发布 | 专人将 develop 合并到 master | ||
| V2.0 的开发阶段 | 所有人在 develop 分支开发 | ||
| V2.0 的开发过程中，发现需要紧急修复的 Bug | 专人从 master 创建 hotfix 分支 | ||
| 执行 Bug 修复 | 负责修复的开发者在 hotfix 分支开发 | ||
| Bug 修复版（V1.1）发布 | 专人将 hotfix 合并到 master | 负责修复的开发者参考 master 分支的做法，结合 V2.0 的功能，在 develop 分支上完成 bug 修复 | |
| V2.0 发布 | 专人将 develop 合并到 master |
低代码中协同操作步骤示例
在 Git 中复制代码链接
开发者需要在 Git 仓库中找到对应的项目，复制代码链接。这个链接将用于在低代码平台中创建协同工程。例如，在 Gitee 上的项目，开发者可以在仓库页面找到 HTTPS 或 SSH 链接，点击复制按钮将链接复制到剪贴板。
在低代码中创建协同工程
打开低代码设计器，在上方菜单栏中选择 "高级"，然后选择创建工程。在弹出的对话框中，输入协作服务器地址（即之前复制的 Git 代码链接）和分支名称，点击 "确定"。系统会进行身份验证，验证通过后将当前工程推送至对应仓库，成功创建协同工程。
对象协同化
创建协同工程后，在左侧的对象管理器中，可以看到每个独立的页面、母版页等都带有一个小锁的标志。当某个页面或其他元素被签出后，锁标志会变为绿色对勾，表示该元素正在被修改。
选择性提交未处理变更
在签入所有未处理变更时，开发者可以选择签入的部分，忽略无须签入的部分。这样可以更加灵活地管理代码的提交，避免不必要的代码变更被提交到版本管理系统中。
详细的提交历史
提交历史会详细记录每一位协同人员的签入信息，并且支持另存为、回滚任意版本。开发者可以通过查看提交历史了解项目的开发进度和每一次修改的内容，方便进行问题排查和版本回溯。
工程模块
在模块选项中，可以看到各个模块的状态，并会细化到低代码设计器中的各个功能点。这有助于开发者了解项目的整体结构和各个模块的状态，及时发现和解决问题。
打开协同工程
低代码平台支持开发人员打开已有的协同工程，随时随地加入协作人员，共同进行项目的开发。开发者只需输入协作服务器地址和分支名称，即可打开对应的协同工程。
结论
低代码平台通过模型驱动的开发方法、基于 Git 的版本控制系统和云端的协作和发布平台，实现了高效、安全、灵活的版本管理。版本管理在低代码开发中具有重要的意义，它不仅可以帮助开发者记录和保存每一个版本的变化，方便进行回溯、比较、合并和恢复，还能支持多人协作开发，避免冲突和错误，实现持续集成和持续交付的流程。通过建立合理的版本管理规则和采用多分支管理实践，可以进一步提高开发效率和项目的稳定性。同时，低代码平台提供的协同操作步骤使得团队协作更加便捷和高效。随着低代码技术的不断发展，版本管理将在软件开发中发挥越来越重要的作用，帮助企业更快地交付高质量的应用程序。