Mit Git die eigene Website verwalten

[TuxuT]

Hallo Gemeinde,

ich würde gerne meine Website unter Git-Versionskontrolle stellen doch leider verstehe ich den Workflow noch nicht ganz...
Auf meinem Webserver habe ich jedenfalls erfolgreich ein Git-Repository anlegen können.
Das Repo liegt unter ./[home]/Git_repo

Die Dateien meiner Homepage sind alle unter ./[home]/public_html gehosted, dieser Ordner liegt also parallel zu /[home]/Git_repo.
Zum Entwickeln meiner Homepage hätte ich jetzt gerne ein Live-System (direkt unter /public_html) und ein Development-System (unter /public_html/development/).
Ich würde also neue Funktionen erst unter einem development-Branch entwickeln und wenn diese korrekt funktionieren, in den master-Branch also in das Live-System mergen.

Muss ich jetzt mein Git-Repository 2x auschecken? Einmal nach /public_html und dann nochmal nach /public_html/testing?
Ich verstehe das nicht so ganz.
Wichtig ist zudem, dass diese beiden Checkouts ja immer auf die HEAD-Revision des jeweiligen branches zeigen, sonst funktioniert es ja nicht.

./[home]/public_html --> MASTER-Branch
./[home]/public_html/testing --> DEVELOPMENT-Branch

Ich habe das remote repository ja lokal auf meinem Rechner geklont. Wenn ich meine Änderungen pushe, müssen die serverseitigen Webspace-Ordner automatisch geupdated werden...
Ziel ist natürlich zudem, dass ich vollständig auf einen FTP-Client zum Hochladen der Dateien verzichten kann.
Wie gesagt, ich habe derzeit keine Ahnung wie man das realsiiert.
Kann mir vllt hier jemand erläutern wie ein korrekter Workflow aussieht bzw. Webdesign mit Git-Kontrolle funktioniert?
Wo ist mein Denkfehler?

Herzlichen Dank und viele Grüße
Stefan

 

[Crumar]

Ich vermute besser wäre es für dich, git nur zum entwickeln zu verwenden und dann Deployment Pipelines zu verwenden. Gitlab hat sowas z. B., bei anderen weiß ich es nicht, selbst hab ichs auch noch nicht verwendet. Klingt aber meiner meinung nach dem, was du ordentlicherweise tun solltest

 

[deveth0]

Ja, du musst das git repo zweimal clonen, einmal master, einmal develop.
Anschließend würde ich einen cronjob anlegen, der alle paar Minuten beide repos aktualisiert.
Schöner wäre da natürlich ein Buildserver (jenkis, gitlab ci...) aber auch völliger Overkill.

Das sollte es dann eigentlich auch schon gewesen sein

 

[andy_m4]

Auf meinem Webserver habe ich jedenfalls erfolgreich ein Git-Repository anlegen können.

Wozu auf dem Webserver?

Ich würde es lokal zum entwickeln nutzen. Die Sache wie man seinen Kram auf den Webserver bekommt würde ich getrennt davon zu betrachten. Und ich würde das auch nicht mit git machen.
git ist eine Versionsverwaltung und kein Deployment-Tool.

 

[character]

Bei Heroku wird auch mit git deployed, überhaupt kein Problem.

 

[deveth0]

GitHub pages auch. Was spricht denn aus deiner Sicht dagegen?

 

[0x8100]

https://en.internetwache.org/dont-p...urcecode-an-analysis-of-alexas-1m-28-07-2015/

 

[TuxuT]

Ja, du musst das git repo zweimal clonen, einmal master, einmal develop.
Anschließend würde ich einen cronjob anlegen, der alle paar Minuten beide repos aktualisiert.
Schöner wäre da natürlich ein Buildserver (jenkis, gitlab ci...) aber auch völliger Overkill.

Das sollte es dann eigentlich auch schon gewesen sein

Okay - Danke. Das werde ich ausprobieren...
Es macht auch keine Probleme dass der eine Klon in dem anderen verschachtelt ist?
Also der Klon für Testing würde ja in dem Klon von der aktuellen Internetseite ("Live-System") stecken...

Und wie würde dieser Cronjob aussehen. Ist das einfach ein Skript, das die Git-Befehle für das Updaten des Master- und Development-Branch enthät?

Danke nochmal!

PS: Das Repo liegt auf dem Server, da ich evtl. in Zukunft nicht als einziger an der Homepage bastle. Wenn man mit mehreren Personen entwickelt, geht wohl kein Weg an einem zentralen Repository vorbei.

 

[deveth0]

Naja ich würde das schon in nen extra verzeichnis parallel packen, wenn das nicht geht, dann auf jedenfall die git ignore anpassen.

Der link von 0x8100 ist auch lesenswert.
Und ja, der cronjob ist ein Skript was einfach nen pull macht.
Ist das dein eigener Server?

 

[Kanibal]

Stichwort: Push-to-Deploy.
Gibt es massenhaft Anleitungen dafür:
- http://krisjordan.com/essays/setting-up-push-to-deploy-with-git
- https://www.digitalocean.com/commun...t-up-automatic-deployment-with-git-with-a-vps

Wichtig wäre nur, dass Du per Webserver den Zugriff auf das .git-Verzeichnis unterbindest.

 

[RalphS]

Ich schlag vor, auch mal in das ganze Konzept der virtuellen(!) Ordnerstruktur von Webservern zu schauen. Public_html ist schon ein Stamm, darunter sollte man lieber keine weiteren Stammpfade anlegen.

Git kann ansonsten durchaus verschiedene Branches eines repository in verschiedenen (Dateisystem) Verzeichnissen verwalten. Im workdir landet dann nur eine Textdatei namens .git statt des Unterordners.

Stichwort dafür ist git worktree.
Sinnvolle Struktur im physischen Dateisystem könnte sein:

/SourceCode/gitrepository/.git
/websites/prod
/websites/devel

Dann die beiden Referenz-.git-Dateien in prod und devel für world sperren.

Oder den Websitestamm jeweils eine Verzeichnisebene darunter. Name ist egal, sollte nur sprechend sein.

Dann prod und devel als jeweils eigene Website oder virtuellen Ordner bereitstellen.

 

[TuxuT]

Vielen Dank, das bringt mich jetzt ein ganzes Stück weiter!!!
Die Geschichte mit den hooks scheint ziemlich mächtig zu sein.
Hiermit werden die zeitgesteuerten Cronjobs vermutlich überflüssig oder? (da man jetzt tatsächlich direkt auf die pull- und push-Ereignisse reagieren kann)
Git gefällt mir...

 

[Bagbag]

Hiermit werden die zeitgesteuerten Cronjobs vermutlich überflüssig oder?

Ja