Le strict minimum : c'est-à-dire les seuls fichiers d'en-tête contenant les déclarations ou définitions de ce qui va être utilisé et permettant ainsi à la compilation de réussir.

Il est préférable d'avoir des déclarations anticipées (forward declaration) dans les fichiers d'en-tête et d'inclure l'en-tête de déclaration dans le fichier source. L'objectif à atteindre est que tout fichier d'en-tête doit pouvoir être inclus indépendamment des autres et compiler. Ce qui veut dire qu'un fichier d'en-tête doit contenir le moins de choses possibles.

class A
{
// déclaration de la classe A
};

class A; // déclaration anticipée
class B
{
// déclaration de la classe B
// ...

   void do_someting_with_a_A(A const &);
};

#include "B.h"
#include "A.h"
// définition de B...

A noter que la déclaration anticipée n'est possible que si le compilateur n'a pas besoin de connaître complètement le type : pointeur, référence. On ne peut l'utiliser pour l'héritage ou la composition.
Pour aller plus loin avec les déclarations anticipées, jusqu'à présent vous avez l'habitude de découper votre code en deux fichiers : un fichier d'en-tête MyClass.h pour la déclaration et un fichier d'implémentation MyClass.cpp pour la définition. Notez qu'on peut associer un troisième fichier MyClassFwd.h pour regrouper les déclarations anticipées liées à CMyClass. Ce fichier contient tout naturellement une déclaration anticipée de la classe :

class CMyClass;

Mais, c'est l'occasion d'y mettre aussi d'autres déclarations associées qui vont systématiquement (ou presque) avec votre classe. Ce peut être des enum, des déclarations de fonctions externes, etc... :

class CMyClass;
enum E_options_my_class
{
  // ...
};
std::ostream& operator << (std::ostream& O, const CMyClass& B); 

Lorsqu'une autre classe nécessite une déclaration anticipée de CMyClass, elle fait alors appel à cet en-tête :

#include "MyClassFwd.h"

Cet ordre est une proposition parmi d'autres qui ont aussi leur légitimité. Vous pouvez suivre un autre ordre d'inclusion si vous en sentez le besoin compte tenu de vos pratiques habituelles ou du contexte de votre application. En fait, l'idée maîtresse est de maintenir une cohérence sur l'ensemble du projet. Quelle que soit la politique que vous choisissez de mettre en œuvre, utilisez la même systématiquement dans tous vos fichiers.

Les templates nécessitent d'avoir toute la définition dans le fichier d'en-tête. Pour maintenir une politique cohérente, on peut séparer la déclaration d'une classe template (.h) et sa définition (.tpp). La définition est incluse à la fin du fichier de déclaration :

template<class T>
class TMyTemplateClass
{
public: 
   void do_something();
};
#include "MyTemplateClass.tpp"

// en-tête si besoin

// définition
template<class T>
void TMyTemplateClass<T>::do_something()
{
}

Inclure le fichier en tout premier dans un fichier .cpp. Ce dernier doit compiler sans erreur.

Les en-têtes précompilés n'offrent malheureusement pas de standard dans leur mise en œuvre. Tous les compilateurs ne les supportent pas, et ceux qui savent les gérer ne le font pas tous de la même façon. Est-ce une raison pour les abandonner ? Non. Car ils offrent de vrais avantages en terme de temps de compilation, surtout pour les projets utilisant des bibliothèques volumineuses ou complexes. La question qui se pose alors est de savoir quoi mettre dans les en-têtes précompilés ? Il faut garder à l'esprit l'objectif des en-têtes précompilés : accélérer la compilation. Il faut donc veiller à mettre les fichiers des bibliothèques externes récurrents dans vos sources ainsi que ceux qui sont susceptibles de provoquer des inclusions en cascade (afxXXX.h avec les MFC, wx.h dans wxWidgets). En revanche ne mettez pas des fichiers d'en-têtes du projet en cours car ce sont ceux qui sont le plus susceptibles de varier et dégradent ainsi le temps de compilation en forçant à tout recompiler.
Il faut être vigilant à ne pas transformer le fichier d'en-têtes précompilés en un fourre-tout contenant tous les fichiers de toutes les bibliothèques utilisées dans un projet. Cela rompt le principe qui veut que l'on minimise les dépendances entre les unités de compilation. Identifiez correctement les fichiers clés qui sont significatifs dans le temps de compilation de votre projet.