GitHub Desktop 3.6.7 ist ein kleines Release mit einem ausgesprochen praktischen Ziel: den Momenten, in denen ein grafischer Git-Client mehr als einen Checkout desselben Repositorys darstellen muss. Die Version bietet eine Einstellung, mit der der aktuelle Worktree sichtbar bleibt, verarbeitet Namen am Anfang mit einem Bindestrich korrekt, behebt ein Pfadproblem bei „In Cygwin öffnen“ und beseitigt einen Absturz in der Fortschrittsverfolgung von Git LFS.

Redaktionelles Foto eines Laptops und organisierter Projektordner, die mehrere verknüpfte Git-Worktrees darstellen.

An der grundsätzlichen Form von GitHub Desktop ändert sich dadurch nichts. Die Anwendung bleibt ein Desktop-Client rund um Git und kein Ersatz für Gits Repository-Modell. Der Nutzen ist enger gefasst und gerade deshalb praktisch: Wenn der Arbeitsalltag parallele Branches, verknüpfte Worktrees, große Dateien oder Repositorys mit ungewöhnlichen Namen umfasst, beseitigt 3.6.7 mehrere Stellen, an denen die Oberfläche im Weg stehen konnte.

Für Maintainer und Entwickler, die regelmäßig mit Worktrees arbeiten, ist das ein Release, das sich zu testen lohnt. Es ist kein Grund, einen stabilen Team-Workflow ohne Prüfung auf jedem eingesetzten Betriebssystem umzustellen. Ebenso wenig wird GitHub Desktop dadurch zu einer vollständigen Worktree-Verwaltung. Das eigene Changelog und der Release-Tag beschreiben ein gezieltes Wartungsrelease; die Git-Dokumentation erklärt, warum einige verbleibende Einschränkungen strukturell und nicht bloß kosmetisch sind.

Was sich in 3.6.7 geändert hat

Der offizielle Release-Tag für 3.6.7 führt vier Gruppen von Änderungen auf.

Erstens werden Branch-, Remote- und Tag-Namen, die mit einem Bindestrich beginnen, nun bei Fetch-, Push-, Checkout-, Merge-, Rebase- und Worktree-Operationen korrekt verarbeitet. Ein Name wie -maintenance ist ungewöhnlich, aber Git-Repositorys enthalten durchaus Bezeichnungen, die an der Grenze zur Kommandozeile problematisch sind. Eine grafische Anwendung muss solche Namen sicher an Git übergeben und ein Argument von einer Option unterscheiden. Die Korrektur ist weniger deshalb wichtig, weil die meisten Teams Namen mit führendem Bindestrich verwenden, sondern weil sie eine Klasse von Eingabe-Mehrdeutigkeiten in mehreren Arbeitsabläufen gleichzeitig schließt.

Zweitens behebt das Release die Cygwin-Integration, wenn der Repository-Ordner Leerzeichen oder Satzzeichen enthält. Ein solcher Fehler kann in einem sorgfältig benannten Testverzeichnis unsichtbar bleiben und in einem echten Windows-Home-Verzeichnis sofort stören. Das Repository kann gültig sein, die Shell kann installiert sein, und die Integration kann trotzdem scheitern, wenn der Pfad falsch zusammengesetzt oder maskiert wird. Die Release-Notiz ist knapp, ihr Geltungsbereich aber klar: Pfade sind Daten, und Desktop-Integrationen müssen sie unverändert bewahren.

Drittens stürzt die Fortschrittsverfolgung von Git LFS nicht mehr ab, wenn beim Lesen einer Datei ein Fehler auftritt. Das macht die zugrunde liegende Datei nicht lesbar und beseitigt auch nicht die Notwendigkeit, Speicher, Berechtigungen oder einen beschädigten Checkout zu untersuchen. Es bedeutet jedoch, dass ein Fehler bei der Fortschrittsanzeige den Client nicht mehr mitreißen sollte. Für Repositorys, die Binärdateien, Design-Assets, Datensätze oder andere große Objekte über Git LFS speichern, ist dies die unmittelbarste Zuverlässigkeitskorrektur des Releases.

Schließlich sorgt die neue Einstellung unter „Erscheinungsbild“ mit der Option „Worktree-Liste immer anzeigen“ dafür, dass der Toolbar-Bereich des aktuellen Worktrees sichtbar bleibt. Das frühere Beta-Changelog beschreibt das beabsichtigte Verhalten: Die Steuerung für den aktuellen Worktree bleibt vorhanden, statt zu verschwinden, wenn der übrige Listenbereich eingeklappt wird. Der Unterschied klingt geringfügig, bis ein Repository mehrere verknüpfte Checkouts besitzt und vor einem Commit geprüft werden muss, welcher davon aktiv ist.

Zum Release gehört außerdem die kleine Detailpflege, die man von einem Desktop-Wartungsupdate erwartet: bessere Kontraste für Erfolgs- und Fehlersymbole in der Prüfungsübersicht sowie eine Validierung der Pfade von macOS-App-Bundles im Klon-Dialog. Das sind keine Schlagzeilenfunktionen, passen aber zum Muster der Version. 3.6.7 macht Grenzfälle sichtbarer und weniger anfällig.

Warum die Worktree-Einstellung wichtig ist

Git-Worktrees sind im gewöhnlichen Sinn keine zusätzlichen Klone. Die Dokumentation zu Git Worktree beschreibt einen Hauptarbeitsbaum und null oder mehr verknüpfte Worktrees. Sie teilen den Großteil der Repository-Daten, halten aber Zustände wie HEAD und den Index getrennt. Praktisch kann ein Repository damit einen Checkout auf einem Feature-Branch, einen weiteren auf einem Release-Branch und einen dritten auf einem temporären Untersuchungs-Branch besitzen, ohne die gesamte Objekt-Datenbank dreimal herunterzuladen.

Dieses Modell ist besonders nützlich bei Arbeit, die häufige Kontextwechsel verlangt. Ein Maintainer kann einen Release-Branch sauber halten und gleichzeitig einen Pull Request in einem anderen Verzeichnis prüfen. Ein Entwickler kann einen lang laufenden Test oder lokalen Server in einem Worktree belassen und in einem zweiten an einer Fehlerbehebung arbeiten. Auch automatisierte Coding-Werkzeuge machen Worktrees sichtbarer, weil sie für parallele Aufgaben oft isolierte Checkouts anlegen. Die Verzeichnisstruktur ist anders, das menschliche Problem bleibt gleich: Mehrere Ordner sehen wie dasselbe Projekt aus, und ein Fehler kann im falschen landen.

Ein Client, der den aktuellen Worktree erst nach dem Öffnen eines Menüs anzeigt, fügt jeder Aktion ein kleines Maß an Unsicherheit hinzu. Bei einem Repository mit nur einem Checkout fällt das kaum auf. Teuer wird die Unsicherheit bei ähnlichen Namen, kurzlebigen Branches oder Verzeichnissen mit generischen Bezeichnungen wie work, app oder checkout.

Die neue dauerhafte Anzeige löst die Identifikation nicht allein. GitHub Desktop muss weiterhin genügend Pfad- oder Branch-Kontext zeigen, damit sich Worktrees unterscheiden lassen, und der aktuelle Issue-Tracker zeigt, dass dies ein aktives Usability-Thema bleibt. Ein offenes Issue schlägt vor, den vollständigen Pfad eines Worktrees beim Überfahren mit der Maus anzuzeigen, wenn mehrere Bäume denselben letzten Ordnernamen tragen. Das erinnert an die Grenze der Änderung: Eine sichtbare Liste verbessert die Auffindbarkeit, ist aber kein vollständiges Benennungssystem.

Die richtige Einordnung ist daher bescheiden. Die Änderung macht es schwerer, den aktuellen Kontext zu vergessen. Sie garantiert nicht, dass das ausgewählte Verzeichnis das beabsichtigte ist, und ersetzt nicht die Prüfung von Branch und Pfad vor einer nicht rückgängig zu machenden Aktion.

Das Release baut auf Gits eigenen Einschränkungen auf

Einige Überraschungen bei Worktrees lassen sich in einem Client nicht vollständig beheben. Git teilt Referenzen und Objekte bewusst zwischen Worktrees, während der Zustand pro Worktree geführt wird. Die Dokumentation weist darauf hin, dass HEAD und der Index getrennt sind, viele Referenzen jedoch gemeinsam bleiben. Ein Branch ist normalerweise nur in einem Worktree gleichzeitig ausgecheckt; Git verweigert bestimmte Operationen, sofern sie nicht ausdrücklich erzwungen werden.

Diese Unterscheidung erklärt, warum ein Worktree günstig und trotzdem diszipliniert zu verwenden ist. Das Erzeugen eines zweiten Checkouts erstellt kein vollständig unabhängiges Repository. Ein Fetch kann gemeinsam genutzte Remote-Tracking-Referenzen aktualisieren. Die Konfiguration kann geteilt werden, sofern keine Worktree-spezifische Konfiguration aktiviert ist. Hooks, generierte Dateien, Build-Caches und Umgebungsdateien können sich so verhalten, als gehörten alle Checkouts zu einem größeren Projekt, auch wenn die Quellverzeichnisse getrennt sind.

Auch die Aufräumregeln sind wichtig. Git legt Verwaltungsinformationen für verknüpfte Bäume im Verzeichnis worktrees des Repositorys ab. Löscht jemand einen Worktree im Dateimanager, können die Metadaten bestehen bleiben, bis sie bereinigt werden. Für einen sauberen Baum ist git worktree remove der unterstützte Weg; mit git worktree prune lassen sich verwaiste Einträge entfernen, nachdem geprüft wurde, dass der fehlende Baum tatsächlich verschwunden ist. Wurde ein Verzeichnis manuell verschoben, kann git worktree repair die Metadaten wieder verbinden.

GitHub Desktop kann diese Zustände verständlicher darstellen, sie aber nicht gefahrlos verändern. Wer eine sichtbare Worktree-Liste als Liste unabhängiger Klone interpretiert, kann weiterhin falsche Annahmen über gemeinsame Branches, Konfiguration oder Objektspeicherung treffen. Das Release sollte zusammen mit dem Git-Modell eingesetzt werden, nicht als Ersatz dafür.

Die Korrektur für Namen mit Bindestrich betrifft das Parsen

Führende Bindestriche lassen sich leicht als Namenskonvention abtun, die niemand verwenden sollte. Damit verpasst man die technische Lehre der Korrektur. Viele Kommandozeilenprogramme verwenden einen Bindestrich, um Optionen einzuleiten. Beginnt ein gültiger Branch-, Remote-, Tag- oder Pfadname ebenfalls mit einem Bindestrich, muss jede Schicht, die einen Befehl zusammensetzt, die Unterscheidung zwischen Wert und Flag erhalten.

Ein Client kann das mit sorgfältiger Verarbeitung von Argument-Arrays, expliziten Markierungen zum Ende der Optionen, Validierung oder einer Kombination dieser Techniken erreichen. Für Nutzer zählt vor allem das Ergebnis: Gewöhnliche Operationen dürfen einen Repository-Namen nicht als Kommandooption umdeuten.

Die Breite der 3.6.7-Notiz verdient Aufmerksamkeit. Die Korrektur beschränkt sich nicht auf Checkout, sondern umfasst Fetch, Push, Merge, Rebase und Worktree-Aktionen. Das deutet darauf hin, dass der problematische Wert mehrere Befehlswege durchlaufen kann. Ein Repository kann normal wirken, bis ein Remote oder Tag mit derselben Namensform ins Spiel kommt. Die gesamte Gruppe von Operationen zu reparieren ist wertvoller, als nur einen sichtbaren Menüpunkt zu flicken.

Maintainer sollten ungewöhnliche Ref-Namen trotzdem als Kompatibilitätstest behandeln. Wenn Automatisierung, Release-Skripte, Hosting-Hooks oder Dokumentation eines Projekts davon ausgehen, dass jeder Branch-Name ein konventionelles Wort mit Schrägstrichen ist, ist der Desktop-Client nur ein Teil des Systems. 3.6.7 senkt ein clientseitiges Risiko, macht aber nicht jede Drittanbieter-Integration robust.

Eine kleine Testmatrix genügt, um das Verhalten zu prüfen, ohne daraus ein Produktionsexperiment zu machen:

  • Ein Wegwerf-Repository und einen Branch mit führendem Bindestrich anlegen.
  • Fetch, Checkout, Merge und Rebase zunächst lokal ausführen, bevor ein gemeinsames Remote einbezogen wird.
  • Nur dann ein Remote oder Tag mit derselben Form ausprobieren, wenn die Repository-Richtlinien das erlauben.
  • Prüfen, ob Kommandozeile und Web-Oberfläche des Teams denselben Ref-Namen akzeptieren.
  • Die Test-Refs nach der Prüfung sauber entfernen.

Es geht nicht darum, Namen mit führendem Bindestrich zu empfehlen. Es geht darum zu prüfen, ob ein bestehendes Repository mit schwierigen Namen bedienbar bleibt.

Git LFS: Eine Absturzkorrektur ist keine Speicherdiagnose

Git LFS verändert die Fehleroberfläche eines Repositorys. Git speichert Zeigerdateien in der normalen Historie, während große Inhalte über einen LFS-Server verwaltet und bei Bedarf heruntergeladen werden. Eine Fortschrittsanzeige sitzt daher zwischen Benutzeroberfläche, lokalem Dateisystem, Git-Prozess und LFS-Übertragung. Ein Lesefehler kann durch Berechtigungen, eine verschwundene Datei, Eingriffe von Antivirensoftware, ein eingebundenes Netzlaufwerk, eine volle Festplatte oder ein Problem in der Übertragung verursacht werden.

Die Änderung in 3.6.7 betrifft die Reaktion des Clients auf einen solchen Fehler: Die Fortschrittsverfolgung soll die Anwendung nicht mehr zum Absturz bringen. Das ist nützlich, weil ein Absturz den Kontext zerstört. Der Nutzer kann den sichtbaren Operationszustand verlieren und anschließend herausfinden müssen, ob die Übertragung beendet, fehlgeschlagen oder eine teilweise Datei zurückgelassen wurde. Ein geöffneter Client kann den Fehler anzeigen und die Untersuchung des Repositorys ermöglichen.

Es wäre falsch, daraus eine Garantie für die Datenintegrität von LFS zu machen. Es handelt sich um eine Verbesserung der Robustheit im Anzeigepfad. Nach dem Upgrade sollten Teams große Dateioperationen weiterhin mit einem Test-Repository oder einem unkritischen Checkout prüfen, besonders auf Rechnern mit Netzfreigaben, externen Laufwerken, aggressiver Endpoint-Security oder ungewöhnlichen Dateisystemberechtigungen.

Wenn eine Übertragung fehlschlägt, sollten vor wiederholten Versuchen die Grundlagen geprüft werden. Freien Speicherplatz und Schreibberechtigungen kontrollieren. Prüfen, ob der Pfad lokal und stabil ist. LFS-Protokolle und den konfigurierten Endpunkt des Repositorys ansehen. Den Checkout mit dem üblichen Build- oder Asset-Validierungsprozess des Projekts überprüfen. Dass eine grafische Anwendung geöffnet bleibt, ist hilfreich, aber kein Beleg dafür, dass das Objekt vollständig ist.

Hier hilft auch der Open-Source-Charakter von GitHub Desktop bei der Nachvollziehbarkeit. Das Repository ist öffentlich, sein Changelog führt Issue-Referenzen auf, und die Anwendungsmetadaten weisen das Projekt als MIT-lizenziert aus. Diese Lizenz macht den Code unter den Bedingungen des Projekts zur Prüfung und Weiterverwendung verfügbar; Einschränkungen für Marken und die Lizenzen gebündelter Abhängigkeiten bleiben davon unberührt. Sie begründet keinen Supportvertrag und garantiert nicht, dass jede Integration auf jeder Plattform gleich funktioniert.

„In Cygwin öffnen“ und die unspektakuläre Bedeutung von Pfaden

Die Cygwin-Korrektur gehört zu einer größeren Klasse von Fehlern in Desktop-Software: Die Anwendung versteht einen Windows-Pfad, die Ziel-Shell erwartet einen POSIX-ähnlichen Pfad, und an der Grenze liegen Leerzeichen oder Satzzeichen. Ein Pfad wie ein Verzeichnis namens Open Source oder ein Ordner mit Klammern ist für ein Dateisystem völlig normal und zugleich eine häufige Quelle für Maskierungsfehler in Startprogrammen.

Für Nutzer lautet die praktische Frage, ob die reparierte Integration zur tatsächlichen Verzeichnisstruktur passt. Liegt das Repository in einem Pfad mit Leerzeichen, Klammern, eckigen Klammern, kaufmännischen Und-Zeichen oder Nicht-ASCII-Zeichen, sollte die Menüaktion nach dem Upgrade getestet werden. Dafür eignet sich ein nicht wegwerfbares Repository, aber nicht der aktive Release-Checkout für die erste Validierung. Prüfen, ob Cygwin im vorgesehenen Verzeichnis startet und ob die Shell dieselben Dateien sieht wie der Desktop-Client.

Die Änderung zeigt außerdem, warum GUI-Release-Notizen kleiner wirken können als die Fehler, die sie beheben. Die Funktion selbst ist nur eine Menüaktion. Der Fehler kann jedoch einen gesamten Arbeitsablauf für Menschen blockieren, die unter Windows eine Unix-ähnliche Toolchain verwenden. Eine zuverlässige Pfadübergabe ist Infrastruktur, auch wenn sie keine aufregende Funktion darstellt.

Dieselbe Vorsicht gilt für Skripte, die aus dem Client gestartet werden. Man sollte nicht annehmen, dass das aktuelle Arbeitsverzeichnis als Kontext genügt. Skripte sollten die Repository-Wurzel auflösen, Leerzeichen verarbeiten und eine sichtbare Diagnose ausgeben, wenn der Pfad nicht existiert. Die Anwendung kann einen korrekten Pfad übergeben; das aufgerufene Werkzeug muss ihn trotzdem richtig verarbeiten.

Wer zuerst aktualisieren sollte

Der stärkste Grund für ein schnelles Update besteht für Entwickler, die mehrere verknüpfte Worktrees in GitHub Desktop verwenden, mit Git LFS arbeiten, Cygwin unter Windows einsetzen oder Repositorys mit ungewöhnlichen Ref-Namen haben. Diese Nutzer liegen am nächsten an den betroffenen Pfaden und können erkennen, ob die Korrekturen zu ihrem Arbeitsablauf passen.

Eine zweite Gruppe sind Maintainer, die Beiträge auf unterschiedlichen Betriebssystemen einrichten. Ein Release, das einen pfad- oder namensabhängigen Fehler entfernt, kann den Supportaufwand senken. Trotzdem sollten die getesteten Versionen und Einrichtungserwartungen des Projekts veröffentlicht werden, statt das Desktop-Update als allgemeine Lösung zu behandeln.

Für Nutzer mit nur einem Checkout auf einem stabilen Rechner ist die Dringlichkeit geringer. Die hier zitierten Notizen kündigen keine große neue Funktion und keine Sicherheitsreaktion an. Ein Update gehört weiterhin zur normalen Wartung, aber es gibt wenig Grund, eine kontrollierte Umgebung ohne Kompatibilitätsprüfung zu unterbrechen.

Der sicherste Rollout ist schrittweise:

  1. 3.6.7 auf einem Rechner installieren, der den tatsächlichen Team-Workflow repräsentiert.
  2. Ein Repository mit einem verknüpften Worktree öffnen und prüfen, ob der aktuelle Worktree sichtbar bleibt.
  3. Den normalen Ablauf für Branch, Commit, Fetch, Push und Pull Request ausführen.
  4. Falls relevant, eine LFS-Übertragung und „In Cygwin öffnen“ aus einem Pfad mit Leerzeichen testen.
  5. macOS, Windows und Linux getrennt prüfen, wenn das Team mehr als eine Plattform unterstützt.
  6. Erst danach die dokumentierte Basisversion für Beiträge aktualisieren.

Das Release ist klein genug, dass dieser Prozess schnell abgeschlossen sein sollte. Es ist zugleich spezifisch genug, dass ein allgemeiner Smoke-Test genau die behobenen Fehler übersehen kann.

Was GitHub Desktop weiterhin nicht ist

GitHub Desktop ist kein vollständiger Ersatz für Gits Kommandozeile. Die Anwendung verbirgt den Unterschied zwischen Worktree und Klon nicht und kann nicht entscheiden, ob ein Branch geteilt, entfernt, gesperrt oder bereinigt werden sollte. Erweiterte Repository-Wartung gehört weiterhin zu den Git-Befehlen und zur operativen Dokumentation des Projekts.

Ebenso wenig ersetzt die Anwendung ein vollständiges Cygwin-Terminal. Die reparierte Integration öffnet eine andere Umgebung; sie vereinheitlicht die Semantik von Windows- und POSIX-Pfaden nicht in jedem Werkzeug. Ein Team, das PowerShell, Git Bash, Cygwin, WSL, Container und native Build-Tools mischt, sollte Pfadannahmen ausdrücklich dokumentieren.

GitHub Desktop ist außerdem keine Sicherheitsgrenze für Repository-Inhalte. Beim Öffnen eines Repositorys können Hooks ausgeführt, nicht vertrauenswürdige Daten dargestellt, externe Werkzeuge aufgerufen oder abhängig vom Workflow Zugangsdaten verwendet werden. Die Verbesserungen im Changelog sind wertvoll, aber die üblichen Vorsichtsmaßnahmen bleiben sinnvoll: Repository-Skripte prüfen, Zugangsdaten begrenzen, Abhängigkeiten aktuell halten und experimentelle Checkouts von sensiblen Umgebungen trennen.

Open Source bedeutet schließlich nicht, dass jeder Bestandteil der Distribution dieselbe Lizenz besitzt. Das Repository weist die Anwendung als MIT-lizenziert aus; Abhängigkeiten und GitHub-Marken unterliegen eigenen Bedingungen. Organisationen, die einen modifizierten Build weitergeben, sollten Lizenzdateien, Hinweise zu Drittanbieter-Software und Markenregeln prüfen, statt das Wort Open Source als pauschale rechtliche Schlussfolgerung zu verwenden.

Alternativen für Teams mit vielen Worktrees

Die erste Alternative ist die Git-Kommandozeile selbst. Sie legt das vollständige Worktree-Modell offen und ist der Referenzpunkt für Operationen wie add, list, lock, move, repair, prune und remove. Ein Team, das stark von Worktrees abhängt, sollte diese Befehle kennen, auch wenn der Großteil der täglichen Arbeit in einer GUI stattfindet.

Die zweite Möglichkeit ist ein Editor oder eine IDE mit ausdrücklicher Unterstützung für mehrere Wurzeln und Worktrees. Der Vorteil liegt in der Nähe zu Code, Terminals, Tests und Sprachwerkzeugen. Der Nachteil: Die Oberfläche kann das Öffnen mehrerer Ordner erleichtern und zugleich weniger Sichtbarkeit über den gemeinsam genutzten Git-Zustand bieten. Teams sollten sich auf Namenskonventionen und Bezeichnungen für Arbeitsbereiche einigen.

Die dritte Möglichkeit ist ein spezieller Worktree-Manager oder eine kleine Sammlung von Shell-Skripten. Damit lassen sich eine Verzeichnisstruktur vorgeben, vorhersehbare Namen erzeugen und veraltete Bäume entfernen. Gleichzeitig entsteht eine neue Wartungsfläche. Ein Skript, das auf einem Rechner bequem ist, kann gefährlich werden, wenn es eine bestimmte Pfadstruktur voraussetzt, einen nicht sauberen Baum löscht oder Sperren und nicht versionierte Dateien ignoriert.

GitHub Desktop 3.6.7 passt am besten, wenn ein Team für alltägliche GitHub-Aufgaben einen visuellen Client möchte und Gits Worktree-Regeln weiterhin akzeptiert. Es ist eine nützliche Zwischenschicht, keine Abstraktion, die den Repository-Zustand verschwinden lässt.

Das praktische Fazit

GitHub Desktop 3.6.7 ist einen Test wert, wenn Worktrees, Git LFS, Cygwin oder ungewöhnliche Ref-Namen zum Arbeitsalltag gehören. Die sichtbare Worktree-Einstellung verbessert den Kontext, die Korrektur für Namen mit führendem Bindestrich schließt eine reale Klasse von Problemen bei der Argumentverarbeitung, die Cygwin-Reparatur macht eine häufige Windows-Pfadgrenze weniger brüchig, und die LFS-Änderung verhindert, dass ein Dateilesefehler den Client mit beendet.

Für alle anderen ist dies ein normales Wartungsupdate mit wenig Aufregung. Interessanter ist das Release als Hinweis darauf, wo Desktop-Git-Clients unter Druck geraten: Parallele Checkouts werden alltäglich, Repositorys enthalten mehr generierte und binäre Inhalte, und Entwickler wechseln ständig zwischen grafischen und terminalbasierten Umgebungen.

Installieren, anschließend die für das eigene Repository wichtigen Grenzfälle prüfen. Vor dem Commit den aktiven Worktree ansehen. Branch- und Pfadnamen sichtbar halten. Beim Entfernen oder Reparieren von Verzeichnissen die eigenen Worktree-Befehle von Git verwenden. Eine Korrektur für einen LFS-Absturz als verbesserte Robustheit behandeln, nicht als Verifikationsschritt. Damit lässt sich der Wert von 3.6.7 nutzen, ohne einem kleinen Release mehr zu versprechen, als es tatsächlich leistet.

Quellen