viz*_*zmo 10 git workflow large-files
我正在为我的公司维护一个半大型网站(几百页)。这是一个静态站点,有大量手动编写(即复制和粘贴)的 HTML,二进制资源散布在各处。这些资产包括产品图像、模拟视频、教程视频、固件文件、手册等,这些资产很少发生变化。理想情况下,它们都将存储在一个或几个系统中,以便可以系统地搜索和检索它们。唉,我们的世界并不理想,事实并非如此。这就是为什么以前的开发人员将所有这些文件的副本与代码一起放入站点的文件结构中。他的工作流程是在自己的 PC 上复制整个网站以进行更改并测试更改,然后通过 FTP 将其上传到 Web 服务器。没有版本控制。
当我接手时,我想引入版本控制,所以我把整个东西放在 Azure DevOps 上托管的 git 存储库中。我对大多数二进制文件使用了 LFS。整个存储库的大小现在约为 10 GB(包括 LFS 对象)。有一个部署管道,它只是克隆存储库并通过 FTP 上传整个内容。
最近,我的公司引入了本地 GitLab 安装,我与他们讨论了将存储库迁移到那里的问题。然而,他们现在不支持 LFS,并坚持认为我的工作流程不是 git 应该使用的方式。撇开我发现他们的推理过于教条这一事实不谈(大型二进制文件不应该在 git 中,尽管有 LFS。如果是的话,你就做错了。),我不否认我的工作流程离开了还有很大的改进空间。
他们建议将所有二进制资产放入外部存储解决方案(例如 Sharepoint)中,并在准备新网站时在 GitLab 中进行部署作业来拉取它们。
这让我想到了我的实际问题。鉴于这些情况:
遵循 GitLab 管理员的建议会有所改进吗?您认为作为网站维护者会给我带来什么好处吗?如果二进制资产不再是存储库的一部分,是否有办法跟踪与存储库历史相关的资产版本?
我希望这个问题足够具体,而不是一个简单的意见问题。
他们建议将所有二进制资产放入外部存储解决方案(例如 Sharepoint)中,并在准备新网站时在 GitLab 中进行部署作业来拉取它们。
实际上,通常的解决方案是将它们放入用于存储二进制文件的工件引用中。(Nexus或Artifactory)
您要进行版本控制的是pom.xml(例如)声明您需要的静态资产二进制文件的版本。
部署变为:
git restore来自裸存储库(快速,因为文件更少,更小)| 归档时间: |
|
| 查看次数: |
331 次 |
| 最近记录: |