引言
客户是传统型研发+制造的企业，在软件源代码以及固件包版本配置管理这块，没有很熟悉的人！
故，需要给客户提供两种方案，进行比较！
基于Git类方案
软件源代码协同管理需求
1. 统一存储源代码：将源代码存储在一个专门的源代码存储服务器上，而不仅仅存在个人电脑上。这样可以确保源代码的统一性和备份。
编辑
2. 主从热备机制：源代码存储服务器应具备主从热备机制，以防止数据丢失和保证高可用性。
3. 分配权限：针对每个工程包，可以分配不同的权限给不同的人。权限包括代码拉取、更新、删除、新建仓库、代码合并提交等。
4. 历史修改记录：每个工程包中的每个文件都应该能够查看历史修改记录，包括时间、修改人和修改明细。
编辑
5. 回退功能：根据软件包对应的版本号或标签，应该具备回退功能，以得到当时发布包的一套源代码。
编辑
6. 比对功能：支持源代码的比对功能，能够比对出两个版本之间的源代码差异。
7. 分支版本管理：支持分支版本的功能，用于满足不同客户需求，并能够合并回主干版本。
编辑
8. 多人协同和冲突解决：系统应具备多人协同功能，能够处理源代码冲突和解决冲突的功能。
9. 源代码审查：系统应提供源代码review的功能，用以进行代码提交前和发布前的审批流程。
软件打包固件版本管理需求
1. 固件包管理：提供固件包的上传、下载、浏览查询和信息编辑功能。
编辑
编辑
2. 产品线管理：支持产品线功能，使固件包能够跟随产品线进行发布。
编辑
3. 审批流程：建立固件包审批流工程，流程涵盖研发、测试、工艺、生产和质量等环节。确保固件包经过严格的测试和审批流程后再安装到设备上。
编辑
4. 自动发邮件：固件包发布时应具备自动发邮件的功能，以通知相关人员。
5. 版本控制：为固件包实施版本控制，使用版本号或标签来标识每个固件包的不同版本。这样可以方便地进行版本管理和回滚操作。
6. 固件包权限管理：根据团队成员的角色和责任，分配不同的固件包权限，包括上传、下载、编辑等。确保团队成员只能访问和操作他们需要的固件包。
编辑
7. 固件包历史记录：记录每个固件包的上传、下载和修改历史，包括上传者、时间和操作内容。这样可以追踪固件包的变更历史和责任。
编辑
8. 固件包回滚：在固件包发布后，提供固件包回滚的功能，以便在出现问题时能够快速还原到之前的稳定版本。
编辑
9. 设备识别和固件包关联：为每个设备分配唯一的标识符，将设备与其对应的固件包进行关联。这样可以确保每个设备都有对应的正确固件包。还可以根据设备标识符快速查找设备信息和固件包版本。
10. 版本关系网：提供固件包顶级版本关系网功能，以便一键打包。
11. 主从热备机制：为防止数据丢失，固件包管理系统应具备主从热备机制。
基于传统加密软件方案
管控员工电脑
编辑
编辑
也支持文件版本控制管理
编辑
两种方案比较
自建git方案的优势
编辑
传统加密软件优势
编辑
两种方案比较完，客户就可以根据自己的情况，自行选择！
个人推荐git方案，非常讨厌传统加密配置类的软件，因为笔者曾经亲自盯过一整套加密软件的需求、定版本、部署、上线、装客户端、培训试用、最终投产的过程。加密软件用来做固件包的配置管理，想用来做固件版本控制，又想防员工外发泄密，非常扯淡！
打击积极性不说，也防不住真正想拿走资料的人。关键是给所有人，都带来了很多不必要的工作量。最最关键一点，加密软件的原理是基于驱动层的，相当于在每个员工电脑操作系统上，又加了一层，然后才是自己公司的资料沉淀，一旦沉淀着床，文件就进入他们的加密系统。整个公司都脱裤子暴露在人家那里，真的值得吗？为了你们那点窥私欲和管控欲？