Ein Programm mit Fenster fuer Git verkauft immer eines: Aenderungen einreichen, ohne jeden Befehl vorher zu lernen. Die Linie 3.6 hat zwei Dinge hineingelegt, mehrere Arbeitsordner je Ablage auf einmal und Konflikte beim Zusammenlegen an Copilot.

Die Version steht bei 3.6.7

Der aktuelle stabile Stand ist 3.6.7, erschienen am 14. Oktober 2026. Die Linie 3.6 begann am 24. Juni 2026, und innerhalb von vier Monaten folgten acht kleine Ausgaben, diese ist die achte. Die Vorablinie hat bereits einen dritten Teststand der naechsten Korrektur erreicht.

Die Hauptnummer bewegt sich nie, was sagt, dass die Funktionsarbeit in der ersten Ausgabe der Linie lag und die sieben folgenden vor allem Fehler betrafen. Das Projekt ist unter der MIT-Lizenz offen, ueberwiegend in TypeScript geschrieben, traegt rund einundzwanzigtausend Markierungen und zehntausend Abzweigungen und wird seit Mai 2016 gepflegt.

Eine Ablage, mehrere Arbeitsordner

Die erste neue Funktion jener Ausgabe war die Unterstuetzung fuer Arbeitsverzeichnisse von Git, mit denen sich mehrere Arbeitsordner einer Ablage verwalten lassen. Auf der Befehlseingabe gibt es das seit langem, in Programmen mit Fenster blieb es eine Luecke.

Was das bedeutet, zeigt eine ganz gewoehnliche Lage: Du bist mitten in einer Funktion, und jemand braucht sofort eine dringende Korrektur am Hauptzweig. Ohne Arbeitsordner versteckst du die Aenderungen, wechselst den Zweig, korrigierst und wechselst zurueck, was den Verlauf der Einsendungen verwischt, oder du klonst die Ablage erneut, was den Objektbestand verdoppelt und die Zweigpflege teilt. Mit Arbeitsordnern checkt dieselbe Ablage mehrere Zweige in verschiedene Ordner gleichzeitig aus, teilt einen Objektbestand, verdraengt keinen Zweig, und beide Ordner bleiben offen.

Dass daraus ein paar Klicks werden, senkt die Schwelle wirklich. Vorher verlangte der Vorgang zu verstehen, was ein Arbeitsordner ist, wie ein Pfad anzugeben ist und worauf beim Loeschen zu achten ist; jetzt deckt das Fenster alles ab.

Konflikte gehen an Copilot

Die zweite Funktion ist das Loesen von Konflikten beim Zusammenlegen mit Copilot. Dieselbe Ausgabe ergaenzte etwas Verwandtes: Eine Anfrage zum Erzeugen einer Einsendungsnotiz laesst sich unterbrechen, wo man frueher nach dem Druck auf Erzeugen wartete, bis sie fertig war.

Copilot ist im Fenster kein Neuling, automatische Notizen gibt es seit einer Weile. Es in Konflikte zu schieben gibt den langweiligsten Teil ab, zwei Saetze von Konfliktmarken zu lesen und zu entscheiden, welche Seite bleibt. Seine Rolle bleibt begleitend: Das Fenster zum Loesen bleibt, und ein Mensch bestaetigt jede Stelle, statt alles auf einmal anzunehmen.

Eine Korrektur derselben Ausgabe betrifft Konflikte unmittelbar. Wird der Konfliktstand ungueltig, kommt ein eingefrorener Dialog ohne Neustart zurueck. Solche Korrekturen erreichen nie eine Ankuendigung, und doch braucht sie genau wer Konflikte loest, weil ein eingefrorener Dialog gern im schlechtesten Moment passiert.

Haken liefen schon; 3.6 behob Plattformfehler

Ein Punkt gehoert klargestellt. Die Rede, 3.6 habe Unterstuetzung fuer Haken von Git gebracht, stimmt nicht. Wer die Anmerkungen der Linie 3.6 nach Haken durchsucht, findet zwei Korrekturen: eine in einer fruehen Ausgabe, die einen Haken, der aus der Standardeingabe liest, unter Windows scheitern liess, und eine in einer anderen, die einen Haken, der git aufruft, unter macOS wegen eines falschen Ausfuehrungspfads scheitern liess.

Anders gesagt, Haken liefen bereits, und 3.6 sorgte dafuer, dass sie auf zwei Systemen nicht mehr scheitern. Der Unterschied wirkt wie ein Detail, ist fuer ein Team mit Pruefungen vor dem Einreichen aber zweierlei: ob es ueberhaupt geht, oder ob es verlaesslich geht.

Die vier Punkte der Startseite

Die Startseite nennt vier Verkaufsargumente, und beim Durchlesen zeigt sich, dass alle dieselbe Art von Reibung angehen. Aenderungen genau pruefen, Versionen vergleichen und jede Abweichung sehen. Durch Ziehen auswaehlen, zusammenfassen und Einsendungen umordnen, also Einsendungen zwischen Zweigen bewegen, mehrere zu einer verschmelzen und die Reihenfolge des Verlaufs aendern. Aenderungen vormerken, ohne sie einzureichen. Und jederzeit eine Notiz berichtigen, neue Aenderungen einbringen oder auf einen frueheren Stand zurueckgehen.

Die Zieharbeit ist der Punkt, an dem es sich abhebt. Einsendungen auf der Befehlseingabe umzuordnen heisst, eine interaktive Neufassung zu oeffnen und bei einem Fehler mittendrin Konflikte zu behandeln; Ziehen macht daraus ein sichtbares Umsortieren, zum Preis, dass verwickelte Lagen weiterhin zum Terminal zurueckkehren.

Der Spruch auf der Startseite ist ebenso schlicht: Git nutzen, ohne mit Git zu ringen, und das Produkt nennt sich ein Programm mit Fenster, das die Verwaltung von Code am eigenen Rechner vereinfacht. Der Fussbereich bietet Anmerkungen, einen Weg mitzuwirken und einen Teststand, und sagt, dass es von der Gemeinschaft getragen und fuer Zusammenarbeit gebaut ist.

Fuer wen es taugt

Menschen neu bei Git und Menschen, die die Befehlseingabe nicht taeglich wollen, sind das direkte Publikum: einreichen, senden, holen und Zweige wechseln in einem Fenster, mit Unterschieden, die sich viel leichter lesen als Ausgaben im Terminal.

Der Preis ist, dass es nie das ganze Git abdecken will. Verwickelte Neufassungen, das Umschreiben von Verlauf im Stapel und feine Arbeit an Verweisen gehoeren weiter ins Terminal. Es als Eingang fuer den Alltag zu nehmen und die Befehlseingabe fuer die wenigen harten Aufgaben zu lassen, ist die praktischere Einrichtung.

Bei den Systemen deckt es Windows und macOS ab, kostenlos und offen, was in dieser Gruppe nicht gewoehnlich ist, wo die meisten Programme mit Fenster entweder Geld kosten oder nur einen Teil ihres Codes oeffnen.

Der Handel in GitHub Desktop war immer klar: nicht das ganze Git zu machen, sondern den meistgegangenen Weg zu pflastern. Arbeitsordner aus der Befehlseingabe ins Fenster zu holen und Konflikte an Copilot zu geben sind Schritte auf derselben Linie, weniger Muehe am Anfang und kein zweites Terminal noetig.