Git-Produktions- / Staging-Server-Workflow


108

Derzeit enthält meine Website (Produktionsserver) bereits viel Code. Und jetzt möchte ich Git für meine Projekte verwenden und einen Staging-Server für mein Team einrichten. Kann mir jemand einen Rat geben?

Hier ist das Bild in meinem Kopf:

        Production        - Production server which already have codes
            ↑             
         Staging          - New staging server, will install Trac too
         ↗↙ ↖↘          
  Developer1  Developer2  - Local development 

Meine Frage ist, wie soll ich anfangen?

Hier sind einige Schritte in meinem Kopf:

  1. Machen Sie einen git initIn-Production-Server (ist das sicher?)
  2. clone das Repo von der Produktion zum Staging-Server
  3. Entwickler clonedas Repo von der Inszenierung auf ihren lokalen Computer
  4. push Dateien auf dem Staging-Server nach Abschluss der Änderung
  5. Wenn die Inszenierung fertig ist, pushalles zur Produktion

Ist dieser Arbeitsablauf sinnvoll oder gibt es einen besseren Weg, dies zu tun?

Was ist, wenn ich nur eine Datei ändern möchte?

Hat origin / master in diesem Prozess etwas damit zu tun? Wer ist der Ursprung? werde ich am Ende mehrere Ursprünge haben?

Wann sollte ein Entwickler branchin diesem Fall verwenden?

Antworten:


59

Es ist besser, den Hauptzweig nur für den Produktions- und Entwicklungszweig für die Bereitstellung zu verwenden. Jeder Entwickler sollte einen lokalen Zweig erstellen, um neue Funktionen hinzuzufügen, und dann mit dem Entwicklungszweig zusammenführen. Wenn Sie neu in einem Git sind, versuchen Sie es mit - http://github.com/nvie/gitflow Es gibt auch ein gutes Bild, das das Git-Verzweigungsmodell beschreibt - http://nvie.com/posts/a-successful-git- Verzweigungsmodell /


Dies ist eine bessere Antwort. Ich war mit dem Konzept der Git-Verzweigung nicht sehr vertraut.
Kayue

@Fehler. Haben Sie einen Link zu einer Ressource, die den Entwicklungszweig erläutert -> Push-to-Staging-System und Master-Zweig -> Push-to-Production-Server ausführlicher? Der großartige Artikel Ein erfolgreiches Git-Verzweigungsmodell erwähnt diesen Teil nicht, selbst wenn es sehr gute Konzepte für Verzweigung und Versionierung erwähnt.
Edgar Alloro

19

Ihr Vorschlag sieht in Ordnung aus, aber ich würde nicht zulassen, dass die Entwickler direkt auf den Staging-Server pushen. Stattdessen sollte ein Integrator Zweige sorgfältig prüfen und in den Hauptzweig (oder den Entwicklungszweig, wenn Sie das von bUg vorgeschlagene Git-Flow-Modell verwenden) integrieren. * Dieselbe Person würde auf den Staging-Server pushen.

* Integrator : " Eine ziemlich zentrale Person, die als Integrator in einem Gruppenprojekt fungiert, erhält von anderen vorgenommene Änderungen, überprüft und integriert sie und veröffentlicht das Ergebnis, damit andere es verwenden können ... "


1. Führen Sie einen Git-Init im Produktionsserver durch (ist dies sicher?)

Ja, es ist sicher, aber Sie müssen natürlich sehr restriktive Berechtigungen für dieses Repo festlegen. Ich würde wahrscheinlich damit beginnen, curldie gesamte Website auf eine lokale CD zu übertragen, wenn ich sie noch nicht habe.

2. Klonen Sie das Repo von der Produktion auf den Staging-Server

Sie sollten wahrscheinlich ein "zentrales" Repo haben, das sowohl vom Produktions- als auch vom Staging-Server getrennt ist. Dieser kann nach Bedarf geklont und gepusht werden.

3. Entwickler klonen das Repo von der Bereitstellung auf ihren lokalen Computer

4. Drücken Sie die Dateien nach Abschluss der Änderung auf den Staging-Server

5. Wenn die Inszenierung fertig ist, schieben Sie alles in die Produktion

Ersetzen Sie "Staging" durch "Central" und ich denke, Sie sind in Ordnung, aber ein größeres Problem ist, wie Sie mit Zweigen arbeiten und zusammenführen, wie bUg betont.


10
1: Um Git Repo in der Produktion sicher zu machen, müssen Sie eine .htaccess-Datei mit dem Titel "Alle verweigern" hinzufügen.
Kayue

2
2: Felixyz '"zentrales" Repo bezieht sich auf nacktes Repo. Verwenden Sie den Befehl --bare, um ein nacktes Repo zu erstellen.
Kayue

1
@keyue 1: Noch besser, fügen Sie RedirectMatch 404 /\.gitzu Ihrer Produktion .htaccess Ihre schützen .gitignore , .gitattributes und .git Ordner.
Leo
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.