git und keine ende

Question

Hallo, irgendwie stehe ich mit git auf Kriegsfuß, versuche es jetzt schon mehrmals. Heute ging ich nach dieser Anleitung vor:

$ git clone https://github.com/kivitendo/kivitendo-erp.git
$ cd kivitendo-erp/
$ 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 ändernungen"

[meine_aenderungen 1d89e41] juhu tolle ändernungen
 4 files changed, 380 insertions(+)
 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

Zunächst wird der Branch zurückgespult, um Ihre Änderungen
darauf neu anzuwenden ...
Wende an: juhu tolle ändernungen
$ service apache2 restart                   # webserver starten!

Wobei ich die '3.4.1' durch meine derzeitige '3.6.1' Version ersetzt habe. Wenn ich danach im Browser Kivitendo aufrufe sehe ich weiterhin die Version 3.6.1. Es würde doch Sinn machen mit git zu arbeiten, da es ja einfacher sein soll die Version zu aktualisieren. Wichtig wäre mir auch jeweils nur die Stabel Version inne zu haben.

Noch eine Frage, nach obriger Anleitung was ist der unterschied von release-3.6.1 und meine_eigene_änderung / juhu tolle änderung?

Gibt es irgendwo eine funktionierende step by step Anleitung die einem DAU es so erklärt das es nur funktioniert?

Answer 1

Auf den ersten Blick sieht das erstmal richtig aus, ich mache es ähnlich, aber mit "git cherrypick" statt "git rebase". Ich erzeuge also einen neuen Branch auf dem Stand des "master" und ziehe mir dann meine eigenen Änderungen da hinein, Du machst es umgedreht, Du hast einen Branch auf altem Stand und spulst den vor auf den Stand des "masters".
Gleiches Ergebnis, umgekehrte Herangehensweise. Der effektive Unterschied ist, dass ich ständig neue aktuelle Branches mit meinen eigenen Änderungen erzeuge und Du statt dessen einen eigenen Branch parallel "mitwachsen" lässt.

Aber: wenn es Dir einzig um Deine Templates geht und Du keine weiteren Änderung hast, vor allem keine am Code, dann brauchst Du eigtl nur das Template-Verzeichnis von Git ausnehmen.

Füge dazu in der Datei ".git/info/exclude" (vorne dran ist ein Punkt, falls die Datei nicht existiert, lege sie an) Dein Templateverzeichnis hinzu. Dann wird das von Git nicht angerührt und Du kannst auschecken, wie Du lustig bist.
Also in Deinem Fall einfach eine Zeile

/templates/mein_druck

hinzufügen, das ist alles.

Answer 2

Die Doku ist insofern etwas unvollständig, da nicht klar ist, dass wir am Anfang auf dem Zweig master sind:

git checkout release-3.4.1  

ODER

git checkout master
git pull

Der erste Befehl holt den Master zum Stand des release ab und der zweite Befehl holt die aktuelle unstable (auch aus dem master).
Weiter oberhalb in der doku steht dann der kryptische, aber sichere checkout Befehl:

git checkout `git tag -l | egrep -ve "(alpha|beta|rc)" | tail -1`

Allerdings ist die Vorbedingung, dass der Zweig vorher "gefetcht" wird.

Beispiel:
Mein Zweig

git tag -l | egrep -ve "(alpha|beta|rc)" | tail -1
release-3.5.2

git branch
* meiner-361-1
  master

Master Zweig

git checkout master
git fetch
 * [neues Tag]           release-3.5.3                            -> release-3.5.3
 * [neues Tag]           release-3.5.4                            -> release-3.5.4
 * [neues Tag]           release-3.5.4beta                        -> release-3.5.4beta
 * [neues Tag]           release-3.5.5                            -> release-3.5.5
 * [neues Tag]           release-3.5.6                            -> release-3.5.6
 * [neues Tag]           release-3.5.6.1                          -> release-3.5.6.1
 * [neues Tag]           release-3.5.7                            -> release-3.5.7
 * [neues Tag]           release-3.5.8                            -> release-3.5.8
 * [neues Tag]           release-3.6.0                            -> release-3.6.0
 * [neues Tag]           release-3.6.0beta                        -> release-3.6.0beta
 * [neues Tag]           release-3.6.1                            -> release-3.6.1
 * [neues Tag]           release-3.7.0                            -> release-3.7.0

Jetzt checken wir die aktuellste Stable aus:

git checkout `git tag -l | egrep -ve "(alpha|beta|rc)" | tail -1`

Hinweis: Wechsle zu 'release-3.7.0'.

git checkout meiner-361-1
git rebase master # verheiratet jetzt die stable 3.7 mit meinen eigenen änderungen in meiner-361-1

Comments

ok siehe

$ git status -uno
On branch my361
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   image/kivitendo_mir.png

no changes added to commit (use "git add" and/or "git commit -a")

$ git checkout $DATEINAME 
M       image/kivitendo_mir.png

---

Tja, da mag jemand nicht, dass die kivi eine ukrainische Flagge mit Friedenstaube schwenkt.

$DATEINAME ist ein Platzhalter für die Datei die modifiziert (M) wurde. In dem Fall kivitendo_mir.png

git checkout image/kivitendo_mir.png

---

thx, jetzt habe ich die Version 3.7.0.

Aber beim aktualisieren der DB die nach dem Admin in der Benutzerebene folgt, erhalte ich jene Fehlermeldung:

The database update/creation did not succeed. 
The file sql/Pg-upgrade2/follow_up_done.sql containing the following query failed:
INSERT INTO follow_up_done (follow_up_id, done_at)   
SELECT id, COALESCE(mtime, itime) FROM follow_ups WHERE done IS TRUE
The error message was: ERROR:  
null value in column "done_at" violates not-null constraint
DETAIL:  Failing row contains (8, 15, null, null).
All changes in that file have been reverted.: 

Versuche gerade (bis her ohne Erfolg) folgendes in der meinigen DB unterhalb public via pphPgAdmin / SQl einzufügen:

INSERT INTO follow_up_done (follow_up_id, done_at) SELECT id,
COALESCE(mtime, itime) FROM follow_ups WHERE done IS TRUE

---

Auch das manuelle hinzufügen via create der Tadelle 'follow_up_done' bringt so nichts. Im Ergebnis genauso Abbruch der DB Aktualisierung nur mit dem Unterschied, Tabelle existiert bereits. Also genauso nass wie zuvor.

---

ok, ich mache für das DB Problem einen neuen Thread auf, ist Glaube das dies besser ist.