Praxisprojekt Second Brain · Pflege

Versionieren mit Git

Lektion 3/69 Min. LesezeitFortgeschritten

Lernziele

  • Du committest jeden Agentenlauf als einen Commit, dessen Nachricht den Lauf benennt.
  • Du erkennst im Diff, ob der Agent eine Seite ergänzt oder umgeschrieben hat.
  • Du nimmst einen ganzen Lauf, ungesicherte Arbeit oder eine einzelne Seite gezielt zurück.

Git macht es erst sicher, einen Agenten unbeaufsichtigt laufen zu lassen. Ohne Git bleibt ein schlechter Lauf ein Rätsel. Mit Git ist jede Änderung ein Diff · engl. diffDie Gegenüberstellung zweier Stände einer Datei: Zeilen mit Plus kamen dazu, Zeilen mit Minus fielen weg. Git zeigt so, was ein Commit geändert hat.Im Glossar, den du lesen und mit einem Befehl zurücknehmen kannst.

Die Einrichtung, die .gitignore und das vollständige Zurücksetzen mit git restore und git clean zeigt die Lektion Git, Sync und Backups. Hier geht es um den Alltag danach.

Ein Commit pro Lauf

Jeder Lauf bekommt genau einen Commit, und die Nachricht nennt ihn:

ingest 2026-09-07: 4 sources, 9 pages
lint 2026-09-07: 3 broken links, 1 merge

Ein Commit pro Datei begräbt die Historie unter Einzelteilen. Ein Commit pro Woche macht es unmöglich, einen einzelnen schlechten Lauf zurückzunehmen, ohne die guten mitzunehmen. Ein Commit pro Lauf passt genau zu der Frage, die du später stellst: Was hat dieser Lauf getan?

Geplante Aufgaben committen ihre Arbeit selbst, als Teil des Laufs. Wie du ihnen die Git-Befehle freigibst, zeigt Zeitpläne.

Diffs generierter Seiten lesen

In den ersten Wochen lohnt es sich, die Diffs zu lesen, danach ab und zu. Du suchst zwei Dinge: Seiten, die sich geändert haben, obwohl sie es nicht sollten, und Umschreibungen, wo eine Ergänzung erwartet war.

Ein Agent, der eine Seite still umschreibt, statt etwas anzuhängen, fällt nur im Diff auf. Wir haben beides an der Seite Abrufübung nachgestellt, einmal als Ergänzung und einmal als Umschreibung:

# Ergänzung: drei Zeilen angehängt
 wiki/concepts/Abrufübung.md | 3 +++
 1 file changed, 3 insertions(+)

# Umschreibung: Kernaussage ersetzt, offene Frage gelöscht
 wiki/concepts/Abrufübung.md | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

Nur Pluszeichen heißt: Es kam etwas dazu. Minuszeichen in einer Seite, an die nur angehängt werden sollte, sind ein Grund, den vollen Diff zu öffnen. In unserem Beispiel ist dabei die offene Frage der Seite verschwunden.

Ergänzt oder umgeschrieben?

Der Auftrag lautete jedes Mal: neue Quelle einarbeiten, bestehende Seiten nur ergänzen. Ordne jede Zeile aus git diff --stat zu.

Noch offen (5)

  • Leitner-System.md | 4 ++++
  • Abrufübung.md | 7 +++----
  • index.md | 1 +
  • Verteiltes Wiederholen.md | 22 +----------
  • Pomodoro-Technik.md | 2 +-

Passt zum Auftrag (0)

    Diff öffnen (0)

      Nach einer Woche zeigt dir git log --stat, welche Seiten deine Automatisierung am häufigsten anfasst. Kompakter geht es so:

      git log --since=2026-11-01 --name-only --format= | sort | uniq -c | sort -rn | head

      Im Test-Vault standen nach einer Woche log.md (4 Commits) und index.md (3) oben. Das ist gesund, denn beide ändern sich mit jedem Lauf. Steht eine einzelne Konzeptseite ganz oben, schreibt der Agent sie womöglich bei jedem Lauf neu.

      Zurücknehmen

      git revert HEAD                                       # einen Lauf zurücknehmen, Historie bleibt
      git restore .                                         # ungesicherte Änderungen verwerfen
      git checkout HEAD~3 -- wiki/concepts/some-page.md     # eine Seite auf einen alten Stand

      git revert HEAD legt einen neuen Commit an, der den letzten Lauf rückgängig macht. Der schlechte Lauf bleibt in der Historie sichtbar. Im Test kam die gelöschte offene Frage auf der Seite Abrufübung damit zurück.

      git restore . verwirft alles, was seit dem letzten Commit geändert wurde. Das ist der Grund, vor jeder großen Operation zu committen. Ein Nachholen alter Quellen, das auf halber Strecke schiefgeht, kostet dich dann den Lauf und lässt den Vault unversehrt. Seiten, die der Lauf neu angelegt hat, entfernt erst git clean, wie in Git, Sync und Backups gezeigt.

      git checkout HEAD~3 -- <pfad> holt eine einzelne Seite aus einem älteren Commit, HEAD~3 heißt drei Commits zurück. Die Änderung ist danach schon für den nächsten Commit vorgemerkt. Committe sie mit einer Nachricht, die sagt, warum. Gleichwertig ist git restore --source=HEAD~3 --staged --worktree -- <pfad>.

      Branches

      Ein Branch · engl. branchEin Seitenzweig in Git, auf dem du Änderungen ausprobierst, ohne den Hauptstand zu berühren. Danach führst du ihn zusammen oder löschst ihn.Im Glossar lohnt sich für Experimente, die die Struktur anfassen: ein neues Seitenformat, eine Änderung am Schema, ein großer Neuimport unter anderen Anweisungen.

      git checkout -b neues-schema

      Lass den Lauf dort arbeiten, lies das Ergebnis, dann führe den Branch zusammen oder lösch ihn. Im Test haben wir auf einem Branch type: concept in type: konzept umbenannt. Zurück auf main stand überall wieder concept, und git branch -D neues-schema hat den Versuch entfernt.

      Machst du so einen Umbau direkt auf main und entscheidest erst danach, landet der Vault nach unserer Einschätzung oft in einem halb migrierten Zustand, den niemand mehr zu Ende bringen will.

      Was nicht ins Repository gehört

      .obsidian/workspace*, Caches und alles, was einen Schlüssel enthält. Der Key des Plugins Local REST API liegt in .obsidian/plugins/obsidian-local-rest-api/data.json. Schau vor dem ersten Push nach, was in .obsidian/plugins/ liegt.

      Halte das Remote-Repository privat, solange du den Vault nicht bewusst öffentlich gemacht hast.

      Merksätze

      • Jeder Lauf ist ein Commit, und die Nachricht nennt Art, Datum und Umfang des Laufs.
      • Minuszeichen im Diff einer Seite, die nur ergänzt werden sollte, sind ein Grund nachzusehen.
      • git revert HEAD nimmt einen Lauf zurück, git restore . verwirft Ungesichertes, git checkout HEAD~n -- <pfad> holt eine Seite zurück.
      • Umbauten an der Struktur laufen auf einem Branch und werden erst nach dem Lesen zusammengeführt.
      • Ein Key, der einmal committet wurde, bleibt in der Historie. Erneuere ihn.

      Prüf dich selbst

      Denkfrage

      Warum ist ein Commit pro Woche zu grob, obwohl er die Historie schön übersichtlich hält?

      Denkfrage

      Ein Lauf sollte nur ergänzen, aber git diff --stat zeigt bei einer Seite viele Minuszeichen. Wie gehst du vor?

      Prüf dich selbst

      1. 1Welche Commit-Nachricht passt zur Regel „ein Commit pro Lauf“?
      2. 2Der gestrige Import war schlecht, seitdem liefen zwei gute Läufe. Was nimmt nur den Import zurück?
      3. 3Wann lohnt sich ein eigener Branch?
      4. 4Du hast data.json mit dem Key gepusht und dann mit git rm --cached entfernt. Was ist jetzt der wichtigste Schritt?

      Quellen

      1. git-revert · Git, Stand: Nov. 2026

        Neuer Commit, der die Änderungen eines früheren zurücknimmt.

      2. git-restore · Git, Stand: Nov. 2026

        --source, --staged und --worktree.

      3. Removing sensitive data from a repository · GitHub, Stand: Nov. 2026

        Erst Schlüssel widerrufen oder erneuern, dann bei Bedarf git filter-repo.

      4. Local REST API with MCP · Adam Coddington, Stand: Nov. 2026

        Der API-Key liegt in data.json des Plugins.

      Dein Fortschritt bleibt nur in diesem Browser gespeichert.