Project- vs. Package-Level Branching in Git

Back when I worked at a large games company, we used Perforce, and our repo structure looked a little something like this:

/branches
	/alpha
	/beta
/mainline
	/packages
		/external
			/foolib
				/1.0
				/1.1
				/2.0
		/internal
			/barlib
				/dev
				/1.0
				/2.0
			/bazlib
				/2.34
				/2.35
			/qux
				/dev

At the package level, we would split up packages/libraries into two groups based on if they were developed at the company or not (external/internal), and inside each one, we might have multiple versions. In the example above, the repo is for the "qux" game, which uses an internal "bazlib" library developed by another group, and the "barlib" library which was developed for use on "qux" and may be used simultaneously on other projects.

Project-level branches took mainline as a base and branched into the /branches directory. Package-level branches would usually take the "dev" version (which represented the current development version, akin to "master" in Git) as a base and branch into the same parent directory but with an actual version name.

I've successfully used this repo structure with several other projects over the years at other companies (who were mostly using Subversion). Now I'm trying to get into the Git swing of things, but it seems to be that Git only offers project-level branching, and doesn't allow for the kind of package-level branching I'm describing here.

Am I incorrect or is there a way to accomplish with Git what I was doing before with P4 and SVN?

-- Thomas Hauk Shaggy Frog Software www.shaggyfrog.com