Git hooks - propagation à partir d'un dépôt distant?

Question

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. J'ai récemment commencé à utiliser git et je suis loin d'être un expert, mais ce que je voudrais faire, c'est d'avoir un hook pré-push qui fonctionne "post-review" pour soumettre les changements à ReviewBoard. J'ai un crochet de travail qui fera cela, mais il semble que ce n'est pas propagé automatiquement aux clones du dépôt. Il semblerait que cela ne soit pas fait pour éviter de forcer le code exécutable sur un utilisateur, mais il s'agit d'un référentiel interne uniquement et nous souhaitons le faire appliquer ainsi que quelques autres stratégies. Existe-t-il un moyen de forcer git à propager les hooks vers des clones distants ou devons-nous demander à nos développeurs d'exécuter quelque chose qui place ces hooks dans leurs repos locaux?

Merci - Adam

Answer 1

Git n'a pas un support intégré pour le transfert entre crochets clones, en option 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 extraits du système de fichiers local (ou du système de fichiers réseau, selon le cas). Il est possible que vous puissiez instrumenter un système pour les copier, ou mettre les crochets eux-mêmes dans le référentiel et demander aux développeurs de configurer correctement leur clone.

Il peut également être possible d'exécuter le hook que vous voulez sur le référentiel central nu, lorsque le push se produit mais avant que l'arbitre ne soit mis à jour. Cela pourrait être fait avec un crochet de pré-réception ou de mise à jour. Si cela est acceptable dépend de la fonctionnalité réelle de ce crochet, ce qui n'est pas clair à partir de votre poste.

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 en branches de publication. Vous pourriez avoir un hook de mise à jour qui ne permet que des poussées vers des branches particulières d'utilisateurs privilégiés, ou tout autre critère. Cela pourrait aussi être fait en utilisant gitolite, que vous pouvez lire à http://progit.org/book/ch4-8.html

Si vous n'êtes pas engagé à Reviewboard, vous pourriez envisager http://code.google.com/p/gerrit/ qui est mieux intégrée avec Git et soutient explicitement ce flux de travail