Ich habe zwei gängige Ansätze zur automatischen Bereitstellung von Website-Updates mit einem blossen Remote-Repo gefunden.
Der erste erfordert, dass der Repo in das Dokumentenstammverzeichnis des Webservers geklont wird und im Post-Update-Hook ein git pull verwendet wird.
%Vor%Der zweite Ansatz fügt dem leeren Repository einen "detached work tree" hinzu. Der Post-Receive-Hook verwendet git checkout -f , um den HEAD des Repositorys in das Arbeitsverzeichnis zu replizieren, das das Root-Dokument des Webservers ist, d. H.
%Vor%Der erste Ansatz hat den Vorteil, dass Änderungen, die im Arbeitsverzeichnis der Website vorgenommen werden, festgeschrieben und an das leere Repo zurückgegeben werden können (Dateien sollten jedoch nicht auf dem Live-Server aktualisiert werden). Der zweite Ansatz hat den Vorteil, dass sich das git-Verzeichnis nicht innerhalb des Dokumentstammverzeichnisses befindet, aber dies kann leicht mit htaccess gelöst werden.
Ist eine Methode in puncto Best Practice objektiv besser als die andere? Welche anderen Vor- und Nachteile fehle ich?
In Bezug auf das Release-Management (hier Bereitstellung) ist es am besten, eine Zielumgebung zu haben, die unabhängig vom Release-Mechanismus ist.
Mit anderen Worten, die zweite Lösung ( checkout -f ) ändert eine einfache Webverzeichnisstruktur ohne weitere Unterverzeichnisse, die nicht Teil davon sein sollten (wie ein .git -Ordner).
Ich benutze es zum Beispiel in " Verwenden von git zum Bereitstellen meiner node.js-App auf meinem Produktionsserver ".
Dadurch werden Nebeneffekte minimiert und die Produktionsumgebung kann genau so arbeiten, wie sie benötigt wird, ohne Interferenzen.
Tags und Links git web-deployment