How to fix fatal: No tag exactly matches 'abc1234' in Git

GitBEGINNERLOWUpdated Dec 6, 2025· 159 views

The git describe command fails when used with --match or --exact-match options and no tags match the specified pattern or commit. This occurs when trying to find a specific tag that describes the current commit.

Quick fix

Fixes fatal: No tag exactly matches 'abc1234'

git tag -l
  1. Check if any tags exist in your repository
  2. Verify the current commit has a tag (for --exact-match)
  3. Test your --match pattern
  4. Fetch tags from remote if in CI/CD or after shallow clone
git — error
git tag -l
fatal: No tag exactly matches 'abc1234'

What this error means

The git describe command is used to give a human-readable name to a commit based on the nearest reachable tag. When you use the --exact-match option, git describe will only output if the current commit is tagged exactly. If you use the --match option with a pattern, it will only consider tags matching that glob pattern. This error occurs when git describe cannot find any tags that satisfy your search criteria. With --exact-match, it means the current commit doesn't have a tag pointing directly to it. With --match, it means no tags in your repository match the specified pattern, or none of the matching tags are reachable from the current commit. This is commonly encountered in CI/CD pipelines when trying to determine version numbers from tags, or when attempting to verify that a specific commit has been tagged for release.

Typical symptoms

  • Command fails with "fatal: No tag exactly matches" when using git describe --exact-match
  • Error message shows "fatal: No names found, cannot describe anything" when using --match with no matching tags
  • Build or release scripts fail when trying to extract version information from git tags
  • CI/CD pipelines report errors during version determination steps
  • Git describe command succeeds without --match or --exact-match but fails with these options

Common causes

  1. The current commit has no tag pointing directly to it (when using --exact-match)
  2. No tags in the repository match the specified glob pattern (when using --match)
  3. Shallow clone in CI/CD environments cuts off history before reaching any matching tags
  4. Tags exist in remote repository but have not been fetched locally
  5. Only lightweight tags exist but git describe by default looks for annotated tags only
  6. Repository has no tags at all
  7. The matching tags exist but are not reachable from the current commit (on different branches)

How to fix "fatal: No tag exactly matches 'abc1234'"

1Check if any tags exist in your repository

First, verify that your repository has tags:

bash
git tag -l

If this returns no output, you have no tags. You'll need to create at least one tag:

bash
git tag v1.0.0
2Verify the current commit has a tag (for --exact-match)

If you're using --exact-match, check if the current commit (HEAD) has a tag:

bash
git tag --points-at HEAD

If this returns no output, the current commit is not tagged. You can either:
- Switch to a tagged commit
- Create a tag for the current commit: git tag v1.0.1
- Use git describe without --exact-match to find the nearest tag

3Test your --match pattern

If using --match, verify that tags matching your pattern exist:

bash
# List all tags matching pattern
git tag -l 'v*'

# Try describe with --match
git describe --match 'v*'

Adjust your glob pattern to match your actual tag naming convention. Common patterns:
- v* - matches v1.0.0, v2.1.3, etc.
- release-* - matches release-2024.1, release-2024.2, etc.
- * - matches all tags

4Fetch tags from remote if in CI/CD or after shallow clone

In CI/CD environments or after shallow clones, tags may not be present:

bash
# Fetch all tags from remote
git fetch --tags

# Or fetch with full history (unshallow)
git fetch --unshallow

For GitHub Actions, ensure your workflow fetches full history:

yaml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0  # Fetch all history for all branches and tags

For GitLab CI, disable shallow cloning in Settings → CI/CD → General Pipelines or use:

yaml
variables:
  GIT_DEPTH: 0
5Include lightweight tags if needed

By default, git describe only considers annotated tags. If you have lightweight tags, add the --tags option:

bash
# Consider both annotated and lightweight tags
git describe --tags --match 'v*'

To check what type your tags are:

bash
# Annotated tags show detailed info
git show v1.0.0

# Lightweight tags show the commit they point to
6Use --always as a fallback

If you want git describe to always return something even when no tags match, use --always:

bash
# Returns tag if found, otherwise abbreviated commit hash
git describe --tags --always

# With --match pattern
git describe --match 'v*' --always

This is useful in build scripts where you need some identifier regardless of whether tags exist.

Advanced notes

Understanding Tag Reachability

Git describe only considers tags that are reachable by following parent commits from the current commit. If you've created tags on different branches that haven't been merged, they won't be considered. Use git describe --all to consider branches and remote-tracking references as well.

Pattern Matching with --match

The --match option accepts glob(7) patterns, not regular expressions. Multiple --match options can be provided, and a tag matching any pattern will be considered. Use --no-match to clear previously specified patterns.

Tag Preference Order

When multiple tags could describe the same commit:
1. Annotated tags are preferred over lightweight tags
2. Tags with newer dates are preferred over older ones
3. If tied, lexicographic order determines the winner

Performance in Large Repositories

In repositories with many tags, consider using --match to limit the search space. This can significantly improve performance of git describe in CI/CD pipelines.

Versioning Best Practices

For semantic versioning workflows:
- Use annotated tags for releases: git tag -a v1.2.3 -m "Release 1.2.3"
- Push tags explicitly: git push --tags or git push origin v1.2.3
- Establish a consistent naming convention (e.g., v* prefix) and use --match to filter
- In CI/CD, always fetch tags before attempting version determination

Frequently asked questions

What does "fatal: No tag exactly matches 'abc1234'" mean?
The git describe command is used to give a human-readable name to a commit based on the nearest reachable tag. When you use the --exact-match option, git describe will only output if the current commit is tagged exactly. If you use the --match option with a pattern, it will only consider tags matching that glob pattern.
How do I fix "fatal: No tag exactly matches 'abc1234'"?
The git describe command fails when used with --match or --exact-match options and no tags match the specified pattern or commit. This occurs when trying to find a specific tag that describes the current commit.
What causes "fatal: No tag exactly matches 'abc1234'"?
The current commit has no tag pointing directly to it (when using --exact-match) No tags in the repository match the specified glob pattern (when using --match) Shallow clone in CI/CD environments cuts off history before reaching any matching tags
Is the "fatal: No tag exactly matches 'abc1234'" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading