Kivitendo Installationen mit git verwalten: Unterschied zwischen den Versionen
Zeile 3: | Zeile 3: | ||
== Neue kivitendo Installation mit git einrichten == | == Neue kivitendo Installation mit git einrichten == | ||
− | mkdir /var/www/kivitendo/firma | + | mkdir /var/www/kivitendo/firma |
− | + | cd /var/www/kivitendo/firma | |
− | cd /var/www/kivitendo/firma | + | git clone https://github.com/kivitendo/kivitendo-erp.git |
− | |||
− | git clone https://github.com/kivitendo/kivitendo-erp.git | ||
− | |||
(Dadurch wird ein Unterverzeichnis /var/www/kivitendo/firma/kivitendo-erp erzeugt und darin die gesamte kivitendo-Installation inkl. einem unsichtbaren Unterordner /var/www/kivitendo/firma/kivitendo-erp/.git für die git-Versionsverwaltung. | (Dadurch wird ein Unterverzeichnis /var/www/kivitendo/firma/kivitendo-erp erzeugt und darin die gesamte kivitendo-Installation inkl. einem unsichtbaren Unterordner /var/www/kivitendo/firma/kivitendo-erp/.git für die git-Versionsverwaltung. | ||
− | + | cd kivitendo-erp | |
− | cd kivitendo-erp | + | git tag |
− | |||
− | git tag | ||
− | |||
(zeigt die vorhandenen releases an) | (zeigt die vorhandenen releases an) | ||
− | + | git checkout -b produktiv release-3.4.0 | |
− | git checkout -b produktiv release-3.4.0 | + | (erstellt den neuen Branch "produktiv" mit allen Änderungen bis und mit dem gewünschten Release, in diesem Beispiel release-3.4.0)<br /> |
− | |||
− | (erstellt den neuen Branch "produktiv" mit allen Änderungen bis und mit dem gewünschten Release, in diesem Beispiel release-3.4.0) | ||
− | |||
Eventuelle '''nach''' dem Release erstellte wichtige Bugfixes installieren: | Eventuelle '''nach''' dem Release erstellte wichtige Bugfixes installieren: | ||
− | + | git cherry-pick commit-Bezeichnung | |
− | git cherry-pick commit-Bezeichnung | ||
− | |||
Konfigurationsdatei erstellen: | Konfigurationsdatei erstellen: | ||
− | + | cd config | |
− | cd config | + | cp kivitendo.conf.default kivitendo.conf |
− | + | kivitendo.conf editieren und anpassen<br /> | |
− | cp kivitendo.conf.default kivitendo.conf | ||
− | |||
− | kivitendo.conf editieren und anpassen | ||
− | |||
Damit ist die Installation auf dem Server abgeschlossen und alles weitere kann über den Aufruf der Web-Administration eingerichtet werden. | Damit ist die Installation auf dem Server abgeschlossen und alles weitere kann über den Aufruf der Web-Administration eingerichtet werden. | ||
Zeile 38: | Zeile 23: | ||
'''Wichtig:''' Backup der Datenbank(en) erstellen !! | '''Wichtig:''' Backup der Datenbank(en) erstellen !! | ||
+ | git checkout master | ||
+ | (wechselt zum master-Branch) | ||
+ | git pull | ||
+ | (fügt dem lokalen master-Branch alle Änderungen aus dem master Branch im github-Repository hinzu) | ||
+ | git checkout produktiv | ||
+ | (wechselt wieder zum Branch produktiv) | ||
+ | git merge release 3.4.1 | ||
+ | (erweitert den Branch produktiv auf das gewünschte Release, in diesem Beispiel release 3.4.1)<br /> | ||
+ | Anschliessend zunächst einmal im Administrations-Interface einloggen und anschliessend im normalen Benutzer-Weblogin. | ||
+ | Falls Datenbank Upgrades nötig sind, werden diese nun ausgeführt.<br /> | ||
+ | ('''Achtung:''' sobald ein Datenbankupgrade durchgeführt wurde, ist es nur möglich, mit git wieder zu einem Zustand vor dem Datenbankupgrade zurückzukehren, wenn die Datenbank aus dem vorher erstellten Backup zurückgespielt wurde.) | ||
− | + | == Verwenden eines anderen Branches aus dem github-Repository == | |
− | + | Alle auf github vorhandenen Branches anzeigen: | |
+ | git branch -a | ||
+ | Branch auswählen, z.B. design_4.0-rebase-3.5.4+<br /> | ||
+ | Lokalen Branch als Kopie des Branches auf github erstellen: | ||
+ | git checkout -b design_4.0-rebase-3.5.4+ origin/design_4.0-rebase-3.5.4+ | ||
− | + | == Aktualisieren eines lokalen Branches, dessen Original durch ein Rebase verändert wurde == | |
− | + | git reset --hard origin/design_4.0-rebase-3.5.4+ | |
− | git | + | == Einsatz eines zusätzlichen (lokalen) git-Repositorys == |
− | ( | + | Repository in .git/config eintragen und Namen dafür auswählen (statt "origin" z.B. bei uns lokal: "revamp"): |
+ | [remote "revamp"] | ||
+ | url = delfin-web:/var/lib/git/kivitendo-erp.git | ||
+ | fetch = +refs/heads/*:refs/remotes/revamp/* | ||
− | git | + | Branch aus dem neuen Repository holen: |
+ | git fetch revamp | ||
+ | git checkout -b neuerbranch revamp/neuerbranch | ||
− | + | == Commits von einem Branch in einen anderen übernehmen == | |
− | + | * Voraussetzung: beider Branches müssen lokal vorhanden sein und mit 'git branch' angezeigt werden. | |
− | + | * Hash des Commits ermitteln, der übernommen werden soll, z.B. mit 'git log' | |
− | + | * In den Branch wechseln, in den der Commit übernommen werden soll: | |
+ | git checkout branch1 | ||
+ | * Commit aus Branch2 übernehmen: | ||
+ | git cherrypick HASH_DES_COMMITS_AUS_BRANCH2 | ||
− | == | + | == Letzten lokalen Commit rückgängig machen, um ihn abändern zu können == |
− | + | git reset --soft HEAD^ | |
+ | Nun können mit 'git status' alle Dateien angezeigt werden, die durch den Commit verändert wurden.<br /> | ||
+ | Weitere Änderungen sind nun möglich und anschliessend kann ein neuer Commit erzeugt werden.<br /><br /> | ||
+ | Anzeigen der bisherigen Änderungen in einer Datei, die noch nicht als Commit übermittelt wurden: | ||
+ | git diff Dateiname | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
[[Kategorie:Kivitendo]] | [[Kategorie:Kivitendo]] |
Version vom 4. Dezember 2019, 19:54 Uhr
Voraussetzungen: Linux Installation (z.B. Debian Jessie) mit git und allen für kivitendo benötigten Paketen (siehe kivitendo Dokumentation), Webserver- und Postgres-Konfiguration gemäss kivitendo Dokumentation.
Neue kivitendo Installation mit git einrichten
mkdir /var/www/kivitendo/firma cd /var/www/kivitendo/firma git clone https://github.com/kivitendo/kivitendo-erp.git
(Dadurch wird ein Unterverzeichnis /var/www/kivitendo/firma/kivitendo-erp erzeugt und darin die gesamte kivitendo-Installation inkl. einem unsichtbaren Unterordner /var/www/kivitendo/firma/kivitendo-erp/.git für die git-Versionsverwaltung.
cd kivitendo-erp git tag
(zeigt die vorhandenen releases an)
git checkout -b produktiv release-3.4.0
(erstellt den neuen Branch "produktiv" mit allen Änderungen bis und mit dem gewünschten Release, in diesem Beispiel release-3.4.0)
Eventuelle nach dem Release erstellte wichtige Bugfixes installieren:
git cherry-pick commit-Bezeichnung
Konfigurationsdatei erstellen:
cd config cp kivitendo.conf.default kivitendo.conf
kivitendo.conf editieren und anpassen
Damit ist die Installation auf dem Server abgeschlossen und alles weitere kann über den Aufruf der Web-Administration eingerichtet werden.
Upgrade auf neues Release
Wichtig: Backup der Datenbank(en) erstellen !!
git checkout master
(wechselt zum master-Branch)
git pull
(fügt dem lokalen master-Branch alle Änderungen aus dem master Branch im github-Repository hinzu)
git checkout produktiv
(wechselt wieder zum Branch produktiv)
git merge release 3.4.1
(erweitert den Branch produktiv auf das gewünschte Release, in diesem Beispiel release 3.4.1)
Anschliessend zunächst einmal im Administrations-Interface einloggen und anschliessend im normalen Benutzer-Weblogin.
Falls Datenbank Upgrades nötig sind, werden diese nun ausgeführt.
(Achtung: sobald ein Datenbankupgrade durchgeführt wurde, ist es nur möglich, mit git wieder zu einem Zustand vor dem Datenbankupgrade zurückzukehren, wenn die Datenbank aus dem vorher erstellten Backup zurückgespielt wurde.)
Verwenden eines anderen Branches aus dem github-Repository
Alle auf github vorhandenen Branches anzeigen:
git branch -a
Branch auswählen, z.B. design_4.0-rebase-3.5.4+
Lokalen Branch als Kopie des Branches auf github erstellen:
git checkout -b design_4.0-rebase-3.5.4+ origin/design_4.0-rebase-3.5.4+
Aktualisieren eines lokalen Branches, dessen Original durch ein Rebase verändert wurde
git reset --hard origin/design_4.0-rebase-3.5.4+
Einsatz eines zusätzlichen (lokalen) git-Repositorys
Repository in .git/config eintragen und Namen dafür auswählen (statt "origin" z.B. bei uns lokal: "revamp"):
[remote "revamp"] url = delfin-web:/var/lib/git/kivitendo-erp.git fetch = +refs/heads/*:refs/remotes/revamp/*
Branch aus dem neuen Repository holen:
git fetch revamp git checkout -b neuerbranch revamp/neuerbranch
Commits von einem Branch in einen anderen übernehmen
- Voraussetzung: beider Branches müssen lokal vorhanden sein und mit 'git branch' angezeigt werden.
- Hash des Commits ermitteln, der übernommen werden soll, z.B. mit 'git log'
- In den Branch wechseln, in den der Commit übernommen werden soll:
git checkout branch1
- Commit aus Branch2 übernehmen:
git cherrypick HASH_DES_COMMITS_AUS_BRANCH2
Letzten lokalen Commit rückgängig machen, um ihn abändern zu können
git reset --soft HEAD^
Nun können mit 'git status' alle Dateien angezeigt werden, die durch den Commit verändert wurden.
Weitere Änderungen sind nun möglich und anschliessend kann ein neuer Commit erzeugt werden.
Anzeigen der bisherigen Änderungen in einer Datei, die noch nicht als Commit übermittelt wurden:
git diff Dateiname