Pour moi la première à laquelle il faut penser se sont les abus qui peuvent se présenter.
Les abus
Concernant l'ajout d'un dépot distant ils peuvent se présenter sous au moins 3 formes :
- Un dépot avec 10^9999999 fichiers de versionnés
- Un dépot avec un historique de de 10^999999999999999 commits
- Des fichiers interdits sont présents sur le dépot
Et il est impossible de traiter ces cas automatique avec git (pour le second il est toujours possible d'utiliser --depth, mais dans ce cas là on ne peut pas utiliser git log pour récupérer la liste des auteurs)
Donc concernant les deux premiers abus, la seule solution qui me viens à l'esprit pour gérer ça automatiquement c'est les quotas du système d'exploitation, ce qui implique soit de gérer des quotas par dossier (compliqué -pas impossible car rien n'est impossible =D- à mettre en place), soit d'avoir un utilisateur système par utilisateur inscrit (ce qui pose des problème de configuration important et surtout peut présenter un jolie travail supplémentaire si un jour il faut changer de serveur).
Bref dans tous les cas c'est l'admin sys qui pleurs.
Quand au troisième abus il suffirait de lancer un script une fois le dépot cloné.
Sinon une autre solution se serait de valider manuellement l'ajout d'un dépot distant, ainsi si "validateur" pourra vérifier que le dépot a une taille normal et que ça ne vas pas poser de problèmes et que tous les fichiers présents sont autorisés.
Enfin une dernière solution serait de forcer l'ajout d'un dépot vierge.
Quoi qu'il arrive le problème ne se pose que pour le clone car après tout peut être géré par un hook pre-receive et quelques commandes tels que du et un script shell.
Les auteurs
Ensuite se pose la question des auteurs, là je vois deux solutions :
1. Utiliser git log
2. Utiliser un fichier json
git log
L'utilisation de git log pose un problème fondamental : comment associer les auteurs des commits avec les utilisateur du site. La seule solution acceptable c'est de les forcer à configurer leur dépot local de manière à utiliser le même pseudo que sur le site (ou le même e-mail, ce qui est le fonctionnement de github).
Par contre git log peut être particulièrement lent si l'historique est grand mais dans ce cas on peut y aller de manière incrémentale (on génère et met en cache la liste des auteurs lorsque le dépot est cloné, puis un hook post-receive se charge de mettre à jour cette liste à chaque push).
Fichier json
Dans ce cas on se contente de laisser les auteur gérer la liste eux même, manuellement. Ils vont donc devoir remplir un fichier (json par exemple) avec la liste des pseudos des auteurs (les pseudos devant être ceux du site). De cette manière il devrait être possible de mentionner un auteur non inscrit sur le site.
Un mix des deux
On utilise git log, et un fichier json permet de faire la correspondance entre les auteurs des commits et les utilisateurs sur le site.
Les branches/tags
Ici je pense que la première chose à faire c'est de remettre à plat les besoins. Il faut : (n'hésitez pas à compléter la liste)
- identifier la béta en cours (archiver la liste des bétas ?)
- identifier la dernière version validée (archiver cette liste ?)
- identifier la dernière version en cours de rédaction
- les auteurs peuvent publier une béta, soumettre une version à la validation, modifier la version en cours de rédaction
- les validateurs peuvent publier une version en validation
- les validateurs peuvent modifier uen version publiée (attention aux conflits avec la
CC-BY-ND et la CC-BY-NC-ND) ?
- une utilisation identique via l'interface web et un client git traditionnel
Tout est identifié par un commit
La première chose qui me saute aux yeux c'est que tout correspond à un commit et que par conséquent tout est identifié de manière unique par un hash. Donc la première chose de faisable c'est de permettre de donner le hash précis de la version à mettre en béta/valider à chaque fois (le hash ou un alias, dixit un tag).
Archiver
La seconde chose c'est qu'il serait bien de pouvoir archiver cet historique de béta/validation auquel cas on peut avoir deux solutions :
- Les stocker dans la bd
- Utiliser des tags nommés avec une convention précise (ie: beta-<numero de la beta>, validation-<numero>, valide-<prod>)
Le premier cas étant trivial et classique je vais pas m'étendre. Quand au second il est plus complex et il présente un problème principal, à savoir la gestion des droits car :
- seul l'auteur peut proposer en validation
- seul l'auteur peut propsoer en béta
- seul l'équipe de validation peut valider
Dans ce cas je vois deux solutions :
- Forcer l'utilisation de l'interface web pour créer les/ces tags (l'auteur indique le hash du commit ou un tag à mettre en béta/validation)
- Utiliser des hooks
pre-receive (mais qu, à prioris, peuvent être abusés car il ne me semble pas que le hook connaisse l'utilisateur utilisé pour push)
De plus la seconde solution impose aussi d'utiliser un hook post-receive pour détecter ces tags et effectuer les actions correspondantes coté site web. Bref la première solution me semble être la plus viable.
Dans tous les cas il faudra protéger ces tags là afin d'empécher leur supression.
Les modifications effectuées par les validateurs
Dans ce cas je ne vois vraiment qu'une solution : si les validateurs doivent effectuer une modification alors, dans ce cas, une nouvelle branche est toujours créée à partir du commit de la version publiée (git checkout <hash> && git checkout -b validation-revision-<n>). Ainsi pas besoins de protéger la branche en écriture vue que HEAD n'est jamais utilisé. Par contre, par sécurité, il faut bloquer la suppression de cette branche (même si en réalité le commit existera toujours).
P.S Vous l'auriez compris, il me semble important d'être en mesure de manipuler directement le dépot git 
ou tout au moins d'être en mesure d'utiliser un dépot git distant que l'on peut donc manipuler.
