低代码平台如何实现版本管理？

前言

低代码平台是一种利用可视化界面和拖拽功能来快速开发应用程序的工具，它可以减少手动编码的工作量，提高开发效率和质量。低代码平台通常提供了一系列的预构建模块、组件和服务，让开发者可以根据业务需求和逻辑来组合和配置，而不需要关心底层的技术细节。低代码平台也支持与其他系统和服务的集成，以及在不同的云环境或本地环境中部署和扩展应用程序。

在使用低代码平台开发应用程序的过程中，一个重要的问题是如何实现版本管理。版本管理是指对应用程序的源代码、配置文件、文档等进行跟踪和控制的过程，它可以帮助开发者记录和保存每一个版本的变化，方便进行回溯、比较、合并和恢复。版本管理也可以支持多人协作开发，避免冲突和错误，以及实现持续集成和持续交付的流程。

不同的低代码平台可能有不同的版本管理机制和工具，但是一般来说，它们都遵循以下的原则和步骤：

使用模型驱动的开发方法。低代码平台的核心特征之一是使用模型驱动的开发方法，即通过图形化的方式来定义应用程序的数据模型、业务逻辑、用户界面、流程等。这样，应用程序的源代码就会由模型生成，而不是由开发者手动编写的。这意味着，版本管理的对象是模型，而不是代码。
使用基于Git的版本控制系统。Git是一个分布式的版本控制系统，它可以让开发者在本地和远程仓库中存储和管理应用程序的版本。Git的优点是它可以支持分支、标签、合并、冲突解决、历史查看等功能，以及与其他开发工具和平台的集成。低代码平台通常会提供一个基于Git的版本控制系统，并且允许开发者使用自己的Git仓库，来管理应用程序的模型。开发者可以使用低代码平台的图形化界面或者命令行工具来执行Git的操作，如提交、推送、拉取、分支、合并等。
使用云端的协作和发布平台。除了使用Git来管理应用程序的版本，低代码平台还会提供一个云端的协作和发布平台，让开发者可以在一个统一的环境中进行项目管理、团队协作、反馈收集、测试、部署、监控等活动。云端的协作和发布平台可以与Git仓库进行同步，保证应用程序的版本一致性和安全性。开发者可以使用云端的协作和发布平台来创建、管理和切换不同的应用程序版本，如开发版、测试版、生产版等，以及在不同的环境中部署和运行应用程序，如公有云、私有云、混合云、本地环境等。

因此，低代码平台可以通过使用模型驱动的开发方法、基于Git的版本控制系统和云端的协作和发布平台来实现版本管理。这样，开发者可以更高效、更安全、更灵活地开发、维护和更新应用程序，同时保证应用程序的质量和稳定性。下面小编将以葡萄城公司的企业级低代码开发平台为例，给大家介绍一下低代码平台的版本管理都包含哪些内容。

低代码中的版本管理

一、为什么要做版本管理？

版本管理（Version Control）的本质是在管理更新的历史记录，也是在管理开发团队的直接工作成果。在软件工程诞生的初期，开发者管理的版本和最终用户看到的软件版本一致，这导致一个版本中包含的内容非常多。开发者无法针对其中的部分内容，比如一个页面、一个服务端命令进行回滚来快速定位问题，因此多个开发者一同开发时，也很难在第一时间将自己正在开发的内容和其他同事正在开发的内容及时合并起来进行自测，就会存在很大的风险。于是，版本管理的粒度开始细化，从管理软件的版本，到管理更细化的源代码（低代码的工程文件）的版本，从此软件工程中最重要的概念之一：版本管理就诞生了。从实践上看，在低代码中启用"协作工程"，引入软件工程中主流的版本管理技术，除了可以让多人协作开发同一个项目外，还可以让开发更有序，从而避免以下的风险：

硬盘文件损坏导致之前开发的工程无法打开；
无法确定和线上版本一致的工程，导致修改线上Bug后，出现预期外的结果。

二、低代码 vs Git

低代码开发与编码开发一样，都沿用了同一套Git版本管理机制。下表是关于低代码版本控制与Git的对比：

低代码的可视化操作	Git的概念和命令	说明	常见应用场景
协同工程	本地 repository
- 协作服务器地址	远程 repository（HTTPS）地址
- 分支	分支 branch
- 打开工程	克隆 clone	将远程repository的文件拉取到本地	在新的电脑上打开现有的工程
- 创建工程	强制推送 push --force	远程repository的文件被废弃，采用本地文件覆盖，通常用于初始化远程repository	创建一个工程后，将其上传到版本管理服务器
工程模块与状态	文件状态 status	查看变更的文件和放在缓存区（新增）的文件	检查哪些文件被锁定了，确认是谁锁定了这些文件
- 签出	N/A	低代码自行实现的文件锁定机制，其他开发者无法签出的已经标记为签出的文件修改文件时，设计器自动设置签出状态，用户也可以在【工程模块】页面手动签出	修改这个文件
- 签入	提交并推送 commit + push
未处理的变更	文件状态 status
提交历史	日志 log	查看远程分支的所有提交记录，以及每次提交中包含的全部内容
- 回滚到当前选择的版本	彻底回退 reset --hard	将远程分支彻底回退到某个版本，然后将该版本的文件拉取到本地，覆盖本地文件
- 当前选定的版本另存为	克隆 clone	将远程repository的文件拉取到本地，然后生成一个新的工程文件
获取最新版本	拉取 pull	获取远程文件，本地修改过的文件、放在缓存区（新增）的文件都会被保留
- 强制同步为最新版本	强制拉取 pull --force	本地文件被废弃，使用远程文件覆盖

三、建立版本管理规则

在开发过程中，推荐建立版本管理规则，确保所有开发人员了解和遵循这些规则：

【推荐】除非临时的实验项目，或学习、练习用项目，建议所有投入使用的项目都需要启用版本管理
【推荐】开发者需要为每一次提交的代码写"签入注释"
【推荐】在签入之前需要先【获取最新版本】，完成自测，确保功能无误后方执行签入操作
【推荐】在启用了多分支的项目中，除负责分支合并的开发者，其他人都不允许签入到master分支
【建议】除非必要，不要手动签出模块或页面，尽量减少签入的范围，以免影响其他人工作
【建议】团队成员间按照功能模块或前后端的方式进行分工，可有效避免签出时发生冲突
【建议】插件、服务端引入的编程扩展类库、前端引入的JavaScript文件等没有纳入设计器的版本管理，推荐在对应的开发工具（如Visual Studio）上做好版本管理

四、多分支管理实践

在项目发布上线后，团队在开发新版本同时，难免会需要对旧版本的Bug进行快速修复，因为这些Bug的修正工作可能无法推迟到新版本上线时。新版本开发的周期越长，在开发过程中需要对旧版本进行维护性Bug修正的风险就越大。面对这种情况，需要在版本管理的基础上，引入多分支管理，让新版本开发工作和旧版本维护工作可以分开避免互相干扰。

不同的开发团队在分支操作上有较大的差异性。下面展示的是一个简单易行的方案：

4.1 分支定义

Master：主分支，与线上环境同步，通常不允许开发人员对master分支进行签入
Develop：新版本开发的分支，从Master分支上创建，新版本上线时，由专人合并到Master分支
Hotfix：为修复重要Bug单独创建的分支，从Master分支创建，Bug修正上线后，由专人合并到Master分支

4.2 分支操作流程

场景	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