Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
Windows、macOS、Linux のファイル システムには、他のプラットフォームの 1 つ以上が常にサポートしていない制限と動作があります。 Git はクロスプラットフォーム テクノロジであるため、あるプラットフォームの開発者は、別のプラットフォームのファイル システムと互換性のない名前のファイルまたはフォルダーを含むコミットを行うことができます。 この非互換性からリポジトリを保護することは重要です。他のプラットフォームの開発者は、ファイル名またはパス名がサポートされていないため、作業ディレクトリが破損するコミットを知らないうちにチェックアウトする可能性があるためです。
Azure Repos には、1 つ以上のプラットフォームと互換性のないコミットをプッシュするユーザーからリポジトリを保護するのに役立つ 3 つのクロスプラットフォーム互換性設定 が用意されています。 これらの設定は、ファイル システムに関する次の制限事項に関連しています。
- 大文字と小文字の区別
- ファイル名とフォルダー名に関する制限事項
- パスの長さの制限
大文字と小文字の区別
Windows および macOS ファイル システムでは、既定では大文字と小文字が区別されません (ただし、大文字と小文字は区別されません)。 ほとんどの Linux ファイル システムでは大文字と小文字が区別されます。 Git はもともと Linux カーネルのバージョン管理システムとして構築されているため、大文字と小文字が区別されます。
Git for Windows では、大文字と小文字を区別しないオペレーティング システムに関する多くの問題に対処していますが、いくつかの問題が残っています。
ファイル名とフォルダー名
Linux では、 File.txt と file.txt の両方を含む Git リポジトリをチェックアウトしても問題ありません。 これらは個別のファイル名です。 Windows と macOS では、両方のファイルをチェックアウトすると、2 番目のファイルが最初のファイルを上書きします。 2 つのフォルダーが大文字と小文字のみが異なる場合、大文字と小文字を区別しないファイル システムでは、それらのフォルダーの内容が混在します。
ケースの競合があるリポジトリを修正するには、次の 2 つの方法があります。
- 大文字と小文字が区別される環境でリポジトリを確認します。 競合しないようにファイルとフォルダーの名前を変更し、それらの変更をリポジトリにプッシュします。 Linux 用 Windows サブシステム は、そのような環境の 1 つです。
- 競合ごとにコマンド
git mv -f <conflicting name> <non-conflicting name>を使用します。 両方のファイル名に正確な大文字を使用するように注意してください。
最初にケースの競合が発生しないようにすることをお勧めします。 Azure Repos には、このような状況につながるプッシュを防ぐための ケース強制設定 が用意されています。 開発者にとって、タブ補完を使用してファイルをコミットする習慣を採用することも役立ちます。 Windows と macOS の両方で大文字と小文字が保持されるため、これらのアプローチにより、Git の内部でファイル システムで使用される大文字と小文字がまったく同じになります。
ブランチ名とタグ名
大文字と小文字のみが異なる 2 つの分岐またはタグ ( refs と呼ばれます) を作成できます。 Git の内部は、Azure DevOps Services と Azure DevOps Server と共に、2 つの異なる ref として扱われます。 ユーザーのコンピューターでは、Git はファイル システムを使用して ref を格納します。 フェッチやその他の操作は、あいまいさのために失敗し始めます。
小さいファイルは各参照を表します。ref 名にスラッシュ (/) 文字が含まれている場合、フォルダーは最後のスラッシュの前の部分を表します。
問題を回避する簡単な方法の 1 つは、常にすべて小文字の分岐とタグ名を使用することです。 この問題が発生している 2 つのブランチまたはタグを既に作成している場合は、Azure Repos Web UI でそれらを修正できます。
ブランチ名を修正するには:
- ブランチのページで、関連するコミットに移動します。
- ショートカット メニューの [ 新しいブランチ] を選択します。
- 分岐に、大文字と小文字の競合がない新しい名前を付けます。
- ブランチのページに戻り、競合するブランチを削除します。
タグ名を修正するには:
- タグのページで、タグ付けされたコミットに移動します。
- ショートカット メニューの [タグの 作成] を選択します。
- 大文字と小文字が競合しない新しい名前をタグに付けます。
- タグのページに戻り、競合するタグを削除します。
パスとファイル名の制限
Windows、macOS、Linux オペレーティング システムには、ファイル名とパスに関してさまざまな制限があります。 これらの制限により、ファイルやフォルダーに名前を付けることができるものが制限されます。これにより、複数のプラットフォームで Git を使用するチームに問題が発生する可能性があります。
たとえば、あるプラットフォームの開発者が、別のプラットフォームで無効なファイル名またはパスの長さを含む共有リポジトリに変更をコミットするとします。 後で、別の開発者は、コンテンツが無効なプラットフォームでそのコミットをチェックアウトしようとします。 この状況により、作業ディレクトリが破損し、破損したデータでリポジトリが破損する可能性があります。
Azure Repos には、次の 1 つ以上の制限に違反するコミットを含むプッシュをブロックする リポジトリ設定 が用意されています。
ファイル名とパスの参照テーブル
| 制限/プラットフォーム | ウィンドウズ | macOS | Linux |
|---|---|---|---|
| ファイル名の制限 |
予約済みファイル名: CON、PRN、AUX、NUL、COM1-COM9、LPT1-LPT9 予約済みファイル名の後に続く .予約文字: \ / : * ? " < > .または空白で終わるファイル名 |
で終わるファイル名 / |
で終わるファイル名 / |
| パスの長さの制限 |
Windows のパス の最大長は 260 文字です (null ターミネータを含む)。 .NET を使用するディレクトリの場合、完全修飾ファイル名は 260 文字未満にする必要があり、ディレクトリ名は 248 文字未満にする必要があります。 |
ファイル名は 255 文字に制限されています。 HFS+ のパスの最大値は無制限として文書化されていますが、一部の macOS バージョンでは 1,016 文字のパスが上限となります。 一部のファイル システムでは、パスの最大値として 1,016 がサポートされています。 |
ファイル名は 255 文字に制限されています。 パスの最大値は 4096 です。 |
エンコードのサポート
Microsoft では、Web プッシュ エンドポイントを介した UTF-16 および UTF-32 エンコードのサポートを追加しました。 このサポートは、エンコードの種類を保持するため、ファイルを UTF-8 として書き換える必要がないことを意味します。 また、Web 経由で UTF エンコードされていないファイル (UTF エンコードのみをサポート) を保存しようとすると、警告が表示されます。
次のスクリーンショットは、Web プッシュを使用してエンコードの変更を導入するときに表示されるダイアログの例を示しています。
