Disclaimer
Please refer to this answer for the official stance and justification on the topic, which should be the top post in this thread. Below is my original answer, which I’ll leave as it was.
The official recommendation of the poetry maintainers is to commit the lockfile if you develop a deployable application (as opposed to a library).
That being said, my personal experience has been that it isn’t necessary to commit lockfiles to VCS. The pyproject.toml file is the reference for correct build instructions, and the lockfile is the reference for a single successful deployment. Now, I don’t know what the spec for poetry.lock is, but I had them backfire on me often enough during collaboration with colleagues in ways where only deleting them would fix the problem.
A usual problem was that using different operation systems or python versions would lead to different lockfiles, and that just doesn’t fly. I’ll gladly let our CI build and persist an authoritative reference-lockfile to enable re-builds, but it still wouldn’t be committed to the repository.
If maintaining a shared lockfile is viable given your workflow – great! You avoid a step in your pipeline, have one less artifact to worry about, and cut down dramatically on build time (even a medium-size project can take minutes to do a full dependency-resolution).
But as far as best practices go, I’d consider adding poetry.lock to the .gitignore a better practice than what you do, and only commit pyproject.toml changes when you add dependencies.