Je cherche actuellement à convertir un dépôt SVN existant en git, puis à utiliser Reviewboard pour les révisions avant d'autoriser les poussées. Je n'ai commencé que récemment à utiliser git et je suis loin d'être un expert en la matière, mais ce que je voudrais faire, c'est avoir un hook pré-push qui s'exécute "post-review" pour soumettre les changements à ReviewBoard. J'ai un hook qui fonctionne pour faire cela, mais il semble que cela ne soit pas propagé automatiquement aux clones du dépôt. En lisant autour de moi, il semble que ce n'est pas fait pour empêcher de forcer le code exécutable sur un utilisateur, mais il s'agit d'un référentiel interne seulement et nous voulons appliquer cela et quelques autres politiques. Existe-t-il un moyen de forcer git à propager les hooks aux clones distants ou devons-nous demander à nos développeurs d'exécuter quelque chose qui place ces hooks dans leurs dépôts locaux ?
Réponse
Trop de publicités?
Git n'a pas de support intégré pour transférer des hooks entre clones, optionnels ou non. Il a des modèles par défaut que vous pouvez modifier ou ajouter pour les nouveaux dépôts, mais ceux-ci sont tirés du système de fichiers local (ou du système de fichiers réseau, selon le cas). Il est possible d'instrumenter un système pour les copier, ou de mettre les hooks eux-mêmes dans le dépôt et de demander aux développeurs de configurer leur clone correctement.
Il pourrait également être possible d'exécuter le hook que vous voulez sur le dépôt central nu, lorsque le push se produit mais avant que le ref soit mis à jour. Cela pourrait être fait avec un hook de pré-réception ou de mise à jour. Si cela est acceptable, cela dépend de la fonctionnalité réelle de ce hook, ce qui n'est pas clair dans votre message.
Lecture http://www.reviewboard.org/docs/manual/dev/faq/ il semble que vous devriez peut-être encourager vos développeurs à utiliser des branches thématiques. Une fois les modifications approuvées, elles peuvent être fusionnées dans les branches de publication. Vous pourriez avoir un crochet de mise à jour qui n'autorise les poussées vers des branches particulières que par des utilisateurs privilégiés, ou tout autre critère. Cela pourrait également être fait en utilisant Gitolite, que vous pouvez lire à l'adresse suivante http://progit.org/book/ch4-8.html
Si vous n'êtes pas engagé dans Reviewboard, vous pourriez envisager de http://code.google.com/p/gerrit/ qui est mieux intégré à Git et supporte explicitement ce flux de travail
