---
title: "poetry.lock Merge Conflict After Server poetry update"
description: "After manual poetry update on a server, git pull conflicts on lock file; resolution: git checkout backend/poetry.lock && git pull"
tags: [poetry, git, deploy, python, server]
source: daily/2026-05-08.md
created: 2026-05-08
updated: 2026-05-08
---

# poetry.lock Merge Conflict After Server poetry update

## The Scenario

A developer runs `poetry update` or `poetry add <package>` directly on a production/staging server to test something. This regenerates `poetry.lock` on the server with a different set of resolved versions. Later, a `git pull` with new changes to `pyproject.toml` (e.g., a version bump) causes a merge conflict on `poetry.lock`.

## The Problem

`poetry.lock` is a large auto-generated file. Merge conflicts in it are almost never worth resolving manually — the correct lock file is the one generated by the developer on their local machine and committed to git.

## Resolution

Discard the server's lock file and let git pull bring the committed version:

```bash
# On the server:
git checkout backend/poetry.lock   # discard server changes
git pull                           # now pull succeeds cleanly

# Then reinstall with the pulled lock file:
cd backend && poetry install --no-root
```

## Prevention

- Never run `poetry update` or `poetry add` on servers — these mutate `poetry.lock`
- Use `poetry install --no-root` on servers (reads the existing lock file, does not modify it)
- If you need to test a new package on the server, use `pip install <pkg>` in the venv as a temporary measure, then add it properly via pyproject.toml locally

## Related

- [[wiki/concepts/poetry-docker-version-mismatch]] — Poetry version mismatches between dev and Docker
