我正在为我的 Python 包管理器使用诗歌，但我相信这将适用于任何编程实践。
我一直在做这件事，但不知道我在做什么，或者我应该怎么做。
当您使用包管理器并安装新包时，通常会.lock更改文件以保持构建确定性。
通常，我会提交这些更改，例如：
$ git add poetry.lock pyproject.toml
$ git commit -m "Install packages: beautifulsoup4"
即，我每次安装/删除软件包时都会提交。我这样做是因为我觉得这是我应该做的，但我有 0 线索，如果这实际上是处理这个问题的正确方法。
我做得很好吗？还是我应该遵守任何其他特定的约定和规则以使其尽可能接近最佳实践？
如果您开发可部署的应用程序（而不是库） ，诗歌维护者的官方建议是提交锁定文件。
话虽如此，我的个人经验是没有必要向 VCS 提交锁定文件。该pyproject.toml文件是正确构建说明的参考，而 lockfile 是单个成功部署的参考。现在，我不知道规范poetry.lock是什么，但在与同事合作期间，我经常让它们适得其反，因为只有删除它们才能解决问题。
一个常见的问题是，使用不同的操作系统或 python 版本会导致不同的锁文件，这就是行不通。我很乐意让我们的 CI 构建并保留一个权威的引用锁定文件以启用重新构建，但它仍然不会提交到存储库。
如果根据您的工作流程维护共享锁定文件是可行的 - 太好了！您避免了流水线中的一步，减少了需要担心的工件，并大大减少了构建时间（即使是中等规模的项目也可能需要几分钟才能完成完整的依赖关系解析）。
但就最佳实践而言，我会考虑添加比您所做的更好的实践，并且仅poetry.lock在添加.gitignore依赖项时提交更改。pyproject.toml
Poetry 实际上在他们的网站上有一个关于此的部分：https ://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
他们认为实际提交这个文件很重要，因为这将显示提交时使用了哪些版本的库。
将此文件提交给 VC 很重要，因为它会导致设置项目的任何人使用与您正在使用的依赖项完全相同的版本。您的 CI 服务器、生产机器、团队中的其他开发人员，所有东西和每个人都运行在相同的依赖项上，这减少了仅影响部分部署的错误的可能性。即使您独自开发，在六个月后重新安装项目时，您可以确信安装的依赖项仍然有效，即使您的依赖项从那时起发布了许多新版本。（请参阅下面有关使用更新命令的说明。）
对于库，不需要提交锁定文件。
将您的
poetry.lock文件提交给版本控制。将此文件提交到 VC 很重要，因为它会导致设置项目的任何人使用与您正在使用的依赖项完全相同的版本。您的 CI 服务器、生产机器、团队中的其他开发人员，所有事物和每个人都运行在相同的依赖项上，这减少了仅影响部分部署的错误的可能性。即使您单独开发，在六个月后重新安装项目时，即使您的依赖项发布了许多新版本，您也可以确信安装的依赖项仍然有效......对于库，没有必要提交锁定文件。
但是，如果您的团队使用不同的操作系统、硬件/CPU 类型等，并且您没有使用 Docker 等容器技术进行开发。我建议不要提交锁定文件，因为这会给团队带来很多问题。如果您的团队使用 Docker 构建，那很好。例如，如果您的锁定文件包含有关专门为 Linux 构建的库的信息，那么 [从锁定文件安装] 在 Windows 上会成为问题。