Совместимость кроссплатформенного интерфейса 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 предлагает параметры репозитория , которые блокируют отправки, содержащие фиксации, которые нарушают одно или несколько следующих ограничений.

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

Ограничения и платформы	Виндоус	macOS	Линукс
Ограничения имени файла	зарезервированные имена файлов: 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-уведомления.