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

thx. Ok wenn ich

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

erhalte ich nach git branch, jenes

* (HEAD detached at release-3.7.0)
  master
  my361

---

wenn ich am ende folgendes Eingeben erhalte ich

$ git rebase master
error: cannot rebase: You have unstaged changes.
error: Please commit or stash them.

---

Ok, in der Tat etwas gemein, dann hast du vorher wahrscheinlich ein git pull gemacht:

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

Antwort:

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

Dann einmal einen neuen Zweig kreiern und diesen dann dagegen rebasen:

git switch -c kivi-37
git checkout my361
git rebase kivi-37

---

thx, anbei nochmal nur ob ich das so richtig verstanden habe die Schritte:

git checkout master
git pull

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

git checkout master
git checkout my361
git rebase kivi-37

achso im Moment stehe ich hier

  $ git branch
  master
* my361

moch etwas my361 ist das was ich via git checkout -b my361 erstellt habe.
Das würde ich dann auch tun wenn z.b die Version 4 da ist halt nur statt my361 dann mit my370 oder

---

habe es nochmals versucht, anbei die Schritte wobei die ersten drei nicht.

git checkout -b myxxx  // xxx = derzeitige Version  
git add templates/my_RB
git commit -m "heureka"


git checkout master
git pull

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

git checkout my361
git rebase kivi370

am Ende erhalte ich selbige Meldung:

$ git rebase kivi370
error: cannot rebase: You have unstaged changes.
error: Please commit or stash them.

---

Dann commite deine lokalen Änderungen oder wirf die weg:

git status -uno

Zeigt dir an welche Dateien geändert worden sind.

git checkout $DATEINAME 

Bringt die dann wieder in den Auslieferungszustand zurück.

---

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.