Habe mich erneut in das Thema Git/SCM hineingelesen und möchte es jetzt umsetzen, da der Bedarf besteht.
Ziel:
Auf externen (remote) Host ein Bare-Repo haben, worauf Redmine (Ist wie Trac) zugreift und Tickets automatisch mit dem entsprechenden Patch verlinkt werden.
Nennen wir das Repo: ProjektWPTemplate
Auf dem gleichen Server befindet sich die Live-Demo von Wordpress mit dem Template.
Lokal arbeite ich auch offline an den Daten und habe eine Wordpressinstallation auf meinem lokalen Webserver.
Ausgearbeitete Lösung:
Bare-Repo auf dem Server anlegen.
Repo auf meinen PC klonen (kein Bare-Repo, mit Arbeitskopie), daran arbeiten mit git add/git commit und zurückspielen via git push origin master.
Fragen:
1.)
Im von mit genannten Projekt handelt es sich z.B. nur um ein Wordpress Theme, das unter wp/themes/meintheme lokal liegt.
Wo sollte das geklonte Repo mit Arbeitskopie am besten lokal liegen?
Im [ich@lokal ~], also Homeverzeichnis und dann via Symlink ein Ordner im eigentlichen documentroot/wp/themes/meintheme legen?
Oder sollte es genau andersherum gemacht werden, das Bare-Repo in documentroot/wp/themes/meintheme geklont werden und dann im ~ Verzeichnis ein Symlink dorthin erstellen?
Es erscheint mir sinnvoll, dass alle lokalen Git Repos in einem Verzeichnis liegen, damit sie schnell auffindbar sind.
(Zwecks schnelleren Commit/Push würde ich mir dann ein alias lokal anlegen in .bash_profile)
2.)
Ebenfalls wie bei 1.), wo ist es am sinnvollsten das Git Repo auf dem remote host (externen Server) zu legen?
Da dort ebenfalls die Kundendemo ist, die laufend aktualisiert werden sollte, sehe ich verschiedene Möglichkeiten:
a.) Das Bare-Repo wird direkt im documentroot/kundendemo/wp/themes auf dem externen Server angelegt.
b.) Ich lege das Bare-Repo in ~ auf dem externen Server an und setze einen Symlink im documentroot/kundendemo/wp/themes
3.)
Z.Zt. greife nur ich auf das Repo zu. Es ist mittelfristig absehbar, dass mehrere Benutzer es verwenden werden. Dafür werde ich Gitolite verwenden. Ist es problemlos möglich zu einem späteren Zeitpunkt, wenn der Bedarf vorhanden ist, sich darum zu kümmern oder ist der Aufwand größer und Gitolite sollte sofort am Anfang installiert/konfiguriert werden?
4.)
Ist es ratsam bei solch einem Projekt, die gesamte Wordpressisnstallation als Repo zu nutzen (Vorteil sehe ich z.B. durch Möglichkeit des Rückspielens von überschriebenen Dateien bei automatischen Update von Wordpress die zu inkompatibilitäten führen könnten).
Wenn ja, wie sieht es praktisch mit Dateien wie der Datenbankkonfigurationsdatei aus, die sich unterscheidet auf lokalem und externen Server.
5.)
Ist das ein empfehlenswerter Workflow zur Nutzung von Git in Verbindung mit Redmine oder gibt es Verbesserungsvorschläge?
Die Hauptfragen nochmal kurz und knackig zusammengefasst:
Ist der von mir zusammengestellte Workflow, der, der er sein sollte um das Ziel zu erreichen?
In welche Verzeichnisse sollte man ein lokal geklontes Repo (und auch das Bare-Repo auf dem externen Host) packen, wenn es z.B. um ein Theme geht, das ein Unterverzeichnis (wp/themes/) einer sowohl lokalen Wordpressinstallation ist (Zum Arbeiten) und auf dem remote host (Es ist ein Server, auf diesem liegtauch das Bare-Repo mit Redmine) als auch die Installation als Kundendemo liegt?
Herzlichen Dank, für die Zeit all derjenigen, die mir helfen!
Update1://
Beim weiteren Google bin ich darauf gestoßen, hört sich genau nach dem an was ich brauche?!
Update2://
Eine weitere Anleitung gefunden, hier auf php.de, dort wird es so beschrieben wie oben von mir gedacht, via Symlink anstatt anstatt zwei Repositories mit dem gleichen Inhalt (Wurde bei Update1:// vorgeschlagen):
Ziel:
Auf externen (remote) Host ein Bare-Repo haben, worauf Redmine (Ist wie Trac) zugreift und Tickets automatisch mit dem entsprechenden Patch verlinkt werden.
Nennen wir das Repo: ProjektWPTemplate
Auf dem gleichen Server befindet sich die Live-Demo von Wordpress mit dem Template.
Lokal arbeite ich auch offline an den Daten und habe eine Wordpressinstallation auf meinem lokalen Webserver.
Ausgearbeitete Lösung:
Bare-Repo auf dem Server anlegen.
Code:
[martha@eridanus ~]$ mkdir ProjektWPTemplate.git [martha@eridanus ~]$ cd ProjektWPTemplate.git [martha@eridanus myproject]$ git init --bare
Code:
[someuser@somehost ~]$ git clone ssh://martha@eridanus.de/home/martha/ProjektWPTemplate.git/ [someuser@somehost ~]$ cd ProjektWPTemplate [someuser@somehost ProjektWPTemplate]$ echo "Irgendetwas zum add+commit" > test.txt [someuser@somehost ProjektWPTemplate]$ git add test.txt [someuser@somehost ProjektWPTemplate]$ git commit -m "initial commit" [someuser@somehost ProjektWPTemplate]$ git push origin master
1.)
Im von mit genannten Projekt handelt es sich z.B. nur um ein Wordpress Theme, das unter wp/themes/meintheme lokal liegt.
Wo sollte das geklonte Repo mit Arbeitskopie am besten lokal liegen?
Im [ich@lokal ~], also Homeverzeichnis und dann via Symlink ein Ordner im eigentlichen documentroot/wp/themes/meintheme legen?
Oder sollte es genau andersherum gemacht werden, das Bare-Repo in documentroot/wp/themes/meintheme geklont werden und dann im ~ Verzeichnis ein Symlink dorthin erstellen?
Es erscheint mir sinnvoll, dass alle lokalen Git Repos in einem Verzeichnis liegen, damit sie schnell auffindbar sind.
(Zwecks schnelleren Commit/Push würde ich mir dann ein alias lokal anlegen in .bash_profile)
2.)
Ebenfalls wie bei 1.), wo ist es am sinnvollsten das Git Repo auf dem remote host (externen Server) zu legen?
Da dort ebenfalls die Kundendemo ist, die laufend aktualisiert werden sollte, sehe ich verschiedene Möglichkeiten:
a.) Das Bare-Repo wird direkt im documentroot/kundendemo/wp/themes auf dem externen Server angelegt.
b.) Ich lege das Bare-Repo in ~ auf dem externen Server an und setze einen Symlink im documentroot/kundendemo/wp/themes
3.)
Z.Zt. greife nur ich auf das Repo zu. Es ist mittelfristig absehbar, dass mehrere Benutzer es verwenden werden. Dafür werde ich Gitolite verwenden. Ist es problemlos möglich zu einem späteren Zeitpunkt, wenn der Bedarf vorhanden ist, sich darum zu kümmern oder ist der Aufwand größer und Gitolite sollte sofort am Anfang installiert/konfiguriert werden?
4.)
Ist es ratsam bei solch einem Projekt, die gesamte Wordpressisnstallation als Repo zu nutzen (Vorteil sehe ich z.B. durch Möglichkeit des Rückspielens von überschriebenen Dateien bei automatischen Update von Wordpress die zu inkompatibilitäten führen könnten).
Wenn ja, wie sieht es praktisch mit Dateien wie der Datenbankkonfigurationsdatei aus, die sich unterscheidet auf lokalem und externen Server.
5.)
Ist das ein empfehlenswerter Workflow zur Nutzung von Git in Verbindung mit Redmine oder gibt es Verbesserungsvorschläge?
Die Hauptfragen nochmal kurz und knackig zusammengefasst:
Ist der von mir zusammengestellte Workflow, der, der er sein sollte um das Ziel zu erreichen?
In welche Verzeichnisse sollte man ein lokal geklontes Repo (und auch das Bare-Repo auf dem externen Host) packen, wenn es z.B. um ein Theme geht, das ein Unterverzeichnis (wp/themes/) einer sowohl lokalen Wordpressinstallation ist (Zum Arbeiten) und auf dem remote host (Es ist ein Server, auf diesem liegtauch das Bare-Repo mit Redmine) als auch die Installation als Kundendemo liegt?
Herzlichen Dank, für die Zeit all derjenigen, die mir helfen!
Update1://
Beim weiteren Google bin ich darauf gestoßen, hört sich genau nach dem an was ich brauche?!
...
I assume you are trying to use Git for website publishing? ... . In short:
You create 2 repositories on the server. One is a bare repository, just like the one you have already created, but it's outside of the public_html directory
Other is a normal repository inside the public_html directory
You create a post-receive hook that updates the repository inside the public_html directory whenever you push to the bare repository
Quelle: http://stackoverflow.com/a/16161464
I assume you are trying to use Git for website publishing? ... . In short:
You create 2 repositories on the server. One is a bare repository, just like the one you have already created, but it's outside of the public_html directory
Other is a normal repository inside the public_html directory
You create a post-receive hook that updates the repository inside the public_html directory whenever you push to the bare repository
Quelle: http://stackoverflow.com/a/16161464
Eine weitere Anleitung gefunden, hier auf php.de, dort wird es so beschrieben wie oben von mir gedacht, via Symlink anstatt anstatt zwei Repositories mit dem gleichen Inhalt (Wurde bei Update1:// vorgeschlagen):
und das document root des ausgecheckten repository ist symlinked auf subdomain.domain.tld
Quelle: http://www.php.de/php-fortgeschritte...tml#post804995
Quelle: http://www.php.de/php-fortgeschritte...tml#post804995
Kommentar