Skip to main content
Redhat Developers  Logo
  • AI

    Get started with AI

    • Red Hat AI
      Accelerate the development and deployment of enterprise AI solutions.
    • AI learning hub
      Explore learning materials and tools, organized by task.
    • AI interactive demos
      Click through scenarios with Red Hat AI, including training LLMs and more.
    • AI/ML learning paths
      Expand your OpenShift AI knowledge using these learning resources.
    • AI quickstarts
      Focused AI use cases designed for fast deployment on Red Hat AI platforms.
    • No-cost AI training
      Foundational Red Hat AI training.

    Featured resources

    • OpenShift AI learning
    • Open source AI for developers
    • AI product application development
    • Open source-powered AI/ML for hybrid cloud
    • AI and Node.js cheat sheet

    Red Hat AI Factory with NVIDIA

    • Red Hat AI Factory with NVIDIA is a co-engineered, enterprise-grade AI solution for building, deploying, and managing AI at scale across hybrid cloud environments.
    • Explore the solution
  • Learn

    Self-guided

    • Documentation
      Find answers, get step-by-step guidance, and learn how to use Red Hat products.
    • Learning paths
      Explore curated walkthroughs for common development tasks.
    • Guided learning
      Receive custom learning paths powered by our AI assistant.
    • See all learning

    Hands-on

    • Developer Sandbox
      Spin up Red Hat's products and technologies without setup or configuration.
    • Interactive labs
      Learn by doing in these hands-on, browser-based experiences.
    • Interactive demos
      Click through product features in these guided tours.

    Browse by topic

    • AI/ML
    • Automation
    • Java
    • Kubernetes
    • Linux
    • See all topics

    Training & certifications

    • Courses and exams
    • Certifications
    • Skills assessments
    • Red Hat Academy
    • Learning subscription
    • Explore training
  • Build

    Get started

    • Red Hat build of Podman Desktop
      A downloadable, local development hub to experiment with our products and builds.
    • Developer Sandbox
      Spin up Red Hat's products and technologies without setup or configuration.

    Download products

    • Access product downloads to start building and testing right away.
    • Red Hat Enterprise Linux
    • Red Hat AI
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform
    • See all products

    Featured

    • Red Hat build of OpenJDK
    • Red Hat JBoss Enterprise Application Platform
    • Red Hat OpenShift Dev Spaces
    • Red Hat Developer Toolset

    References

    • E-books
    • Documentation
    • Cheat sheets
    • Architecture center
  • Community

    Get involved

    • Events
    • Live AI events
    • Red Hat Summit
    • Red Hat Accelerators
    • Community discussions

    Follow along

    • Articles & blogs
    • Developer newsletter
    • Videos
    • Github

    Get help

    • Customer service
    • Customer support
    • Regional contacts
    • Find a partner

    Join the Red Hat Developer program

    • Download Red Hat products and project builds, access support documentation, learning content, and more.
    • Explore the benefits

3 ways to embed a commit hash in Go programs

November 14, 2022
Panagiotis Georgiadis
Related topics:
Go
Related products:
Red Hat OpenShift

    Whether you are using Go to write a simple console-based utility or a fancy web application, it is always helpful to reference the previous version of your software. This information is essential, especially for developers. They need to know what the source code looked like in previous versions, so they can debug any issues introduced at specific points in time.

    To do that, you need a system that can control and manage different versions of the source code, such as git. Whenever you want to capture a snapshot of the program's current codebase, you run a git commit command that saves the code at that point in time. To make sure you do not overwrite a previously saved record, git creates (by default) a unique identifier, hashed with the SHA-1 algorithm, for every commit.

    Usually, when a decent amount of progress has been made, a couple of features have been implemented and lots of bugs have been fixed, it's about time to make things official and announce a new release version of your software. Of course, embedding the release version is not new. You most likely already have automation in place to provide this information within your software (e.g., during the release pipeline). But this kind of progress doesn't happen in a day. So what happens in the meantime? You do what the rolling-release model does, associating every build (go build) with a snapshot of the code at that point in time. This is when the git commit hash comes in handy. There are three ways to embed this hash into your Go program.

    1. Using -ldflags

    The most common way is by using a string variable, a value populated at build time via flags.

    For example:

    var Commit string
    go build -ldflags="-X main.Commit=$(git rev-parse HEAD)"

    The disadvantage here is that you need to remember this syntax and run it every time you build your code. You can make this easier by using Makefiles to do that for you.

    2. Using go generate

    Another way is to use a file (let's call it VERSION.txt). This process requires the installation of Go 1.16 or later, since it uses go:generate to populate the file contents and go:embed to populate the variable. For example:

    //go:generate sh -c "printf %s $(git rev-parse HEAD) > VERSION.txt"
    //go:embed VERSION.txt
    var Commit string

    You have to remember to run go generate every time before go build. To avoid developing an unnecessary memory muscle, you can put this block into your Makefile, which is part of the @build target.

    With this method, you have a file (VERSION.txt) that always captures the latest commit hash of the repository. While this information is not that useful information for you (since you can also see this information in GitHub's user interface or just using git), the advantage here is that you can use this file for other things in your CI/CD environment as well. If a component needs to know the version, now it has an easy way to find it: by reading this file.

    However, the downside here is that you have to remember to include that file as part of your code well. This is something that is generated by the computer and not written by a person, so it's not uncommon for people to forget about it.

    This way is mostly preferred when you are officially releasing a new stable version of your software, but not every time your merge a PR. Although I can see the benefits, I wouldn't recommend this for daily use.

    3. Using runtime/debug package

    The third solution to this problem is quite simple and comes fresh from the runtime/debug package, which is already part of the official Go library.

    import "runtime/debug"
    
    var Commit = func() string {
      if info, ok := debug.ReadBuildInfo(); ok {
        for _, setting := range info.Settings {
          if setting.Key == "vcs.revision" {
            return setting.Value
          }
        }
      }
    
      return "" 
    }()

    Apart from vsc.revision, you can also query for vcs.time (that is the timestamp of the commit message) and check vcs.modified (that is true if the binary builds from uncommitted changes). To make this work, you need Go 1.18, and should build using the -buildvcs (which should be available in your goenv).

    This is a great way to include the commit hash information without having to take care of building with a specific set of ldflags or running go generate every single time. As long as you have Go 1.18 or higher, a simple go build should suffice to pass the git information into the Commit string variable.

    What's the best way to embed a commit hash?

    You might ask: Which of the three ways is the best? The answer is that you should pick the one that fits your needs. You might not need any of these methods, or you might use more than one in combination.

    Personally, I like the last way, because I don't need a Makefile and I don't want to remember to do anything extra out of the ordinary. So, if the usual go build gives me all I need, then that's enough for me. Less is more!

    Related Posts

    • Using Delve to debug Go programs on Red Hat Enterprise Linux

    • Is your Go application FIPS compliant?

    Recent Posts

    • Protect data offloaded to GPU-accelerated environments with OpenShift sandboxed containers

    • Case study: Measuring energy efficiency on the x64 platform

    • How to prevent AI inference stack silent failures

    • Preventing GPU waste: A guide to JIT checkpointing with Kubeflow Trainer on OpenShift AI

    • How to manage TLS certificates used by OpenShift GitOps operator

    What’s up next?

    Path to GitOps cover card

    Read The Path to GitOps for a comprehensive look at the tools, workflows, and structures teams need to have in place in order to enable a complete GitOps workflow.

    Get the ebook
    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Platforms

    • Red Hat AI
    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform
    • See all products

    Build

    • Developer Sandbox
    • Developer tools
    • Interactive tutorials
    • API catalog

    Quicklinks

    • Learning resources
    • E-books
    • Cheat sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site status dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2026 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Chat Support

    Please log in with your Red Hat account to access chat support.