anything behaviourally like perforce branch-spec mappings in git?

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