• • 免责声明**

请参考this answer了解官方对这个主题的立场和理由，这应该是这个帖子的头条。下面是我最初的回答，我会保持原样。
诗歌维护人员的官方建议是，如果您开发的是可部署的应用程序（而不是库），则提交锁文件。
话虽如此，我个人的经验是，没有必要向VCS提交锁文件，pyproject.toml文件是正确的构建指令的参考，锁文件是一次成功的部署的参考，现在我不知道poetry.lock的规范是什么，但在与同事合作的过程中，我经常遇到它们适得其反的情况，只有删除它们才能解决问题。
一个常见的问题是，使用不同的操作系统或python版本会导致不同的锁文件，这是行不通的。我很乐意让我们的CI构建并持久化一个权威的引用锁文件，以支持重新构建，但它仍然不会提交到存储库。
如果在给定的工作流中维护共享锁文件是可行的--太好了!您避免了管道中的一个步骤，少了一个需要担心的工件，并大大减少了构建时间（即使是中等规模的项目也可能需要几分钟来完成完整的依赖关系解决方案）。
但是就最佳实践而言，我会考虑将poetry.lock添加到.gitignore中，这是一个比您所做的更好的实践，并且只在添加依赖项时提交pyproject.toml更改。

到目前为止，所有给出的答案都忽略了Poetry的锁文件与pip freeze等其他工具之间的一个重要区别：Poetry的锁文件是一个通用锁文件。
这意味着Poetry并不关心当前的环境，也不关心使用的Python版本，也不关心平台，而是确保依赖关系在pyproject.toml中给定的Python版本范围内是可解析的，这会产生一个锁文件，该文件在pyproject.toml中给定的Python版本范围内的任何平台上都有效。
与其他工具的不同之处在于，它会产生锁文件，这也是Poetry解析依赖关系较慢的原因。这也是为什么建议在vcs中签入poetry.lock的原因。这样做可以加快设置开发环境的速度，并确保环境是可复制的。

诗歌实际上有一个关于这个的部分在他们的网站上：https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
他们建议实际提交这个文件是很重要的，因为这将显示在提交时使用了所包含的库的哪些版本。
将此文件提交到VC非常重要，因为这将导致设置项目的任何人使用与您正在使用的依赖项完全相同的版本。您的CI服务器、生产计算机、团队中的其他开发人员、所有人都在相同的依赖项上运行，这降低了仅影响部署的某些部分的错误的可能性。即使您单独开发，在六个月内重新安装项目时，你可以确信安装的依赖项仍然工作，即使你的依赖项从那时起发布了许多新版本。2（参见下面关于使用更新命令的注解。3）
对于库，不需要提交锁定文件。

据维修人员说，
将您的poetry.lock文件提交到版本控制。将此文件提交到VC非常重要，因为这将导致设置项目的任何人使用与您使用的依赖项完全相同的版本。您的CI服务器、生产计算机、团队中的其他开发人员以及所有人都在相同的依赖项上运行。这减少了只影响部署的某些部分的bug的可能性。即使你独自开发，在六个月内重新安装项目时，您可以确信安装的依赖项仍然有效，即使您的依赖项发布了许多新版本...对于库，不需要提交锁定文件。
但是，如果您的团队使用不同的操作系统、硬件/CPU类型等，并且您没有使用Docker等容器技术进行开发。我建议您不要提交锁定文件，因为这会给团队带来很多问题。如果您的团队使用Docker进行构建，这是很好的。例如，如果您的锁定文件包含有关专门为Linux构建的库的信息，在Windows上[从锁定文件安装]就成了一个问题。

作为2023年1月的状态，诗歌已经打破了至少在1.3.1，也许1.3.0 https://github.com/python-poetry/poetry/issues/7211之后的旧的次要版本之间的向后兼容性
因此，现在唯一的方法似乎是将poetry.lock添加到.gitignore