Bash Lokale Versionsverwaltung für nur eine Datei sinnvoll?

[N.N.]

Moin, zurzeit habe ich einen Backup-Folder für eine Datei, dessen Inhalt ungefähr so aussieht:

-rw-r--r-- 1 1000 1000  20K Jul 20 07:55 2025-07-20_07:55:46_docker-compose.yml
-rw-r--r-- 1 1000 1000  21K Jul 21 20:40 2025-07-21_20:40:34_docker-compose.yml
-rw-r--r-- 1 1000 1000  21K Jul 22 07:49 2025-07-22_07:49:58_docker-compose.yml
-rw-r--r-- 1 1000 1000  22K Jul 27 12:22 2025-07-27_12:22:26_docker-compose.yml
-rw-r--r-- 1 1000 1000  22K Jul 27 22:04 2025-07-27_22:04:33_docker-compose.yml
-rw-r--r-- 1 1000 1000  22K Jul 31 05:23 2025-07-31_05:23:33_docker-compose.yml
-rw-r--r-- 1 1000 1000  22K Aug  4 08:14 2025-08-04_08:14:34_docker-compose.yml

Immer, wenn ich eine Änderung an der Compose vornehme, erstelle ich mithilfe eines Scripts eine Kopie dieser Datei...

Mit diff (oder diff3) kann ich den Unterschied zwischen einer Datei und dem Nachfolger sehen (also das Was-wurde-geändert?).

Aber das reicht mir noch nicht. Ich möchte nach jeder Änderung folgendes wissen:

• Was wurde geändert? (diff zum Vorgänger)
• Wann wurde es geändert? (date ...)
• Warum wurde diese Änderung eigentlich gemacht? (Natürliche Beschreibung, was wieso geändert wurde)

Ideal wäre es, dass immer, wenn ich die Compose bearbeite und auf speichern klicke, ein "Watchdog" oder ähnliches schaut, ob es eine Änderung gab, dann ein Backup der Datei angelegt wird, und eine KI oder ähnliches zusätzlich eine Readme-Datei mit einer ausführlichen Beschreibung anhand eines Templates dieser Änderung anlegt.

Es soll also nicht nur einfach ein Backup angelegt werden, sondern auch eine Beschreibung dazu... und alles sollte wenn möglich Dateibasiert bleiben.

Gibt es dafür (schon) Tools?

 

[Tornhoof]

mach den ordner zu nem lokalen Git repo.

 

[Gizzmow]

+1 für GIT Repo, das ist einfacher und kannst das besser vergleichen

 

[nutrix]

+2 Git Repo.

 

[Der Lord]

+1 für Git.

Hier empfiehlt sich m.M.n. sich das leichtgewichtige Gitea.

 

[netzgestaltung]

Hat schon jemand Git erwähnt?
Hab auch super Erfahrung mit Gitea (fork von Gitgo) gemacht
Weitere Tools: Github-Desktop oder Sublime-Merge oder Meld

Allerdings: mit der Backupstrategie & dass alles einzelne Dateien sein sollen, passt das nicht zusammen weil da hast du die Versionen im Repo.

 

[Alter_Falter]

git kann auch rein lokal genutzt werden, du brauchst kein remote dazu.

Wenn du ein remote repo anbinden willst und dich für selber hosten entscheidet wäre Forgejo (Fork von Gitea) einen Blick wert.

 

[Der Lord]

Und wenn's nachher kein Git sein soll (nachvollziehbar wenn es denn nur zur Versionierung einer einzelnen Datei dienen soll) : passendes Bash Script könnte auch eine Lösung sein. Als Parameter dann deine Beschreibung und es legt die Infos samt Datei als copy oder gezippt irgendwo ab (txt-Datei? sqlite-DB? gibt viele Möglichkeiten)

 

[N.N.]

Wäre Folgendes eine Überlegung wert: https://github.com/gitui-org/gitui ?

Und wie müsste ich vorgehen, weil jetzt habe ich ja schon alles in einzelnen Dateien.

 

[netzgestaltung]

du kannst mit der ältesten datei das repo starten (in einem eigenen Ordner).
dann überschreibst du die datei mit der nächst jüngeren git add . und machst einen commit mit der Änderungsbeschreibung git commit -m 'deswegen die änderung' .
So verfährst du mit allen versionen bis du in der gegenwart angekommen bist.

 

[N.N.]

Hat geklappt.

Vorweg:

mkdir backup-git
cd backup-git
git init
touch docker-compose.yml
git add docker-compose.yml
git commit -m "Init commit"
cd ..

Und dann folgendes Script:

#!/bin/bash
set -e
idx=1
for n in backup1/*docker-compose.yml
do
  echo "$n"
  dif=$(diff "backup-git/docker-compose.yml" "$n") || true
  msg=$(printf "Update %d:\n\n%s" $idx "$dif")
  idx=$((idx + 1))
  echo "$msg"
  cp -v "$n" "backup-git/docker-compose.yml"
  cd "backup-git"
  git add docker-compose.yml
  git commit -m "$msg"
  cd ..
done

Danach kann ich mit git log --reverse alle Änderungen sehen, so sieht es dann aus:

commit xx (HEAD -> master)
Author: Xx <xx@xx>
Date:   Mon Aug 4 10:27:36 2025 +0200

    Update 168:

    21,23d20
    <       - "--log.maxsize=10"
    <       - "--log.maxbackups=3"
    <       - "--log.compress=true"
    43,46c40,43
    <       - ...
    <       - ...
    <       - ...
    <       - ...
    ---
    >       - ....
    >       - ....
    >       - ....
    >       - ....
    224c221
    <       - /var/log:/srv/logs:ro
    ---
    >       - /var/log/:/srv/logs/:ro

 

[Alter_Falter]

Kann man so machen. Die "Commit Message" nutzt man normalerweise für eine kurze Beschreibung der Änderung. Die eigentliche Änderung sind ja über den Commit selber ersichtlich.

Mit git log -p kannst Du dir die Commits inklusive Änderungen ausgeben lassen.

commit fb0dac1c83755c7d6131b78f662de64783d1f808 (HEAD -> master, tag: 1.3.6, origin/master, origin/HEAD)
Author: René Wagner <rwa@clttr.info>
Date:   Tue Jul 29 19:06:36 2025 +0200

    - reduce required Perl version to 5.36 to allow running on Debian

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 2c9b454..37d9fde 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,4 +1,13 @@
 # Changelog
+## 1.3.6 (2025-07-29)
+- reduce required Perl version to 5.36 to allow running on Debian
+

 

[N.N.]

Hier das (generische) Script, was ich momentan habe:

#!/bin/sh
set -e
file_to_backup="docker-compose.yml"
backup_dir_1="backup-dc"
backup_dir_2="backup-dc-git"
cp -v "$file_to_backup" "${backup_dir_1}/$(date +%F_%T)_${file_to_backup}"
dif=$(diff -c "${backup_dir_2}/${file_to_backup}" "$file_to_backup") || true
msg=$(printf "Update:\n\n%s" "$dif")
cp -v "$file_to_backup" "${backup_dir_2}/${file_to_backup}"
cd "$backup_dir_2"
git add .
git commit -m "$msg"
cd ..
ls -l "$file_to_backup"
ls -la "$backup_dir_1"
ls -la "$backup_dir_2"

Es werden zwei Backups angelegt, einmal in backup-dc und einmal in -git. Die Indexvariable gibt es nicht mehr.

Das kann ich aufrufen, wenn es eine Änderung gab.

Die "Commit Message" nutzt man normalerweise für eine kurze Beschreibung der Änderung. Die eigentliche Änderung sind ja über den Commit selber ersichtlich.

Das stimmt. Danke dafür. ... Super wäre, wenn eine KI diese Message ohne mein Zutun erstellen könnte. Aber das wird wohl ein Traum bleiben.

 

[Enurian]

Super wäre, wenn eine KI diese Message ohne mein Zutun erstellen könnte. Aber das wird wohl ein Traum bleiben.

Dein Traum ist bereits Realität:

Die Qualität ist halt schwankend, eigentlich will man ja in wenigen Wörtern zusammenfassen, was der Sinn der Änderung ist, das kriegt das Ding nicht immer so ideal hin.

 

[N.N.]

ChatGPT hat ein CLI-Tool... ich versuche mal, das Script dahingehend zu ändern...

https://www.omglinux.com/chatgpt-command-line/

Also Prompt gebe ich eine die Änderungen und alte Datei, sollte eigentlich funktionieren.

 

[N.N.]

Ja, es hat geklappt, auch wenn es vielleicht nicht so schön ist wie mit Copilot...

Neues Script:

#!/bin/sh
set -e
file_to_backup="docker-compose.yml"
backup_dir_1="backup-dc"
backup_dir_2="backup-dc-git"
cp -v "$file_to_backup" "${backup_dir_1}/$(date +%F_%T)_${file_to_backup}"
dif=$(diff -c "${backup_dir_2}/${file_to_backup}" "$file_to_backup") || true
msg=$(printf "Update:\n\n%s" "$dif")
echo "$msg" > dc-prompt.txt
msg_2=$(chatgpt --init-prompt-from-file dc-init-prompt.txt --prompt-from-file dc-prompt.txt)
cp -v "$file_to_backup" "${backup_dir_2}/${file_to_backup}"
cd "$backup_dir_2"
git add .
git commit -m "$(printf '%s\n\n%s' "$msg" "$msg_2")"
cd ..
ls -l "$file_to_backup"
ls -la "$backup_dir_1"
ls -la "$backup_dir_2"

ChatGPTs Rolle (Init-Prompt):

Deine Aufgabe ist es nur, die Änderungen an einer docker-compose.yml Datei kurz zusammenzufassen.

Dafür wird dir die aktuelle Änderung als Prompt mitgegeben (die Ausgabe von diff -c ...).

Du gibst bitte nur eine kurze Beschreibung der Änderungen aus.

Beispiel:

commit xx (HEAD -> master)
Author: Xx <xx@xx>
Date:   Mon Aug 4 16:33:40 2025 +0200

    Update:

    *** backup-dc-git/docker-compose.yml    2025-08-04 16:25:32.059659225 +0200
    --- docker-compose.yml  2025-08-04 16:32:58.956566615 +0200
    ***************
    *** 429,436 ****
          networks:
            - mynet1

    - # Das ist nur ein temporärer Kommentar zwischen zwei Servicedefinitionen, der später wieder entfernt wird (ein Test)
    -
        adminer:
          image: adminer
          depends_on:
    --- 429,434 ----


    Entfernung eines temporären Kommentars zwischen zwei Servicedefinitionen.

commit xx
Author: Xx <xx@xx>
Date:   Mon Aug 4 16:25:32 2025 +0200

    Update:

    *** backup-dc-git/docker-compose.yml    2025-08-04 13:24:44.828916992 +0200
    --- docker-compose.yml  2025-08-04 16:24:49.879574385 +0200
    ***************
    *** 429,434 ****
    --- 429,436 ----
          networks:
            - mynet1

    + # Das ist nur ein temporärer Kommentar zwischen zwei Servicedefinitionen, der später wieder entfernt wird (ein Test)
    +
        adminer:
          image: adminer
          depends_on:


    Hinzufügen eines temporären Kommentars zwischen zwei Servicedefinitionen zur Datei docker-compose.yml.

Nachteile: Chatgpt sieht jetzt natürlich nur die Änderungen, und nicht die komplette Datei (vorher/nachher) als Kontext, weil ich nicht weiß, wie lang der Prompt werden darf. Zudem ist der Prompt nicht "individualisierbar".

Und Copilot ist dafür vielleicht die bessere Wahl ... aber es funktioniert immerhin.

 

[N.N.]

Hehe, immer zuerst suchen bzw. die Augen öffnen, das gibt es nebenbei bemerkt schon: https://github.com/kardolus/chatgpt-cli?tab=readme-ov-file#example

 

[Marco01_809]

Die commit messages von einer KI schreiben zu lassen ist witzlos wenn diese ausschließlich auf dem Diff basieren. Das ist wie bei Kommentaren im Code: Das WAS zu beschreiben ist am wenigsten nützlich weil jeder Programmierer lesen kann was der Code tut. Interessant ist das WIE und WARUM.

Das WAS kannst du dir ja auch jederzeit im Diff ansehen. Wenn es schnell gehen soll z.B. git log --oneline dann will man den Kerngedanken kurz und knapp benennen und keine leeren Ausschmückungen ([...] zwischen zwei Servicedefinitionen zur Datei docker-compose.yml, das interessiert keine Sau).

Wirklich nützlich bei einem config/dotfile/template repo wären messages wie:

• OpenX wird nicht mehr weiterentwickelt, wechsel zu LibreX
• Setze X auf Y weil Z zu klein ist für W
• Unendlich Auto-Restarts für X als Notlösung bis Y behoben ist
• Alle Pakete auf die neueste Version updaten
• Downgrade X auf 1.27 weil 1.28 Bug Y hat

Und wirklich gute commit messages sind im Format

komponente: X macht jetzt Y

- X ist der beste Ort um das zu machen weil [...]
- Dazu braucht X aber Z. Darum exportiert W jetzt Z

<Paragraph über Motivation/Ursache>
Y wird gebraucht für [...]. Dadurch kann man [...]
/ Ohne Y geht [...] nicht, was dazu führt [...]
/ Das war schon immer kaputt aber wir haben es vorher nicht bemerkt/es war egal weil [...]

<Paragraph über naheliegendere alternative Lösung(en) und warum diese nicht funktioniert/en>

ist für eine einzelne docker-compose.yml aber overkill.

Ansonsten doch lieber was systematisches wie "Update <datum>", das gaukelt wenigstens keinen inhaltlichen Wert vor. Oder wenn man doch unbedingt KI-generiert will dann zumindest irgendwie markieren damit man in ein paar Jahren noch weiß dass die Beschreibung nicht die Denkweise des Autors widerspiegelt sondern kontextlose fanfiction von einer Drittpartei ist.

 

[N.N.]

@Marco01_809

Das ist wie bei Kommentaren im Code: Das WAS zu beschreiben ist am wenigsten nützlich weil jeder Programmierer lesen kann was der Code tut. Interessant ist das WIE und WARUM.

Das meinte ich doch mit

• Was wurde geändert? (diff zum Vorgänger)
• Wann wurde es geändert? (date ...)
• Warum wurde diese Änderung eigentlich gemacht? (Natürliche Beschreibung, was wieso geändert wurde)

und

Chatgpt sieht jetzt natürlich nur die Änderungen, und nicht die komplette Datei (vorher/nachher) als Kontext, weil ich nicht weiß, wie lang der Prompt werden darf.

Wenn man nicht die komplette, aktualisierte Datei (hier ist es ja nur eine Datei, bei einem kompletten Projekt wird es natürlich umso komplizierter, man denke mal an Windows ...) auch und die Änderungen übergibt, dann muss eine KI Vermutungen anstellen, und das geht oft nicht oder geht schief.

Eine Möglichkeit wäre bei (öffentlichen) Projekten, der KI das Werkzeug zu geben, bei Bedarf die komplette Code-Basis zu sehen.

So, und hier ist noch ein Beispiel von heute morgen...

Init-Prompt:

Schreibe eine kurze Commit-Message der Änderungen in dieser docker-compose.yml-Datei.

Als Eingabe erhältst du die Ausgabe von "diff -c <alte docker-compose.yml> <neue docker-compose.yml>", also alle Änderungen, die vorgenommen wurden.

Ergebnis:

Update:

- Der Zugriff auf den Docker-Socket wurde von read-only auf read-write geändert.
- Der Chromium-Ordner wird nun als read-only eingebunden.
- Der Zugriff auf den Musik-Ordner wurde von einem absoluten Pfad auf den Home-Ordner des Benutzers geändert.
- Die Konfiguration für die Website "xx" wurde entfernt.

Sieht erst mal ganz schön aus... Aber im dritten Punkt lag die KI komplett daneben, den ein relativer Pfad wurde in einem absoluten umgewandelt (und nicht umgekehrt)...

<Paragraph über Motivation/

Das hasse ich. Das wollte mein alter Chef auch immer haben, aber die Motivation kann direkt aus einem "Bug" oder "Feature" ersichtlich sein.

Ein langes "Blabla, ich will die Welt erobern, denn ..." gehört meiner Meinung nach nicht in eine Commit- oder Pull-Request-Message.

Wer soll sich das später durchlesen?