Warum ein git bare-Repository für die Website-Bereitstellung verwenden?

Question

Ich fange an, ein paar Website-Plugins über Git bereitzustellen.

Ich habe eine Reihe von Tutorials im Web durchgeführt und alle empfehlen die Erstellung eines nackten Remote-Repository auf dem Webserver mit einem Post-Update-Hook zum Auschecken in das DocumentRoot-Verzeichnis. Ich habe das alles ohne zu viele Probleme funktioniert.

Warum trennen wir das Repository vom Arbeitsverzeichnis? Was ist falsch daran, nur das DocumentRoot-Verzeichnis als Repository zu verwenden und dann htaccess zu verwenden, um den öffentlichen Zugriff auf alle .git-Inhalte zu verhindern?

Answer 1

Eigentlich sind die Sicherheitsrisiken, die einem schlecht konfigurierten htaccess innewohnen, ein guter Grund für sich selbst, aber der Hauptgrund ist, dass Sie standardmäßig nicht zum ausgecheckten Zweig eines nicht-bare-Repos wechseln können. (. Es aktiviert werden kann, aber dann erfordert ein git reset --hard die Arbeit Baum zu aktualisieren, und ist keine einfacher als ein separates Bereitstellungsverzeichnis mit)

Answer 2

Es gibt mehrere Fragen hier, dass, während der verwandten tatsächlich getrennt:

1 - Warum trennen wir das Repository vom Arbeitsverzeichnis?

Da git verhindert, dass Sie standardmäßig zu einem ausgecheckten Zweig wechseln. Sie können daher niemals in ein Arbeitsverzeichnis wechseln, da es definitionsgemäß auf Festplatte ausgecheckt ist.

2 - Alle von ihnen empfehlen eine nackte Remote-Repository auf dem Web-Server erstellen

Implizite Frage ist: why a bare repo? Nun, ein nackter Repo ist einfach ein git Repo mit nichts ausgecheckt. Daher können Sie zu jedem Zweig auf einem bloßen Repo drücken. Manche Menschen halten dies für einfacher.

Zweite implizierte Frage: is there an alternative to bare repos? Ja, wie erwähnt ist die Einschränkung nur für ausgecheckte Zweige. So können Sie immer noch frei zu einem nicht ausgecheckten Zweig pushen - vielleicht "deploy" und dann einen Haken haben, um diesen nicht ausgecheckten Zweig mit Ihrem Arbeitsverzeichnis zusammenzuführen.

Answer 3

1. Verwenden DocumentRoot als git Arbeitsverzeichnis:

   • Verwenden Update ziehen, müssen externe Trigger oder cron oder manuell ausführen es
   • brauchen, um den HTTP-Zugriff zu beschränken.git Verzeichnis
   • Instant bearbeiten Do/hacken in DocumentRoot diff verwenden können, mit git Geschichte zu vergleichen, gut für debug/finden Problem
   • Schalter Zweig ist einfach

2. Verwenden Sie separate nackten git repostory

   • Benutzer kann zu diesem Repo schieben und post-update Hook verwenden, um DocumentRoot
   • zu aktualisieren Normalerweise niemand wollen Instant-Hack in git bare Repo tun, kann die Änderung in DocumentRoot nicht mit git Geschichte
   • DocumentRoot ist sauber
   • Schalter Zweig Haken ändern müssen

So scheint separaten nackten git Repo mehr sauber und einfach ist außer Notwendigkeit, Setup zu verwenden, ein Post-Update-Haken.

Plan 1 ist auch arbeitsfähig, verwenden Sie es in einem kleinen Projekt oder Entwicklung mechine ist in Ordnung, aber hüten Sie sich die Zugriffsrechte auf .git-Verzeichnis, vor allem beim Wechsel des Web-Servers. zB: nginx unterstützt nicht .htaccess, welches oft in git mit anderen Projektdateien zusammen gespeichert wird.