Совместимость кроссплатформенного интерфейса Git

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

В файловых системах Windows, macOS и Linux есть ограничения и поведение, которые не всегда поддерживаются одной или несколькими другими платформами. Так как Git — это кроссплатформенная технология, разработчик может сделать фиксацию, содержащую файлы или папки, которые имеют несовместимые имена с файловой системой другой платформы. Защита репозитория от этой несовместимости важна, так как разработчики на других платформах могут неузнавательно проверка фиксацию, которая повреждает рабочие каталоги из-за неподдерживаемых имен файлов или путей.

Azure Repos предлагает три кроссплатформенных параметра совместимости, которые помогают защитить репозиторий от людей, которые отправляют фиксации, несовместимые с одной или несколькими платформами. Эти параметры связаны со следующими ограничениями файловых систем:

• Учет регистра
• Ограничения на имена файлов и папок
• Ограничения длины пути

Учет регистра

Файловые системы Windows и macOS не учитывает регистр (но по умолчанию сохраняется регистр). Большинство файловых систем Linux чувствительны к регистру. Git изначально был создан для системы управления версиями ядра Linux, поэтому он учитывает регистр.

Хотя Git для Windows устраняет многие проблемы с нечувствительной операционной системой без учета регистра, некоторые причуды остаются.

Имена файлов и папок

В Linux проверка выход из репозитория Git, содержащего как File.txt, так и file.txt, не является проблемой. Это разные имена файлов. В Windows и macOS проверка от обоих файлов вызывает перезапись первого файла. Если две папки отличаются только по регистру, их содержимое объединяется в файловых системах без учета регистра.

Существует два способа исправления репозитория с конфликтом случаев:

• Ознакомьтесь с репозиторием в среде с учетом регистра. Переименуйте файлы и папки, чтобы они больше не конфликтуют, а затем отправьте эти изменения в репозиторий. подсистема Windows для Linux является одной из таких сред.
• Используйте команду git mv -f <conflicting name> <non-conflicting name> для каждого конфликта. Будьте осторожны, чтобы использовать точную букву для обоих имен файлов.

В первую очередь рекомендуется избежать создания конфликтов в случае. Azure Repos предлагает параметр принудительного применения случаев, чтобы предотвратить отправки, которые привели бы к этой ситуации. Для разработчиков, внедрение привычки использовать завершение вкладок для фиксации файлов также поможет. Так как и Windows, и macOS сохраняют регистры, эти подходы гарантируют, что внутренние элементы Git видят точно тот же регистр, который использует файловая система.

Имена ветвей и тегов

Вы можете создать две ветви или теги (известные как ссылки), которые отличаются только в регистре. Внутренние элементы Git, а также Azure DevOps Services и Azure DevOps Server, рассматривают их как два отдельных ссылок. На компьютере пользователя Git использует файловую систему для хранения ссылок. Получение и другие операции начинаются сбоем из-за неоднозначности.

Небольшой файл представляет каждый ссылочный файл. Если имя ссылки содержит символы косой черты (/), папки представляют части до окончательной косой черты.

Один из простых способов избежать проблем заключается в том, чтобы всегда использовать имена всех строчных ветвей и тегов. Если вы уже создали две ветви или теги с этой проблемой, их можно исправить в веб-интерфейсе Azure Repos.

Чтобы исправить имена ветвей, выполните следующие действия.

1. На странице ветвей перейдите к связанной фиксации.
2. В контекстном меню выберите "Создать ветвь".
3. Присвойте ветви новое имя, которое не имеет конфликта регистра.
4. Вернитесь на страницу для ветвей и удалите конфликтующую ветвь.

Чтобы исправить имена тегов, выполните следующие действия.

1. На странице тегов перейдите к помеченной фиксации.
2. В контекстном меню выберите "Создать тег".
3. Присвойте тегу новое имя, которое не имеет конфликта регистра.
4. Вернитесь на страницу тегов и удалите конфликтующий тег.

Ограничения на путь и имя файла

Операционные системы Windows, macOS и Linux имеют различные ограничения для имен файлов и путей. Эти ограничения ограничивают имена файлов или папок, которые могут создавать проблемы для команд, использующих Git на нескольких платформах.

Например, предположим, что разработчик на одной платформе фиксирует изменение в общем репозитории, который содержит недопустимое имя файла или длину пути на другой платформе. Позже другой разработчик пытается проверка этого фиксации на платформе, в которой содержимое недопустимо. Эта ситуация приводит к повреждению рабочего каталога, который может повредить репозиторий с поврежденными данными.

Azure Repos предлагает параметры репозитория, которые блокируют отправки , содержащие фиксации, которые нарушают одно или несколько следующих ограничений.

Справочная таблица для имен файлов и путей

Ограничения и платформы	Windows	macOS	Linux
Ограничения имени файла	Зарезервированные имена файлов: CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9 Зарезервированные имена файлов, за которыми следует . Зарезервированные символы: \ / : * ? " < > Имена файлов, заканчивающиеся пробелами . или пробелами	Имена файлов, заканчивающиеся в /	Имена файлов, заканчивающиеся в /
Ограничения длины пути	Пути в Windows имеют максимальную длину 260 символов (включая конечный элемент NULL). Для каталогов с .NET полное имя файла должно быть меньше 260 символов, а имя каталога должно быть меньше 248 символов.	Имена файлов ограничены 255 символами. Максимальное число путей в HFS+ задокументировано как неограниченное, хотя некоторые версии macOS заголовок пути в 1016 символов. Некоторые файловые системы поддерживают 1016 в качестве максимального пути.	Имена файлов ограничены 255 символами. Максимальный путь — 4096.

Поддержка кодировки

Корпорация Майкрософт добавила поддержку кодировки UTF-16 и UTF-32 через конечную точку веб-push-отправки. Эта поддержка означает, что мы сохраняем тип кодирования, поэтому вам не нужно переписать файлы как UTF-8. Вы также увидите предупреждение при попытке сохранить файл, который не закодирован через Интернет (который поддерживает только кодировку UTF).

На следующем снимках экрана показан пример диалогового окна, которое отображается при вводе изменений в кодировке с помощью веб-push-отправки.