Ich bin gerade dabei, ein vorhandenes SVN-Repository in git zu konvertieren und anschließend Reviewboard für Reviews zu verwenden, bevor Pushs zugelassen werden. Ich habe erst vor kurzem begonnen, Git zu benutzen und bin weit davon entfernt, ein Experte darin zu sein, aber was ich tun möchte, ist ein Pre-Push-Hook, der "post-review" ausführt, um die Änderungen an ReviewBoard zu senden. Ich habe einen Hook, der das tut, aber es sieht so aus, als ob er nicht automatisch auf Klone des Repositories übertragen wird. 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 durchsetzen. Gibt es eine Möglichkeit, Git zu zwingen, die Hooks zu entfernten Klonen weiterzugeben, oder müssen wir unsere Entwickler anweisen, etwas auszuführen, das diese Hooks in ihre lokalen Repos legt?
Danke - Adam
Git hat keine eingebaute Unterstützung für das Übertragen von Hooks zwischen Klonen, optional oder anderweitig. 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 oder die Hooks selbst in das Repository stellen und Entwickler bitten, ihren Klon korrekt zu konfigurieren.
Es ist auch möglich, den gewünschten Hook auf dem zentralen bare-Repository auszuführen, wenn der Push ausgeführt wird, 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 ersichtlich ist.
Lesen Ссылка Es klingt vielleicht so, als ob Sie Ihre Entwickler ermutigen sollten, Zweige 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 geschehen, was Sie in Ссылка
nachlesen könnenWenn Sie nicht an Reviewboard interessiert sind, sollten Sie Ссылка in Betracht ziehen, das besser in Git integriert ist und explizit unterstützt dieser Workflow
Tags und Links git code-review