Skip to main content
Redhat Developers  Logo
  • Products

    Platforms

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat AI
      Red Hat AI
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • View All Red Hat Products

    Featured

    • Red Hat build of OpenJDK
    • Red Hat Developer Hub
    • Red Hat JBoss Enterprise Application Platform
    • Red Hat OpenShift Dev Spaces
    • Red Hat OpenShift Local
    • Red Hat Developer Sandbox

      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Secure Development & Architectures

      • Security
      • Secure coding
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • Product Documentation
    • API Catalog
    • Legacy Documentation
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

3 ways to embed a commit hash in Go programs

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

Share:

    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

    • A deep dive into Apache Kafka's KRaft protocol

    • Staying ahead of artificial intelligence threats

    • Strengthen privacy and security with encrypted DNS in RHEL

    • How to enable Ansible Lightspeed intelligent assistant

    • Why some agentic AI developers are moving code from Python to Rust

    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

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    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
    © 2025 Red Hat

    Red Hat legal and privacy links

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

    Report a website issue