Git クロス プラットフォームの互換性
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Windows、macOS、および Linux のファイル システムには、他のいくつかのプラットフォームが常にサポートしているとは限らない制限と動作があります。 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 つの分岐またはタグ (ref と呼ばれます) を作成できます。 Git の内部は、Azure DevOps Services と Azure DevOps Server と共に、これを 2 つの異なる ref として扱います。 ユーザーのマシンでは、Git はファイル システムを使用して ref を保存します。 あいまいさが原因でフェッチやその他の操作が失敗し始めます。
小さなファイルは、各 ref を表します。ref の名前にスラッシュ (/) 文字が含まれている場合、フォルダーは最後のスラッシュの前の部分を表します。
問題を回避する簡単な方法の 1 つは、常にすべて小文字のブランチ名とタグ名を使用することです。 この問題がある 2 つのブランチまたはタグを既に作成している場合は、Azure Repos Web UI で修正できます。
ブランチ名を修正するには
- ブランチのページで、関連するコミットに移動します。
- ショートカット メニューで [新しいブランチ] を選択します。
- ブランチに、大文字と小文字の競合がない新しい名前を付けます。
- ブランチのページに戻り、競合するブランチを削除します。
タグ名を修正するには
- タグのページで、タグ付けされたコミットに移動します。
- ショートカット メニューで [タグの作成] を選択します。
- タグに、大文字と小文字の競合がない新しい名前を付けます。
- タグのページに戻り、競合するタグを削除します。
パスとファイル名の制限
Windows、macOS、および Linux オペレーティング システムには、ファイル名とパスに関するさまざまな制限があります。 これらの制限により、ファイルやフォルダーに名前を付けることができるものが制限されます。これにより、複数のプラットフォーム間で Git を使用するチームに問題が発生することがあります。
たとえば、ひとつのプラットフォームの開発者が別のプラットフォームでは無効なファイル名またはパス長を含む変更を共有リポジトリにコミットしたとします。 その後、別の開発者がコンテンツが無効なプラットフォームでそのコミットをチェックアウトしようとします。 この状況では、作業ディレクトリが破損し、破損したデータでリポジトリが損傷する可能性があります。
Azure Repos には、次の制限の1つ以上に違反するコミットを含むプッシュをブロックするリポジトリ設定が用意されています。
ファイル名とパスの参照テーブル
| 制限 / プラットフォーム | Windows | 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 です。 |
暗号化のサポート
Note
このセクションで説明するエンコードのサポートは、Azure DevOps Server 2019.1 以降でサポートされています。
Microsoft は、ウェブ プッシュ エンドポイントを介した UTF-16 および UTF-32 エンコードのサポートを追加しました。 このサポートによりエンコードの種類が保持されるため、ファイルを UTF-8 に書き換える必要はありません。 また、ウェブ経由で UTF エンコードされていないファイル (UTF エンコードのみをサポート) を保存しようとすると、警告が表示されます。
次のスクリーンショットは、ウェブ プッシュを使用してエンコードの変更を導入したときに表示されるダイアログの例を示しています。
