版本管理：通过版本管理让开发更有序
推荐阅读
技术决策者 | 项目经理 | 高级技术人员 | 初级技术人员 | 测试人员 |
|---|---|---|---|---|
√ | √ |
type=info
版本管理是数十年软件工程实践中沉淀下的经验，不论您的项目规模和团队人数，都强烈推荐通过启用“协同工程”进行版本管理。
一、为什么要做版本管理？
版本管理（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 | 本地文件被废弃，使用远程文件覆盖 |
总之，活字格与Git的最大差异有以下几点，对版本管理操作进行了一定程度的简化：
在活字格中，不允许多人修改同一个文件，这意味着提交时无需进行合并（merge）
您无法在活字格中操作本地repository，提交（commit）和推送（push）两个操作是绑定在一起的
实用教程：
三、建立版本管理规则
在开发过程中，推荐您建立版本管理规则，确保所有开发人员了解和遵循这些规则。在团队运营初期或新人加入时，需要投入一定的人力对这些规则的贯彻程度进行检查。
【推荐】除非临时的实验项目，或学习、练习用项目，所有投入使用的项目都需要启用版本管理
【推荐】除了活字格工程，数据库也应该纳入版本管理的范围，了解详情：如何创建、修改并发布外联库的表结构和内置数据？
【推荐】开发者需要为每一次提交写“签入注释”
【推荐】在签入之前需要先【获取最新版本】，完成自测，确保功能后无误后方执行签入操作
【推荐】在启用了多分支的项目中，除负责分支合并的开发者，其他人都不允许签入到master分支
【建议】签入频率根据团队技术能力和习惯而定（新人建议完成一个功能点或模块后，经高级开发人员检查无误再签入），但每1/2天必须将全部新增/修改的文件签入至少一次，以免磁盘故障等原因导致工作损失
【建议】除非必要，不要手动签出模块或页面，尽量减少签入的范围，以免影响其他人工作
【建议】团队成员间按照功能模块或前后端的方式进行分工，可有效避免签出时发生冲突
【建议】外联库的数据表设计没有纳入设计器的版本管理，推荐有专人负责维护开发、测试和生产环境数据库的结构，修改时通知给全开发团队
【建议】插件、服务端引入的编程扩展类库、前端引入的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 |
分支合并的具体操作，详见：易学技巧
4.3 分支操作技巧
为了避免误操作，推荐将master分支设置为“保护分支”
将其他分支合并到master时，推荐采用git服务器提供的pull request机制，可视化操作，不易出错
查找提交历史记录时，建议采用git服务器提供的“提交历史”页面，当前develop分支创建之前的历史，都存放在master分支
type=info
温馨提示
企业级低代码开发最佳实践是活字格官方面向进阶开发者推出的产品技术资源，旨在帮助对活字格基本功能有一定了解的开发者快速提升应用开发能力，保质保量做好企业级项目交付。如果您是初次接触活字格，这些内容可能会有些艰深难懂，这也是正常的。如果您有软件开发经验，推荐您学习《面向程序员的活字格入门课程》；否则，您也可以免费报名参加新手训练营直播课程或购买阅读《低代码开发实战：基于低代码平台构建企业级应用》（机械工业出版社），快速上手低代码开发。