Совместимость кроссплатформенного интерфейса 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.
Чтобы исправить имена ветвей, выполните следующие действия.
- На странице ветвей перейдите к связанной фиксации.
- В контекстном меню выберите "Создать ветвь".
- Присвойте ветви новое имя, которое не имеет конфликта регистра.
- Вернитесь на страницу для ветвей и удалите конфликтующую ветвь.
Чтобы исправить имена тегов, выполните следующие действия.
- На странице тегов перейдите к помеченной фиксации.
- В контекстном меню выберите "Создать тег".
- Присвойте тегу новое имя, которое не имеет конфликта регистра.
- Вернитесь на страницу тегов и удалите конфликтующий тег.
Ограничения на путь и имя файла
Операционные системы 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. |
Поддержка кодировки
Примечание.
Поддержка кодировки, описанная в этом разделе, поддерживается в Azure DevOps Server 2019.1 и более поздних версий.
Корпорация Майкрософт добавила поддержку кодировки UTF-16 и UTF-32 через конечную точку веб-push-отправки. Эта поддержка означает, что мы сохраняем тип кодирования, поэтому вам не нужно переписать файлы как UTF-8. Вы также увидите предупреждение при попытке сохранить файл, который не закодирован через Интернет (который поддерживает только кодировку UTF).
На следующем снимках экрана показан пример диалогового окна, которое отображается при вводе изменений в кодировке с помощью веб-push-отправки.
