Option 1 (Recommended): Embed Git Commit ID during Build ⭐⭐⭐⭐⭐

This is a common DevOps problem. The goal is to answer questions like:

• Which Git commit is currently deployed?
• Is the server running the latest code?
• Which branch was deployed?
• When was it deployed?

There are several industry-standard approaches.

This is probably the simplest and most reliable solution.

During your CI/CD or build process:

git rev-parse HEAD

returns

8ab42f76f1e0a1a8f0d...

Store this inside your application.

Example:

VersionInfo.json

{
    "CommitId":"8ab42f76",
    "Branch":"main",
    "BuildDate":"2026-06-30 10:30",
    "BuildNumber":"125"
}

or

public static class BuildInfo
{
    public const string CommitId = "8ab42f76";
    public const string Branch = "main";
}

Create an endpoint

GET /api/version

Response

{
  "commit":"8ab42f76",
  "branch":"main",
  "build":"125",
  "buildDate":"2026-06-30"
}

Now simply compare

Latest Git commit

8ab42f76

Server

8ab42f76

✓ Up-to-date

Option 2: Docker Image Tag = Git Commit ⭐⭐⭐⭐⭐

Most companies deploy Docker images like

myapp:8ab42f76

instead of

myapp:latest

Then

docker ps

shows

myapp:8ab42f76

Immediately you know what commit is running.

Even better

docker images

shows every deployed version.

Very common in production.

Option 3: Git Commit + Semantic Version ⭐⭐⭐⭐

Example

v2.3.1

and

Commit

8ab42f76

Display

Version : 2.3.1
Commit : 8ab42f76

This is what many enterprise applications do.

Option 4: Auto-generated Build Number ⭐⭐⭐⭐

Every deployment increments a number.

Build 101
Build 102
Build 103

UI

ERP Crystal

Version 2.4.1
Build 103
Commit 8ab42f76

Easy for support teams.

Option 5: Show Version in UI ⭐⭐⭐⭐⭐

Example

ERP Crystal

Version 2.4.1

Commit
8ab42f76

Built
30-Jun-2026

Usually displayed

• Login page
• About page
• Footer

Many ERP products do this.

Option 6: Health Endpoint ⭐⭐⭐⭐⭐

GET /health

Response

{
  "status":"Healthy",
  "version":"2.4.1",
  "commit":"8ab42f76",
  "build":"125",
  "date":"2026-06-30"
}

Very useful for DevOps monitoring.

Option 7: Git Tag Releases ⭐⭐⭐⭐

Tag releases

v2.0.0

v2.0.1

v2.1.0

Now deployment records

Release v2.1.0

Commit

8ab42f76

Option 8: Store Deployment History ⭐⭐⭐⭐

Maintain a deployment log

This is useful when managing multiple environments.

Option 9: Read Commit from Docker Labels ⭐⭐⭐⭐

During image build

LABEL git.commit=8ab42f76
LABEL build.date=2026-06-30

Then

docker inspect

reveals exactly which commit is running.

About Your Version Number Idea

A version number is useful, but by itself it doesn’t tell you exactly what source code is deployed.

For example:

Version 2.1.0

What if a developer fixes one bug and redeploys?

Is it still

2.1.0

or

2.1.1

Someone has to remember to change the version, and mistakes happen.

Git commits are automatically unique.

8ab42f76
↓
Exactly one state of your code.

That’s why many teams combine both:

Version : 2.4.1
Build    : 127
Commit   : 8ab42f76
Branch   : main
Built On : 30-Jun-2026 10:32

This gives both a human-friendly version (2.4.1) and a precise technical identifier (the commit hash).

What I would recommend for your setup

Since you’re using ASP.NET Core, Docker, Nginx, and Linux, a practical approach is:

1. Build the Docker image with the Git commit hash as its tag (for example, erpcrystal:8ab42f76).

2. During the build, generate a small version.json or BuildInfo.cs file containing:

   • Semantic version (if you use one)
   • Git commit hash
   • Branch name
   • Build date/time

3. Expose this information through a lightweight endpoint such as /api/version.

4. Display the version and commit hash in your application’s “About” page or footer for easy verification.

5. If you have a CI/CD pipeline in the future, let it generate the build number automatically.

This approach requires very little code, works well with Docker, and makes it easy to verify whether a server is running the expected build.