Der aktuelle Stable-Release, bzw. beta Release wird bei github +
Der aktuelle Stable-Release, bzw. beta Release wird bei github gehostet und kann hier - heruntergeladen werden.
Die kivitendo ERP Installationsdatei
- (kivitendo-erp-3.4.1.tgz) wird im
+ heruntergeladen werden.
Das aktuelleste kivitendo ERP-Archiv
+ (kivitendo-erp-*.tgz) wird dann im
Dokumentenverzeichnis des Webservers (z.B.
/var/www/html/,
/srv/www/htdocs oder
/var/www/) entpackt:
cd /var/www -tar xvzf kivitendo-erp-3.4.1.tgz
Wechseln Sie in das entpackte Verzeichnis:
cd kivitendo-erp
Alternativ können Sie auch einen Alias in der +tar xvzf kivitendo-erp-*.tgz
Wechseln Sie in das entpackte Verzeichnis:
cd kivitendo-erp
Alternativ können Sie auch einen Alias in der Webserverkonfiguration benutzen, um auf das tatsächliche Installationsverzeichnis zu verweisen.
Bei einer Neuinstallation von Version 3.1.0 oder später muà das WebDAV Verzeichnis derzeit manuell angelegt werden:
mkdir webdav
Die Verzeichnisse users,
@@ -17,7 +17,7 @@ tar xvzf kivitendo-erp-3.4.1.tgz
Wechseln Sie in das entpackte Verzeichn
restlichen Dateien müssen für diesen Benutzer lesbar sein. Die Benutzer-
und Gruppennamen sind bei verschiedenen Distributionen unterschiedlich
(z.B. bei Debian/Ubuntu www-data, bei Fedora
- apache oder bei OpenSUSE
+ apache oder bei openSUSE
wwwrun).
Der folgende Befehl ändert den Besitzer für die oben genannten Verzeichnisse auf einem Debian/Ubuntu-System:
chown -R www-data users spool webdav
Weiterhin muss der Webserver-Benutzer in den Verzeichnissen
templates und users
@@ -28,35 +28,41 @@ tar xvzf kivitendo-erp-3.4.1.tgz
Wechseln Sie in das entpackte Verzeichn die Pfade anpassen) bspw. wie folgt:
cd /var/www/ git clone https://github.com/kivitendo/kivitendo-erp.git cd kivitendo-erp/ -git checkout `git tag -l | egrep -ve "(beta|rc)" | tail -1`
+git checkout `git tag -l | egrep -ve "(alpha|beta|rc)" | tail -1`
Erläuterung: Der Befehl wechselt zur letzten Stable-Version (git tag - -l listet alle Tags auf, das egrep schmeisst alle Einträge mit beta - oder rc raus und das tail gibt davon den obersten Treffer zurück). - Sehr sinnvoll ist es, direkt im Anschluss einen eigenen Branch zu - erzeugen, um bspw. seine eigenen Druckvorlagen-Anpassungen damit zu - verwalten. Hierfür reicht ein simples
git checkout -b meine_eigenen_änderungen
+ -l listet alle Tags auf, das egrep schmeisst alle Einträge mit alpha, + beta oder rc raus und das tail gibt davon den obersten Treffer + zurück). Sehr sinnvoll ist es, direkt im Anschluss einen eigenen + Branch zu erzeugen, um bspw. seine eigenen Druckvorlagen-Anpassungen + damit zu verwalten. Hierfür reicht ein simples
git checkout -b meine_eigenen_änderungen
nach dem letzten Kommando (weiterführende Informationen Git Magic).
Ein beispielhafter Workflow für Druckvorlagen-Anpassungen von 3.4.1 nach 3.5:
$ git clone https://github.com/kivitendo/kivitendo-erp.git $ cd kivitendo-erp/ -$ git checkout release-3.4.1 # das ist der aktuelle release, den wir wollen -$ git add templates/fullhouse # das sind unsere druckvorlagen inkl. produktbilder -$ git commit -m "juhu tolle ändernungen" +$ git checkout release-3.4.1 # das ist ein alter release aus dem wir starten ... +$ git checkout -b meine_eigene_änderungen # unser lokaler branch - unabhängig von allen anderen +$ git add templates/mein_druck # das sind unsere druckvorlagen inkl. produktbilder +$ git commit -m "juhu tolle änderungen" + [meine_aenderungen 1d89e41] juhu tolle ändernungen 4 files changed, 380 insertions(+) - create mode 100644 templates/fullhouse/img/webdav/tesla.png - create mode 100644 templates/fullhouse/mahnung.tex - create mode 100644 templates/fullhouse/zahlungserinnerung_zwei.tex - create mode 100644 templates/fullhouse/zahlungserinnerung_zwei_invoice.tex + create mode 100644 templates/mein_druck/img/webdav/tesla.png + create mode 100644 templates/mein_druck/mahnung.tex + create mode 100644 templates/mein_druck/zahlungserinnerung_zwei.tex + create mode 100644 templates/mein_druck/zahlungserinnerung_zwei_invoice.tex # 5 Jahre später ... +# webserver abschalten! + +$ git checkout master +$ git pull # oder git fetch und danach ein stable release tag auswählen (s.o.) +$ git checkout meine_eigenen_änderungen +$ git rebase master -$ git fetch -$ git rebase --onto release-3.5.0 release-3.4.1 meine_aenderungen Zunächst wird der Branch zurückgespult, um Ihre Ãnderungen darauf neu anzuwenden ... -Wende an: juhu tolle ändernungen -$ service apache2 restart +Wende an: juhu tolle änderungen +$ service apache2 restart # webserver starten!