NTLM Endet In Git/libcurl: Azure DevOps Server-Teams Brauchen Einen Echten Migrationsplan

Emiliano Montesdeoca — Mon, 20 Jul 2026 00:00:00 +0000

Die bevorstehende NTLM-Entfernung in libcurl ist eine dieser Änderungen, die technisch aussehen, aber tatsächlich organisatorisch sind. Wenn Ihr Git-over-HTTPS-Pfad zu Azure DevOps Server immer noch von NTLM abhängt, ist Ihr Problem nicht Tooling, es ist Identitätsschulden.

Originalquelle: https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/

Microsoft hat recht, hier hart vorzugehen. NTLM hat bekannte kryptografische Schwächen und sollte kein moderner Enterprise-Standard sein. Der gefährliche Teil ist, dass viele Umgebungen glauben, sie verwenden Kerberos, wenn sie tatsächlich nur durch stillen SPNEGO-Fallback auf NTLM überleben. Diese Illusion verschwindet im September 2026.

Meine Meinung: Behandeln Sie dies nicht als “Client-Version”-Problem. Das erneute Aktivieren von NTLM-Flags, das Fixieren alter Git-Builds oder die Hoffnung, dass der Fallback verfügbar bleibt, ist ein kurzlebiger Workaround mit langfristigem Risiko. Wenn Ihre Abhilfestrategie Downgrade-und-Verzögern ist, erhöhen Sie aktiv die operative Fragilität.

Eine praktische Migrationssequenz sollte direkt und messbar sein.

Pull Requests direkt in Visual Studio zu prüfen, ist genau die Art von Reibungsreduktion, die ich mag

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Lies das Original hier.

Der Browser stiehlt dem Code-Review-Workflow schon viel zu lange zu viel Aufmerksamkeit.

Deshalb freue ich mich sehr zu sehen, dass Visual Studio weiter in Richtung End-to-End-Pull-Request-Review direkt in der IDE geht.

Das ist eine dieser Funktionen, die vielleicht keine riesigen Schlagzeilen machen, aber den Alltag spürbar verbessern können.

Der Hauptwert ist simpel: weniger Kontextwechsel

Wenn dein Review-Loop teilweise in der IDE und teilweise im Browser lebt, summiert sich die Reibung:

das PR woanders öffnen
die Änderungen in einem Tool ansehen
wieder zur Solution wechseln, um tiefer zu prüfen
noch einmal wechseln, um zu kommentieren oder freizugeben

Das ist nicht katastrophal. Es ist einfach ineffizient.

Wenn Visual Studio es dir erlaubt, ein PR zu öffnen, zu prüfen, zu kommentieren, freizugeben und zusammenzuführen, alles aus derselben Arbeitsumgebung heraus, dann ist das ein echter Produktivitätsgewinn.

Die Option „review ohne Checkout“ ist besonders angenehm

Ein Punkt, den ich besonders mag, ist die Möglichkeit, ohne Checkout des PR-Branches zu reviewen.

Das klingt klein, ist aber perfekt für:

schnelle Review-Durchgänge
unterbrochene Feedback-Anfragen
den aktuellen Branch und den lokalen Zustand unverändert zu lassen

Das ist genau die Art von Flexibilität, die gute Code-Review-Tools brauchen.

Meine Einschätzung

Das ist keine revolutionäre Funktion.

Es ist etwas Besseres: etwas Praktisches.

Für Teams, die den Großteil des Tages in Visual Studio verbringen, bedeutet stärkeres PR-Review-Support weniger Workflow-Unterbrechungen und einen glatteren Weg von der Prüfung zur Aktion.

Das ist in meinen Augen eine lohnenswerte Verbesserung.

Originalbeitrag: Pull Requests prüfen, ohne Visual Studio zu verlassen

Git | The .NET Blog

NTLM Endet In Git/libcurl: Azure DevOps Server-Teams Brauchen Einen Echten Migrationsplan

Pull Requests direkt in Visual Studio zu prüfen, ist genau die Art von Reibungsreduktion, die ich mag

Der Hauptwert ist simpel: weniger Kontextwechsel

Die Option „review ohne Checkout“ ist besonders angenehm

Meine Einschätzung