Plattformübergreifende Kompatibilität von Git

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Die Dateisysteme Windows, macOS und Linux weisen Einschränkungen und Verhaltensweisen auf, die eine oder mehrere der anderen Plattformen nicht immer unterstützen. Da es sich bei Git um eine plattformübergreifende Technologie handelt, ist es für einen Entwickler auf einer Plattform möglich, einen Commit durchzuführen, der Dateien oder Ordner enthält, deren Namen mit dem Dateisystem einer anderen Plattform nicht kompatibel sind. Es ist wichtig, Ihr Repository vor dieser Inkompatibilität zu schützen, da Entwickler auf anderen Plattformen möglicherweise unwissentlich einen Commit auschecken, der ihre Arbeitsverzeichnisse aufgrund nicht unterstützter Datei- oder Pfadnamen beschädigt.

Azure Repos bietet drei plattformübergreifende Kompatibilitätseinstellungen, mit denen Sie Ihr Repository vor Personen schützen können, die Commits pushen, die mit einer oder mehreren Plattformen nicht kompatibel sind. Diese Einstellungen beziehen sich auf die folgenden Einschränkungen bei Dateisystemen:

• Groß- und Kleinschreibung
• Einschränkungen für Datei- und Ordnernamen
• Einschränkung für Pfadlängen

Groß- und Kleinschreibung

Bei den Windows- und macOS-Dateisystemen wird die Groß-/Kleinschreibung standardmäßig nicht beachtet (die Groß-/Kleinschreibung wird aber beibehalten). Bei den meisten Linux-Dateisystemen wird zwischen Groß- und Kleinschreibung unterschieden. Git wurde ursprünglich als Versionskontrollsystem des Linux-Kernels entwickelt, daher wird zwischen Groß- und Kleinschreibung unterschieden.

Zwar behebt Git für Windows viele der Probleme eines Betriebssystems, bei dem die Groß-/Kleinschreibung nicht beachtet wird, aber ein paar Eigenheiten bleiben bestehen.

Datei- und Ordnernamen

Unter Linux ist das Auschecken eines Git-Repositorys, das sowohl File.txt und file.txt enthält, kein Problem. Das sind unterschiedliche Dateinamen. Unter Windows und macOS führt das Auschecken beider Dateien dazu, dass die zweite die erste überschreibt. Wenn sich zwei Ordner nur durch die Groß-/Kleinschreibung unterscheiden, wird ihr Inhalt in Dateisystemen ohne Berücksichtigung der Groß-/Kleinschreibung vermischt.

Es gibt zwei Möglichkeiten zum Beheben eines Repositorys mit Fallkonflikten:

• Überprüfen Sie das Repository in einer Umgebung, in der die Groß-/Kleinschreibung beachtet wird. Benennen Sie Dateien und Ordner um, damit sie nicht mehr in Konflikt geraten, und übertragen Sie diese Änderungen dann in das Repository. Das Windows-Subsystem für Linux ist eine solche Umgebung.
• Verwenden Sie den Befehl git mv -f <conflicting name> <non-conflicting name> für jeden Konflikt. Achten Sie darauf, die genaue Groß-/Kleinschreibung für beide Dateinamen zu verwenden.

Es ist von Vorteil, Fallkonflikte von vornherein zu vermeiden. Azure Repos bietet eine Einstellung zur Durchsetzung der Groß-/Kleinschreibung, um Pushvorgänge zu verhindern, die zu dieser Situation führen würden. Für Entwickler ist es auch hilfreich, sich anzugewöhnen, die Vervollständigung mit der TAB-TASTE zum Committen von Dateien zu verwenden. Da sowohl Windows als auch macOS die Groß-/Kleinschreibung beibehalten, stellen diese Ansätze sicher, dass die Interna von Git genau die gleiche Groß-/Kleinschreibung sehen, die das Dateisystem verwendet.

Branch- und Tagnamen

Sie können zwei Branches oder Tags (auch als refs bezeichnet) erstellen, die sich nur hinsichtlich Groß-/Kleinschreibung unterscheiden. Die Interna von Git behandeln sie zusammen mit Azure DevOps Services und Azure DevOps Server als zwei separate „refs“ (Verweise). Auf dem Computer eines Benutzers verwendet Git das Dateisystem, um „refs“ zu speichern. Fetches und andere Vorgänge schlagen aufgrund der Mehrdeutigkeit fehl.

Jeder Verweis wird in einer kleinen Datei dargestellt. Wenn ein Verweisname Schrägstriche (/) enthält, stellen Ordner die Teile vor dem letzten Schrägstrich dar.

Eine einfache Möglichkeit, Probleme zu vermeiden, besteht darin, Branch- und Tag-Namen immer nur in Kleinbuchstaben zu verwenden. Wenn Sie bereits zwei Branches oder Tags erstellt haben, bei denen dieses Problem auftritt, können Sie diese in der Azure Repos-Webbenutzeroberfläche beheben.

So korrigieren Sie Branch-Namen:

1. Wechseln Sie auf der Seite für Branches zum zugehörigen Commit.
2. Wählen Sie im Kontextmenü Neuer Branch aus.
3. Geben Sie dem Branch einen neuen Namen, der keinen Groß-/Kleinschreibungskonflikt aufweist.
4. Kehren Sie zur Seite für Branches zurück, und löschen Sie den in Konflikt stehenden Branch.

So korrigieren Sie Tag-Namen:

1. Wechseln Sie auf der Seite für Tags zum markierten Commit.
2. Wählen Sie im Kontextmenü Tag erstellen aus.
3. Geben Sie dem Tag einen neuen Namen, der keinen Groß-/Kleinschreibungskonflikt aufweist.
4. Kehren Sie zur Seite für Tags zurück, und löschen Sie das in Konflikt stehende Tag.

Einschränkungen für Pfad- und Dateinamen

Für die Betriebssysteme Windows, macOS und Linux gelten verschiedene Einschränkungen für Dateinamen und Pfade. Diese Einschränkungen schränken die Benennung von Dateien oder Ordnern ein, was für Teams, die Git auf mehreren Plattformen verwenden, zu Problemen führen kann.

Stellen Sie sich beispielsweise vor, dass ein Entwickler auf einer Plattform eine Änderung am freigegebenen Repository committed, die einen Dateinamen oder eine Pfadlänge enthält, die auf einer anderen Plattform ungültig ist. Später versucht ein anderer Entwickler, diesen Commit auf einer Plattform auszuchecken, auf der der Inhalt ungültig ist. Diese Situation führt zu einem beschädigten Arbeitsverzeichnis, das Ihr Repository mit beschädigten Daten beschädigen kann.

Azure Repos bietet Repositoryeinstellungen, mit denen Pushvorgänge blockiert werden, die Commits enthalten, die gegen eine oder mehrere der folgenden Einschränkungen verstoßen.

Referenztabelle für Dateinamen und Pfade

Einschränkungen/Plattformen	Windows	macOS	Linux
Einschränkungen für Dateinamen	Reservierte Dateinamen: CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9 Reservierte Dateinamen, gefolgt von . Reservierte Zeichen: \ / : * ? " < > Dateinamen, die auf . oder Leerzeichen enden	Dateinamen, die in / enden	Dateinamen, die in / enden
Einschränkung für Pfadlängen	Pfade in Windows haben eine maximale Länge von 260 Zeichen (einschließlich eines NULL-Abschlusszeichens). Bei Verzeichnissen mit .NET muss der vollqualifizierte Dateiname weniger als 260 Zeichen und der Verzeichnisname weniger als 248 Zeichen lang sein.	Dateinamen sind auf 255 Zeichen begrenzt. Die maximalen Pfade in HFS+ sind als unbegrenzt dokumentiert, obwohl einige macOS-Versionen die Pfade auf 1.016 Zeichen begrenzen. Einige Dateisysteme unterstützen 1.016 als Pfadmaximum.	Dateinamen sind auf 255 Zeichen begrenzt. Der maximale Pfad beträgt 4096.

Codierungsunterstützung

Microsoft hat Unterstützung für die UTF-16- und UTF-32-Codierung über den Web-Push-Endpunkt hinzugefügt. Diese Unterstützung bedeutet, dass wir den Codierungstyp beibehalten, sodass Sie Ihre Dateien nicht in UTF-8 umschreiben müssen. Außerdem wird eine Warnung angezeigt, wenn Sie versuchen, eine Datei zu speichern, die nicht UTF-codiert ist (die nur UTF-Codierung unterstützt).

Der folgende Screenshot zeigt ein Beispiel für das Dialogfeld, das angezeigt wird, wenn Sie Codierungsänderungen mithilfe eines Webpushs einführen.