Git für Websites / Post-Empfangs- / Trennung von Test- und Produktionsstandorten

Question

Ich verwende Git meiner Website-Quellcode und Bereitstellung zu verwalten, und derzeit haben den Test und Live-Sites auf dem gleichen Feld läuft. Im Anschluss an diese Ressource http://toroid.org/ams/git-website-howto ursprünglich kam ich mit dem folgenden Post erhalten Hook-Skript up zwischen Schüben meiner Live-Site und Schüben meiner Test-Site zu unterscheiden:

while read ref
do
  #echo "Ref updated:"
  #echo $ref -- would print something like example at top of file
  result=`echo $ref | gawk -F' ' '{ print $3 }'`
  if [ $result != "" ]; then
    echo "Branch found: "
    echo $result
    case $result in
      refs/heads/master )
        git --work-tree=c:/temp/BLAH checkout -f master
        echo "Updated master"
        ;;
      refs/heads/testbranch )
        git --work-tree=c:/temp/BLAH2 checkout -f testbranch
        echo "Updated testbranch"
        ;;
      * )
        echo "No update known for $result"
        ;;
    esac
  fi
done
echo "Post-receive updates complete"

Allerdings habe ich Zweifel, dass dies tatsächlich sicher ist :) ich keineswegs bin ein Experte Git, aber ich vermute, dass Git wahrscheinlich Spur des aktuellen hält abgemeldeten Zweig Kopf, und dieser Ansatz hat wahrscheinlich das Potenzial es zu keinem Ende zu verwirren.

So ein paar Fragen:

1. Ist das sicher?

2. wäre ein besserer Ansatz, um meine Basis zu haben Repository die Test-Site-Repository (mit Arbeitsverzeichnis entspricht), und hat dann das Repository Push Änderungen in einen neuen Live-Site-Repository, das ein entsprechendes Arbeitsverzeichnis der hat Live-Site Basis? Dies würde auch erlauben Sie mir, die Produktion auf einen anderen Server zu verschieben und die Stationierung Kette intakt halten.

3. Gibt es etwas, was ich bin fehlt? Gibt es eine andere, saubere Art und Weise zwischen Test- und Produktionsimplementierungen zu unterscheiden, wenn für die Verwaltung von Websites mit Git?

Als zusätzliche Anmerkung im Lichte der Vi Antwort, ist es ein guter Weg, dies zu tun, die viele Deletionen ohne Ausmisten mit dem Dateisystem umgehen würden?

Danke, -Walt

PS - Das Skript, das ich mit für die mehrere repos kam (und bin mit, wenn ich besser hören) ist wie folgt:

sitename=`basename \`pwd\``

while read ref
do
  #echo "Ref updated:"
  #echo $ref -- would print something like example at top of file
  result=`echo $ref | gawk -F' ' '{ print $3 }'`
  if [ $result != "" ]; then
    echo "Branch found: "
    echo $result
    case $result in
      refs/heads/master )
        git checkout -q -f master
        if [ $? -eq 0 ]; then
            echo "Test Site checked out properly"
        else
            echo "Failed to checkout test site!"
        fi
        ;;
      refs/heads/live-site )
        git push -q ../Live/$sitename live-site:master
        if [ $? -eq 0 ]; then
            echo "Live Site received updates properly"
        else
            echo "Failed to push updates to Live Site"
        fi
        ;;
      * )
        echo "No update known for $result"
        ;;
    esac
  fi
done
echo "Post-receive updates complete"

Und dann die Repo in ../Live/$sitename (diese sind „nackt“ repos mit Arbeits Bäumen nach init hinzugefügt) haben die grundlegende Post erhalten:

git checkout -f
if [ $? -eq 0 ]; then
    echo "Live site `basename \`pwd\`` checked out successfully"
else
    echo "Live site failed to checkout"
fi

Answer 1

  

wäre ein besserer Ansatz, um meinen zu haben   Basis-Repository der Teststelle sein   Repository (mit entsprechenden Arbeits   Verzeichnis), und dann haben, dass   Repository Push wechselt zu einem neuen Live   Website-Repository, das eine hat   entsprechend dem Arbeitsverzeichnis   Live-Site Basis? Dies würde auch erlauben,   ich um die Produktion zu einem Umzug   andere Server und halten die   Einsatz Kette intakt.

Ja auf jeden Fall. Es ist eine sehr seltene Gelegenheit, die Sie Ihren Testort wollen direkt neben dem Produktionsstandort gehostet. Es ist gefährlich und unprofessionell in fast jeder Hinsicht, nicht zu sprechen von einer Beschädigung der Datenbank, Webserver lockups usw.

Ich habe in der Regel eine VM Setup-Zwecke zum Testen. Funktioniert sehr gut und ich kann es mit mir auf meinem Laptop während der Reise.

git Verwenden Sie Ihre Website zu implementieren ist eine sehr gute Idee, es gibt eine Menge anderer Leute so tun (zum Beispiel Rob Conery). Wenn Sie eine Live-und Test Website haben passieren sowieso, sollten Sie separate Zweige haben für sie in Ihrem Repository, Set-up als Fernverfolgung Zweige auf den entsprechenden Server-Repositorys. Ihr Workflow wird so einfach, wie Arbeit in Ihrem Testzweig zu tun, schieben Sie es zu testen, testen es, verschmelzen zu leben und zu schieben zu Hause sind.

Ehrlich gesagt, machen Sie nicht zu hart es für sich selbst.

Answer 2

Denken Sie, dass in beiden Richtungen funktionieren.

Sie können auch "git-Archiv Master | tar -C c: / temp / BLAH -x" verwenden. Und "git Live-Ort-Archiv | ssh Live-site 'tar -C / var / www -x'"

getrennte Repositories halten kann nützlich sein, aber „Push in einem anderen Push-bezogene Haken“ sieht heikel und ich erwarte, dass es langsam sein. Sortieren langkettiger, die langsam und zerbrechlich sein wird.

Live-Site Updates sollte manuell nach der Prüfung ausgelöst werden, um die "testing" Version sein kann?

Answer 3

Ich folgte auch die gleiche Führung bei toroid.org, aber ich mag darauf hinweisen, dass, obwohl Sie mit einem nackten Repository gestartet, indem ein Arbeitsverzeichnis hinzufügen, wird zusätzliche Behandlung am ehesten benötigt werden. Ich fand, dass die folgenden Haken ist nützlich, wenn Sie Inhalte, die dynamisch oder auf andere Weise ändern können und wollen nicht verlieren Daten, wenn git checkout -f mit

vorab erhalten

#!/bin/sh
git add -A
git diff --quiet --cached
if [ $? -gt 0 ]; then
    git commit --quiet -m "autocommit"
    echo "Working Directory was out of sync. Pull to receive updated index."
    exit 1
fi

Dies wird ein Push-Stopp, wenn es Veränderungen in dem Remote-Arbeitsverzeichnis. Betrachten Sie es als jemand (der Webserver) Änderungen vornehmen, aber vergessen, sie zu begehen. Mit checkout mit dem -f diese Änderungen verwerfen. Dieser Haken ist ein guter Ort, um dies zu verhindern, aber es wäre schön, wenn es auch ein Haken auf dem Remote-Server vor einem Pull genannt wird, so dass Sie diese Änderungen erhalten würden nahtlos.

Post erhalten

#!/bin/sh
git checkout -f
echo "Working directory synced."

In Bezug auf zwei Zweige haben, dachte ich, die erste Lösung eleganter war als mit mehreren Repositorys beschäftigen. Wenn Sie wirklich Ihre Produktionsstätte isoliert halten möchten, können Sie rsync lokal verwendet werden, die ähnlich Delta-Patching hat. Ich würde mit einer Prüfung und stabilen Zweig im Repository hat nur die Prüfstelle als Arbeitsverzeichnis. Wenn Sie bereit sind, die Tests in den stabilen Zweig, Push-to-Release verschmelzen, und einen Haken für Commits stabilen Zweig den Zuruf rsync suchen haben.