Best Practice for Git Repositories with multiple projects in traditional n-tier design

The reason most people advise to do separate repositories is because it separates out changes and change sets. If someone makes a change to the client projects (which you say doesn’t really effect others), there is no reason for someone to update the entire code base. They can simply just get the changes from the project(s) they care about.

Git Submodules are like Externals in Subversion. You can set up your git repositories so that each one is a separate layer, and then use submodules to include the projects that are needed in the various hierarchies you have.

So if for example:

/Core -- It's own git repository that contains it's base files (as you had outlined)
  /SharedLib1
  /SharedLib2

/UI Layer -- Own git repository 
  /CoreWebsite
  /WebsiteHelper
  /Tahiti.WebsiteHelpers
  /Core -- Git Submodule to the /Core repository
    /SharedLib1
    /SharedLib2

This ensures that any updates to the /Core repository are brought into UI Layer repository. It also means that if you have to update your shared libraries you don’t have to do it across 5-6 projects.