• 如果您熟悉版本控制，请跳到"建议"部分。只是想确保我们在同一页上，并且我们同意在何处使用版本控制，谢谢您 *

它（版本化）取决于业务结构和/或开发目的!

通常，版本控制几乎是通过以下方式完成的

以下是版本化实际上非常有用的方法
1.假设你创建了一个东西，其中每个版本都有自己的用法（例如pm2，jenkins或者甚至是java这样的语言）。
它曾被用于创建工具或自动化某个项目中的任务，现在您发布了它的新版本，该版本完全不支持以前版本的某些功能（不再支持弃用代码）。
方法：在这种情况下，一个人应该始终创建自己的产品的完整版本，并从一开始发布到最新的和超越，以便任何人使用它确保它的稳定性和可能需要的长期支持。
如果你的项目被认为是敏捷的（node.js等），那么把它缩小到major.minor.point发布模型将是最好的实践。

• • 优点：敏捷项目是以正确的方式完成的，而且肯定是唯一的解决方案**
• • 缺点：不适合预算低的小项目，而且肯定是大材小用**

1.您正在处理一个基于Scrum的项目（例如，像Uber这样的敏捷多平台项目），因此业务要求您每隔一段时间发布一个新版本，并且希望所有以前的版本都用于自己的文档目的。
方法：由于您只需要公开最新版本，其余的只是文档，甚至可能是合适的后备版本，可以通过仅标记每个发布并使用诸如Jenkins和Docker的自动化技术来使用major.minor.point发布模型，以便从版本控制获得最新代码并将其部署在诸如Kubernetes的编排技术上。您应该咨询您的开发团队，选择最适合您的部署方法。基本上，您只需要使用Git和Github等版本控制平台来进行文档处理。实际上，您也可以通过上述方式使用所有这些技术。关键是最终用户是否关心版本!

• • 优点：快速部署具有监控功能的敏捷应用程序**
• • 缺点：不适合预算较低的小型项目**

建议：

你有没有同时使用过bootstrap 5以及它的第四和第三版本？
如果是，则认为这是一个不充分的举措。
如果一个人（比如贾斯汀!）试图实现某种静态和本地版本控制，我会简单地建议他不要这样做，因为它带来了有限的报价，它的实际成本。
相反，Justin可以编写和改进他的代码，使其更加模块化，以便在多个地方使用。
如果我没有理解您的问题，或者您认为我可以提供更多帮助，请再次详细说明您的情况。（您的目标是什么，为什么，到目前为止您做了什么，问题在哪里）