Das Visual-Studio-Update vom 27. Oktober 2026 ergänzt die Git-Workflows um zwei Funktionen: Commits lassen sich mit dem aktuellen Arbeitsbaum vergleichen, und Merge-Konflikte lassen sich für mehrere Dateien gemeinsam auflösen. Im Mittelpunkt stehen damit weniger Klicks im Alltag, nicht neue Oberflächen.
Auf den ersten Blick wirkt das Update unspektakulär. Der Nutzen liegt in kleinen Unterbrechungen: eine bekannte Version gegen den aktuellen Stand prüfen, dieselbe Konfliktlösung auf mehrere Dateien anwenden oder nach einem Neustart sehen, welche ungespeicherten Änderungen wieder da sind. An diesen Stellen setzt Visual Studio 2026 an.
Das Update kommt über den Stable Channel von Visual Studio 2026. Neben den Git-Funktionen enthält es eine überarbeitete GitHub-Copilot-Chat-Oberfläche, Hot Exit, neue Tastenkürzel zum Verschieben von Tabs und eine neu gestaltete Fonts-and-Colors-Seite.
Commit und aktuellen Arbeitsbaum direkt vergleichen
Die neue Git-Funktion vergleicht einen früheren Commit mit dem Arbeitsbaum des aktuellen Repositorys. Der Vergleich enthält bereits committete Änderungen und laufende, noch nicht gespeicherte Bearbeitungen. Das weicht vom üblichen Commit-Vergleich ab und trifft trotzdem einen häufigen Fall: Der Zustand, in dem tatsächlich gearbeitet wird, ist oft eine Mischung aus mehreren Ebenen.
Der Arbeitsbaum ist der aktuelle Inhalt aller Dateien im ausgecheckten Repository. Dazu zählen Änderungen aus früheren Commits, lokale Änderungen seit dem letzten Commit und Dateien, die gerade bearbeitet werden. „Compare with Working Tree“ stellt deshalb nicht Commit gegen Commit, sondern einen bekannten Stand gegen die tatsächliche Arbeitssituation.
Aufrufen lässt sie sich über die Commit-Historie oder die Branch-Liste im Fenster „Git Repository“. Ein Rechtsklick auf einen Commit zeigt den Befehl „Compare with Working Tree“. Die Ansicht listet geänderte Dateien und zeigt die Unterschiede in einem seitlichen Diff. So lässt sich prüfen, wie weit ein Refactoring über mehrere Commits vom Ausgangsstand entfernt ist.
Auch ein bekannter funktionierender Zustand lässt sich so prüfen. Verursacht eine Änderung Probleme, kann man den aktuellen Arbeitsbaum gegen einen früheren Commit halten, von dem aus die Entwicklung lief. Der Vergleich zeigt dann, welche Dateien betroffen sind und welche Zeilen vom Referenzstand abweichen.
Bei kleinen Änderungen ist die manuelle Prüfung einzelner Dateien oft schneller. Sobald mehrere Commits, Branches oder laufende Änderungen beteiligt sind, hilft die zusammengefasste Sicht. Sie ersetzt kein Codeverständnis, spart aber die Suche nach der richtigen Vergleichsbasis und Wege zwischen Historie, Diff-Ansicht und Editor.
Merge-Konflikte für mehrere Dateien gemeinsam auflösen
Die zweite Erweiterung betrifft Merge-Konflikte in mehreren Dateien. Bisher musste man dieselbe Entscheidung für jede Datei einzeln treffen. Soll in einem Ordner oder im ganzen Repository durchgängig die aktuelle Version bleiben, ist das nicht mehr Datei für Datei nötig.
Im Fenster „Git Changes“ rechtsklickt man unter „Unmerged Changes“ auf mehrere ausgewählte Dateien, einen Ordner oder den Repository-Stamm. Dann stehen „Keep All Current“ und „Take All Incoming“ bereit. „Current“ ist der aktuelle Stand des Arbeitsbaums, „Incoming“ die Version aus dem eingehenden Commit oder Branch.
Die Auswahl gilt für alle markierten Dateien oder für alle Konfliktdateien im gewählten Ordner bzw. Repository. Das hilft, wenn die technische Entscheidung schon feststeht. Bei größeren Merges macht es aus einer langen Folge identischer Klicks eine planbare Aktion.
Sie ersetzt keine sorgfältige Prüfung. Merge-Konflikte markieren meist Stellen, an denen zwei Entwicklungsrichtungen unterschiedliche Annahmen über den Code treffen. Eine pauschale Entscheidung kann technisch konsistent und fachlich falsch sein. „Keep All Current“ oder „Take All Incoming“ beschleunigt daher vor allem Fälle, in denen die gewünschte Seite für alle betroffenen Dateien klar ist.
Hier hilft der Vergleich mit dem Arbeitsbaum als Kontrolle. Nach einer gebündelten Auflösung lässt sich prüfen, ob die resultierenden Dateien dem beabsichtigten Stand entsprechen. Die beiden Funktionen ergänzen sich: Die eine schafft Übersicht über Unterschiede, die andere spart Aufwand beim Umsetzen einer bekannten Entscheidung.
Neue Copilot-Chat-Oberfläche in Visual Studio
GitHub Copilot Chat bekommt eine neue Oberfläche und eine erneuerte technische Basis. Der Chat baut auf dem Copilot SDK auf, das zuvor mit „Agent (Preview)“ eingeführt wurde. Diese Basis gilt nun auch für den Ask-Modus, den Agent-Modus und die Chat-Infrastruktur. Copilot CLI und die GitHub Copilot App nutzen dieselbe SDK-Basis.
Laut dem Visual-Studio-Team verhalten sich die Copilot-Varianten dadurch einheitlicher. Agentenabläufe sollen besser unterstützt werden, längere Sitzungen effizienter laufen und weniger Rückfragen nötig sein. Das Team gibt außerdem an, dass Prompt-Caching in längeren Sitzungen besser wirkt.
Die neue Chat-Oberfläche aktiviert man in Visual Studio über „Tools > Options > GitHub > Copilot > Copilot Chat“. Nach „Use new Copilot chat experience“ ist ein Neustart nötig. Danach stehen im Chat-Fenster unter der Eingabe die Modi Agent, Interactive und Auto bereit. Copilot tritt damit nicht nur als Antwortsystem auf, sondern als Assistent für Arbeitsabläufe.
Im Alltag entscheidet, wie stabil dieser Ansatz in bestehenden Projekten läuft. Ein Agent muss nicht nur eine passende Antwort formulieren, sondern Änderungen in einem komplexen Codebestand nachvollziehbar einordnen. Dafür zählen Konsistenz, Zustandsverwaltung und eine nachvollziehbare Ausführung. Das Update verbessert die Grundlage, garantiert aber keine fehlerfreien Agentenabläufe.
Feedback geht über „Help > Send Feedback > Report a Problem“. Weil sich Copilot in laufenden Projekten unterschiedlich verhält, hilft ein sauber dokumentierter Testfall mehr als ein allgemeines Urteil. So lässt sich eher unterscheiden, ob das Problem aus der Chat-Oberfläche, der Modellantwort, der Tool-Integration oder dem Projektkontext kommt.
Hot Exit schützt ungespeicherte Arbeit beim Schließen
Hot Exit erhält ungespeicherte Dokumente, wenn Visual Studio beendet wird. Das gilt für neue Dateien, die noch nie gespeichert wurden, und für Änderungen an bestehenden Dateien. Beim nächsten Start stellt die IDE beides wieder her. Auch die Anordnung von Tabs und Fenstern bleibt erhalten.
Für bereits gespeicherte Dateien bleibt Undo verfügbar, samt „Strg+Z“. Hot Exit stellt nicht nur einen Textstand wieder her. Es rekonstruiert einen Arbeitskontext: offene Dateien, Änderungen, Fensterlayout und einen Teil des vorherigen Navigationszustands.
Die Funktion ist standardmäßig aus. Aktivieren lässt sie sich unter „Tools > Options > All Settings > Projects and Solutions > General“ mit „Reopen unsaved documents on solution load or empty environment“. „Solution load“ bzw. „empty environment“ meint die Situation, in der Visual Studio erneut geöffnet und das zuvor verwendete Projekt oder eine Umgebung ohne Solution wiederhergestellt wird.
Hot Exit wirkt wie eine Zwischenablage für den Arbeitsbereich. Das hilft, wenn Visual Studio durch einen Absturz, ein Update oder eine geplante Umstellung geschlossen wird. Der Nutzen hängt aber davon ab, wie die Dateien verwendet werden. Externe Tools oder Prozesse verwalten Dateien möglicherweise anders als Visual Studio. Vollständiges Speichern bleibt deshalb auch mit Hot Exit die sicherere Gewohnheit.
Tabs per Tastatur verschieben, Fonts and Colors anpassen
Auch die Tab-Organisation lässt sich per Tastatur bedienen. Mit „Strg+Shift+Bild auf“ und „Strg+Shift+Bild ab“ verschiebt man den aktiven Tab nach links oder rechts. Bei vertikalen Tabs geht es nach oben oder unten. Angeheftete und nicht angeheftete Tabs bleiben getrennt.
Es gibt Grenzen. Vertikale Tabs verlassen ihre Projektgruppe nicht, Preview-Tabs lassen sich nicht verschieben. Bei alphabetischer Sortierung ist manuelles Neuordnen ebenfalls nicht möglich. „Window.MoveTabLeft“ und „Window.MoveTabRight“ lassen sich unter „Tools > Options > Environment > Keyboard“ neu belegen.
Die Standardbelegung ersetzt die bisherigen Kürzel für „Edit.ViewTopExtend“ und „Edit.ViewBottomExtend“. Beide Befehle bleiben im System, haben aber zunächst keine direkte Zuordnung. Wer die alte Tastaturbelegung behalten will, kann sie in den Keyboard-Einstellungen wiederherstellen oder anders vergeben.
Die Seite „Fonts and Colors“ wurde überarbeitet und auf Unified Settings umgestellt. Kategorien, eine integrierte Suche und Inline-Vorschauen machen die relevanten Einstellungen leichter auffindbar. Vorder- und Hintergrundfarben, Schriftarten und Formatierungsstile stehen in einem Raster. Änderungen bleiben mit der „settings.json“ synchronisiert.
Die Synchronisation macht die persönliche Konfiguration prüfbar, versionierbar und teilbar. Änderungen lassen sich direkt in der JSON-Datei nachvollziehen, anpassen oder zurücksetzen. Für Teams kann das eine einheitlichere Umgebung ergeben, ohne dass jedes Detail in einer Oberfläche gesucht werden muss.
Was sich im Alltag ändert
Das Oktober-Update von Visual Studio 2026 bleibt bei vorhandenen Arbeitsabläufen. Der Vergleich mit dem Arbeitsbaum zeigt den tatsächlichen Zustand des Codes. Die gebündelte Konfliktlösung spart wiederkehrende Entscheidungen. Hot Exit schützt vor Arbeitsverlust, die Tastenkürzel sparen Mausbewegungen, und die überarbeitete Chat-Oberfläche soll Copilot in längere Agentenabläufe einbinden.
Die beiden Git-Funktionen greifen zusammen. Wer Unterschiede seit einem bekannten Commit bewerten will, bekommt einen genaueren Ausgangspunkt. Wer Merge-Konflikte einheitlich entscheidet, kann das Ergebnis anschließend gegen den Arbeitsbaum prüfen. Das ersetzt keine vollständige Versionsverwaltung, macht den Ablauf zwischen Code, Historie und Merge aber knapper.
Die übrigen Neuerungen folgen ähnlichen Zielen: Unterbrechungen abfedern, ohne den Entwicklungsprozess neu zu erfinden. Keine Funktion ersetzt gute Tests, sorgfältige Reviews oder regelmäßiges Speichern. Sie machen Visual Studio an mehreren Stellen weniger hinderlich. Im Alltag heißt das: bessere Übersicht bei Änderungen, weniger Routinearbeit bei Konflikten und ein sichererer Umgang mit laufender Arbeit.
Quelle: devblogs.microsoft.com
