Ich versuche, einen Git-Server auf einer RedHat 6.5-Box zu installieren.
Dabei folge ich diesen Tutorials:1,2,3, und ehrlich gesagt, je mehr ich lese, desto unklarer werden die Dinge.
Wenn ich einen Git-Benutzer erstellen soll, der Eigentümer der Haupt-Repos ist und auch für die Commits zuständig ist, wie verhindere ich dann, dass ein Entwickler fehlerhaften Code pusht (Gitolite, gibt es da etwas Neueres?)?
Was ist die einfachste Konfiguration für den Git-Server (ich hätte gern Gitlab, aber mein Chef lässt das nicht zu), wobei der Entwickler-Push nur dann zugelassen wird, wenn der Code überprüft und die Berechtigung zum Push erteilt wurde.
Hinweis: Alle Entwickler haben SSH-Zugriff auf den Server. Und ich habe ihre ssh.pub-Schlüssel gesammelt
Antwort1
Zur Beantwortung Ihrer Frage:
Wenn ich einen Git-Benutzer erstelle, der Eigentümer der Haupt-Repos ist und auch für die Commits verantwortlich ist, wie verhindere ich dann, dass ein Entwickler fehlerhaften Code pusht?
Die Antwort besteht nicht darin, einen Git-Benutzer zu erstellen. Sie können die Zugriffsberechtigungen für das Remote-Repository mit standardmäßigen UNIX-Benutzern und -Gruppen steuern. Da Git-Pushs über SSH funktionieren, können Sie Repositories lesen, klonen und abrufen, solange Sie per SSH auf den Server zugreifen können, auf dem sich das Repository befindet, und über Ihr Konto auf dem Server Lesezugriff auf das Repository haben. Wenn Sie auch Schreibberechtigungen für das Repository haben, können Sie auch Commits pushen.
Antwort2
Eines der in Git standardmäßig aktivierten Dinge ist:
git push --force
Im Normalfall sollten Sie dies im Repo immer deaktivieren über:
git config --system receive.denyNonFastForwards true
Probleme können bei Merge-Workflow-Szenarien auftreten, wenn Sie viele Pull Requests haben, aber die beste Lösung ist immer, gute Merging- und getrennte Entwicklungsaufgaben zu haben, bei denen Entwickler Git wirklich verstehen und nicht so viel committen (hauptsächlich, weil sie die Natur der Versionskontrolle nicht verstehen) und wenn das in Ordnung ist, werden Sie weniger Konflikte haben. Gutes Training und Verständnis sind immer das Beste. Sie können dies auch verhindern, indem Sie Commits lokal rebasieren. Die zweite Alternative ist vielleicht Github. In diesem Szenario lassen Sie nicht zu, dass mehr als ein Betreuer in die wichtigen Zweige des maßgeblichen Repository pusht.