anything behaviourally like perforce branch-spec mappings in git?

[Robert Buck <buck.robert.j@gmail.com>]

Back at VeriSign we used branch-specs in Perforce to normalize
checked-in tooling to standard names (without version numbers). For
example:

Checked into the Perforce "releng" depot was the following:

//releng/
  head/
    vendor/
      junit-4.1/
        junit-4.1.jar
      junit-4.3
        junit-4.3.jar
  branches/
     same as above...

And a product specific depot may be:

//general
  head/
    ...
  branches/
    ...

The branch spec for a product would be:

//releng/branches/branch-name/vendor/junit-4.1   //workspace/releng/vendor/junit
...

You should be able to get the point. We supported workspace
composition, and the neat thing was that the build system itself was
versioned and could be separately versioned and changed as though it
were itself a product. But, as the build system was Ant based, rather
than constantly changing the build system to adapt to new versions of
junit, oro, and ivy jars, we simply used branch and view specs to
neutralize the workspace so the build system only referred to names
that lack version numbers. Further, a product could upgrade to a newer
version of the build system, almost always without consequence just by
changing these mappings.

So, is there some way to similarly accomplish this in Git? It was a
huge time-saver for release engineering at VeriSign, a pattern I'd
like to replicate using Git.

- Bob