2010-08-12 5 views
8

Ich bin gerade dabei, ein vorhandenes SVN-Repository in git zu konvertieren und dann Reviewboard für Reviews zu verwenden, bevor Pushs erlaubt werden. Ich habe erst vor kurzem begonnen, git zu benutzen und bin weit davon entfernt, ein Experte dafür zu sein, aber was ich gerne machen würde, wäre ein Pre-Push-Hook, der "post-review" ausführt, um die Änderungen an ReviewBoard zu senden. Ich habe einen Haken, der das tut, aber es sieht so aus, als würde dies nicht automatisch auf Klone des Repositories übertragen. Um es zu lesen, hört sich das so an, als würde man nicht zwingen, ausführbaren Code für einen Benutzer zu erzwingen, aber dies ist ein rein internes Repository, und wir wollen dies und ein paar andere Richtlinien erzwingen. Gibt es eine Möglichkeit, Git zu zwingen, die Hooks zu entfernten Klonen zu propagieren, oder müssen wir unsere Entwickler anweisen, etwas auszuführen, das diese Hooks in ihre lokalen Repos legt? Git-Hooks - propagieren von Remote-Repository?

Dank - Adam

+0

Siehe http://stackoverflow.com/questions/3462955/putting-git-hooks-into-repository - das beantwortet einige Ihrer Fragen. – bstpierre

Antwort

7

Git hat keine eingebaute Unterstützung für Haken zwischen den Klonen, optional oder auf andere Weise zu übertragen. Es verfügt über Standardvorlagen, die Sie für neue Repositorys ändern oder hinzufügen können, die jedoch vom lokalen Dateisystem (bzw. Netzwerk-Dateisystem) abgerufen werden. Es ist möglich, dass Sie ein System für das Kopieren dieser Dateien instrumentieren können oder die Hooks selbst in das Repository stellen und die Entwickler auffordern, ihren Klon korrekt zu konfigurieren.

Es ist auch möglich, den gewünschten Hook auf dem zentralen Bare-Repository auszuführen, wenn der Push-Vorgang stattfindet, aber bevor der Ref aktualisiert wird. Dies könnte mit einem Pre-Receive- oder Update-Hook erfolgen. Ob dies akzeptabel ist, hängt von der tatsächlichen Funktionalität dieses Hooks ab, was aus Ihrem Post nicht hervorgeht.

Lesen http://www.reviewboard.org/docs/manual/dev/faq/ es klingt wie vielleicht sollten Sie Ihre Entwickler ermutigen, Zweigstellen zu verwenden. Sobald Änderungen genehmigt wurden, können sie in Freigabezweige zusammengeführt werden. Sie könnten einen Update-Hook haben, der nur Push-Vorgänge zu bestimmten Zweigen von privilegierten Benutzern oder anderen Kriterien erlaubt. Dies könnte auch mit gitolite erfolgen, die Sie bei http://progit.org/book/ch4-8.html

lesen können Wenn Sie sich nicht auf Reviewboard verpflichtet, Sie http://code.google.com/p/gerrit/ betrachten würde, das ist besser integriert mit Git und unterstützt ausdrücklich diesen Workflow