Kivitendo Installationen mit git verwalten: Unterschied zwischen den Versionen

Aus revampedia
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
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
 +
cp kivitendo.conf.default kivitendo.conf
 +
kivitendo.conf editieren und anpassen<br />
 +
Damit ist die Installation auf dem Server abgeschlossen und alles weitere kann über den Aufruf der Web-Administration eingerichtet werden.
  
cd config
+
== Upgrade auf neues Release ==
  
cp kivitendo.conf.default kivitendo.conf
+
'''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 rebase release-3.6.0
 +
(erweitert den Branch produktiv auf das gewünschte Release, in diesem Beispiel release-3.6.0)<br />
 +
Falls Konflikte auftreten, diese lösen und dann jeweils weiter mit
 +
git rebase --continue
 +
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.)
  
kivitendo.conf editieren und anpassen
+
== Verwenden eines anderen Branches aus dem github-Repository ==
  
Damit ist die Installation auf dem Server abgeschlossen und alles weitere kann über den Aufruf der Web-Administration eingerichtet werden.
+
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+
  
== Upgrade auf neues Release ==
+
== Aktualisieren eines lokalen Branches, dessen Original durch ein Rebase verändert wurde ==
 +
git reset --hard origin/design_4.0-rebase-3.5.4+
  
'''Wichtig:''' Backup der Datenbank(en) erstellen !!
+
Sonderfall: Von diesem Branch (z.B. design_4.0-rebase-3.5.4+), der durch ein Rebase verändert wurde, wurde ein zusätzlicher Branch design4_firmaA erstellt, bei dem inzwischen weitere Änderungen durchgeführt wurden.<br />
 +
Um design4_firmaA auf den neusten Stand von design_4.0-rebase-3.5.4+ zu bringen, so dass alle Änderungen von design4_firmaA ans Ende gesetzt werden, muss beim rebase mit --onto gearbeitet werden:
 +
git rebase --onto design_4.0-rebase-3.5.4+ design_4.0-rebase-3.5.4+@{1}
 +
(Ein einfaches 'git rebase design_4.0-rebase-3.5.4+' kommt nicht klar damit, dass die Hashes von design_4.0-rebase-3.5.4+ gegenüber design4_firmaA geändert wurden.)
  
git checkout master
+
== Einsatz eines zusätzlichen (z.B. nicht öffentlichen) git-Repositorys ==
  
(wechselt zum master-Branch)
+
Repository in .git/config eintragen und Namen dafür auswählen (statt "origin" z.B. bei uns: "revamp" bzw. "revamp-extern"):
 +
[remote "revamp"]
 +
        url = delfin-web:/var/lib/git/kivitendo-erp.git
 +
        fetch = +refs/heads/*:refs/remotes/revamp/*
 +
Bzw. wenn das git-Repository extern via ssh erreichbar ist:
 +
[remote "revamp-extern"]
 +
        url = ssh://user@gitweb.revamp-it.ch:10322/var/lib/git/kivitendo-erp.git
 +
        fetch = +refs/heads/*:refs/remotes/revamp-extern/*
  
git pull
+
Branch aus dem neuen Repository holen:
 +
git fetch revamp-extern
 +
git checkout -b neuerbranch revamp-extern/neuerbranch
  
(fügt dem lokalen master-Branch alle Änderungen aus dem master Branch im github-Repository hinzu)
+
== Commits von einem Branch in einen anderen übernehmen ==
 
 
git checkout produktiv
 
  
(wechselt wieder zum Branch produktiv)
+
* 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
  
git merge release 3.4.1
+
== Letzten lokalen Commit rückgängig machen, um ihn abändern zu können ==
  
(erweitert den Branch produktiv auf das gewünschte Release, in diesem Beispiel release 3.4.1)
+
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
  
Anschliessend zunächst einmal im Administrations-Interface einloggen und anschliessend im normalen Benutzer-Weblogin.
+
== Lokalen Commit in ein Repository übertragen ==
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 ==
+
Falls der lokale Branch mit dem neuen Commit noch nicht auf dem Repository existiert:<br />
 +
(revamp: Bezeichnung des Repositorys in '.git/config')
 +
git push -u revamp lokaler-branch:neuer-remote-branch
 +
Falls der Branch auf dem Repository auch noch von anderen Personen mit Commits erweitert wird, unbedingt vor jeder neuen Änderung die bisherigen Änderungen im Repository lokal übernehmen:
 +
git pull
 +
Anschliessend kann lokal ein neuer Commit erstellt werden und dieser wiederum in das Repository übermittelt werden:
 +
git push
  
Alle auf github vorhandenen Branches anzeigen:
 
  
git branch -a
 
  
  
  
 
[[Kategorie:Kivitendo]]
 
[[Kategorie:Kivitendo]]

Aktuelle Version vom 28. Dezember 2022, 22:48 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 rebase release-3.6.0

(erweitert den Branch produktiv auf das gewünschte Release, in diesem Beispiel release-3.6.0)
Falls Konflikte auftreten, diese lösen und dann jeweils weiter mit

git rebase --continue

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+

Sonderfall: Von diesem Branch (z.B. design_4.0-rebase-3.5.4+), der durch ein Rebase verändert wurde, wurde ein zusätzlicher Branch design4_firmaA erstellt, bei dem inzwischen weitere Änderungen durchgeführt wurden.
Um design4_firmaA auf den neusten Stand von design_4.0-rebase-3.5.4+ zu bringen, so dass alle Änderungen von design4_firmaA ans Ende gesetzt werden, muss beim rebase mit --onto gearbeitet werden:

git rebase --onto design_4.0-rebase-3.5.4+ design_4.0-rebase-3.5.4+@{1}

(Ein einfaches 'git rebase design_4.0-rebase-3.5.4+' kommt nicht klar damit, dass die Hashes von design_4.0-rebase-3.5.4+ gegenüber design4_firmaA geändert wurden.)

Einsatz eines zusätzlichen (z.B. nicht öffentlichen) git-Repositorys

Repository in .git/config eintragen und Namen dafür auswählen (statt "origin" z.B. bei uns: "revamp" bzw. "revamp-extern"):

[remote "revamp"]
       url = delfin-web:/var/lib/git/kivitendo-erp.git
       fetch = +refs/heads/*:refs/remotes/revamp/*

Bzw. wenn das git-Repository extern via ssh erreichbar ist:

[remote "revamp-extern"]
       url = ssh://user@gitweb.revamp-it.ch:10322/var/lib/git/kivitendo-erp.git
       fetch = +refs/heads/*:refs/remotes/revamp-extern/*

Branch aus dem neuen Repository holen:

git fetch revamp-extern
git checkout -b neuerbranch revamp-extern/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

Lokalen Commit in ein Repository übertragen

Falls der lokale Branch mit dem neuen Commit noch nicht auf dem Repository existiert:
(revamp: Bezeichnung des Repositorys in '.git/config')

git push -u revamp lokaler-branch:neuer-remote-branch

Falls der Branch auf dem Repository auch noch von anderen Personen mit Commits erweitert wird, unbedingt vor jeder neuen Änderung die bisherigen Änderungen im Repository lokal übernehmen:

git pull

Anschliessend kann lokal ein neuer Commit erstellt werden und dieser wiederum in das Repository übermittelt werden:

git push