I'm not sure I got the question correctly.
Here's the way I usually see it/understand this.
Since you use Docker, I assume (and might be wrong) you run docker containers on the server. When doing so, all our containers have their docker tag based on the git sha revision of the commit which has been used to build that image.
(And because Docker tags are mutable... even if we usually not move them, it might be. The best example if the latest tag...), we also have a Docker LABEL with the same git sha1, so it requires either an inspect or a custom docker ps --format ... command, but the point is: we always have a way to get the exact sha1 the code used by a container, even when this one is running for 4 months or more.
And once you have the git ref, you're back to the usual solution (the fact that the code is running on a server or not is a distraction, but your goal here is really just to get the git ref)
And what if you're not running Docker containers? Well, then it really depends on how you deploy/run your stuff. Currently, our servers are running both Docker containers and native C builds (running in isolated forks). When we build our C binaries, we push them to S3 (nothing fancy here, any file storage would work, even FTP) and the complete path to the binary is either based on the git tag (when build based on a tag) or the git sha1.
Then we use Nomad to run both our Docker and binaries payload, but in all cases, our jobs use the git version (either via the Docker tag or via the binary path) to specify what to run. This makes it as easy as nomad job inspect job_name to get all the details about a running payload, including the git sha which has been used to build that artifact.
If we step back, this is easy for us because we forced ourselves to consider this need from the beginning and tried to make our deployments as immutable as possible, and to make sure everything can be tracked down. If we look at it the other way, if you currently miss this, then it might be a symptom that you might benefit from reviewing your whole development lifecycle to spot any gaps, and consider it from your task definition (e.g. Jira) down to the deploy/release/troubleshoot. If you're able to easily have the git ref of a piece of code running, and link this git ref to a Jira ticket - or whatever our task system is - then you'll be able to always find exactly which code is running, since when, why has this change has been made. Please note that I'm only scratching the surface here, because the configuration of the server, e.g. the settings, the env var you provide to the piece of code, also needs to be tracked so that you are able to know if a change is the config has been done, since when, by who, even if it's the same code revision which is running (e.g. change in concurrency, resource allocation, external services configs, ...) As soon as you consider this in your lifecycle and plan to track it, it becomes much easy to troubleshoot config drifts, errors, ... (If you want to learn more, you can google gitops, immutable infrastructure, or just ask ;-)
Hope this helps